grub-devel
[Top][All Lists]
Advanced

[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: Thu, 27 Aug 2009 23:31:28 +0200

On Wed, Aug 26, 2009 at 2:31 AM, Robert Millan<address@hidden> wrote:
> On Mon, Aug 24, 2009 at 09:23:22PM +0200, Vladimir 'phcoder' Serbinenko wrote:
>
>> 2009-08-24  Vladimir Serbinenko  <address@hidden>
>>
>>       UTF-8 to UTF-16 transformation.
>>
>>       * conf/common.rmk (pkglib_MODULES): Add utf.mod
>>       (utf_mod_SOURCES): New variable.
>>       (utf_mod_CFLAGS): Likewise.
>>       (utf_mod_LDFLAGS): Likewise.
>>       * include/grub/utf.h: New file.
>>       * lib/utf.c: New file. (Based on grub_utf8_to_ucs4 from kern/misc.c)
>
> Sounds like we could end up needing more of this (to other charsets), so
> why not give this module a generic name to hint as to where it can be added?
>
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.
>
> GNU libc has "iconv" command and "iconv_*" facilities for charset conversion,
> how about iconv.mod for consistency?
>
>> +       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
> --
> 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
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git




reply via email to

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