From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Mh4Cb-0000Hw-HG for mharc-grub-devel@gnu.org; Fri, 28 Aug 2009 12:21:25 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mh4Ca-0000Ho-Eo for grub-devel@gnu.org; Fri, 28 Aug 2009 12:21:24 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mh4CW-0000Hc-SG for grub-devel@gnu.org; Fri, 28 Aug 2009 12:21:24 -0400 Received: from [199.232.76.173] (port=40717 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mh4CW-0000HZ-Q2 for grub-devel@gnu.org; Fri, 28 Aug 2009 12:21:20 -0400 Received: from xvm-190-8.ghst.net ([217.70.190.8]:36775 helo=aybabtu.com) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mh4CW-0002O6-4R for grub-devel@gnu.org; Fri, 28 Aug 2009 12:21:20 -0400 Received: from [192.168.10.10] (helo=localhost) by aybabtu.com with esmtp (Exim 4.69) (envelope-from ) id 1Mh4CU-00034Z-B4 for grub-devel@gnu.org; Fri, 28 Aug 2009 18:21:18 +0200 Received: from rmh by localhost with local (Exim 4.69) (envelope-from ) id 1Mh4CT-0003uM-QI for grub-devel@gnu.org; Fri, 28 Aug 2009 18:21:17 +0200 Date: Fri, 28 Aug 2009 18:21:17 +0200 From: Robert Millan To: The development of GRUB 2 Message-ID: <20090828162117.GA14976@thorin> References: <20090826003131.GC25183@thorin> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: free as in freedom X-Message-Flag: Worried about Outlook viruses? Switch to Thunderbird! www.mozilla.com/thunderbird X-Debbugs-No-Ack: true User-Agent: Mutt/1.5.18 (2008-05-17) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: Re: [PATCH] UTF-8 to UTF-16 transformation X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 16:21:24 -0000 On Thu, Aug 27, 2009 at 11:31:28PM +0200, Vladimir 'phcoder' Serbinenko wrote: > On Wed, Aug 26, 2009 at 2:31 AM, Robert Millan wrote: > > On Mon, Aug 24, 2009 at 09:23:22PM +0200, Vladimir 'phcoder' Serbinenko wrote: > > > >> 2009-08-24  Vladimir Serbinenko   > >> > >>       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. Uhm perhaps we should use inline functions then. What do you think? > >> +       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. -- 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."