[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] UTF-8 to UTF-16 transformation

From: Vladimir 'phcoder' Serbinenko
Subject: Re: [PATCH] UTF-8 to UTF-16 transformation
Date: Fri, 28 Aug 2009 19:39:24 +0200

>> I'm ok with renaming but whether a conversion goes to charset.mod is
>> perhaps to be decided on case-by-case basis-
>> > The conversion functions in kern/misc.c could eventually move there as 
>> > well,
>> > once UTF-8 support becomes optional in the kernel.
>> utf16_to_utf8 can be moved now out of the kernel but it's used by some
>> fs modules (e.g. fat). Perhaps utf16_to_utf8 should be a separate
>> module? This would decrease the size of biggest cores with the price
>> of its increase in smaller cores.
> Uhm perhaps we should use inline functions then.  What do you think?
For me it's ok. During my tests with misc.c I checked this one too and
on 3 filesystems using utf16_to_utf I had following results:
core pc+fat+biosdisk: 7 bytes decrease
core pc+hfsplus+biosdisk: 2 bytes increase.
core pc+ntfs+biosdisk: 33 bytes decrease

I haven't checked the size with filesystems not using utf16_to_utf8.
Unfortunately USB uses this function too. I'll look if it's essential
and inlining effects on core.
>> >> +       if ((c & 0x80) == 0x00)
>> >> +         code = c;
>> >> +       else if ((c & 0xe0) == 0xc0)
>> >
>> > These should be macroified.
>> >
>> Actually this are accelerated bitchecks (bit numbers follow specific
>> and easy pattern) and for real readability would have to be written in
>> binary but AFAIK binary notation isn't supported in C code and would
>> result in overly long strings
> Ah, right.  Then it's not a problem.  Maybe with (1 << 7) instead of 0x80,
> if you prefer.
In second version I macroified these values (as
> --
> 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
> address@hidden

Vladimir 'phcoder' Serbinenko

Personal git repository:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]