On Mon, Aug 17, 2009 at 3:43 PM, Robert Millan<r...@aybabtu.com> wrote:
> On Sat, Aug 15, 2009 at 04:47:32PM +0200, Vladimir 'phcoder' Serbinenko wrote:
>> +static inline char *
>> +grub_strncat (char *dest, const char *src, int c)
>> +{
>> + char *p = dest;
>> +
>> + while (*p)
>> + p++;
>> +
>> + while ((*p = *src) != '\0' && c--)
>> + {
>> + p++;
>> + src++;
>> + }
>> +
>> + *p = '\0';
>> +
>> + return dest;
>> +}
>
> Some of them (like this one) are surprisingly big. Did you test them
> separately?
Yes I did. My test environment was a core.img with pc+fat+biosdisk. I
have a log which functions save how much. In this case inlining
strncat saved 21 bytes. The reason for some bigger functions to be
inlined is that they are used only in non-size critical parts. In this
case it's used in LUA and iso9660.mod (one call). So inlining strncat
always saves space (even if iso9660.mod is in core.img but there is no
size limit when booting from cd).
>
> --
> Robert Millan
>
> The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
> how) you may access your data; but nobody's threatening your freedom: we
> still allow you to remove your data and not access it at all."
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
--
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
