From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LWtuE-0002Bl-Ez for mharc-grub-devel@gnu.org; Tue, 10 Feb 2009 09:48:10 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LWtuC-0002Ba-OE for grub-devel@gnu.org; Tue, 10 Feb 2009 09:48:08 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LWtuA-0002BO-OA for grub-devel@gnu.org; Tue, 10 Feb 2009 09:48:07 -0500 Received: from [199.232.76.173] (port=54195 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LWtuA-0002BK-D9 for grub-devel@gnu.org; Tue, 10 Feb 2009 09:48:06 -0500 Received: from aybabtu.com ([69.60.117.155]:46731) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LWtuA-0000aG-0i for grub-devel@gnu.org; Tue, 10 Feb 2009 09:48:06 -0500 Received: from [192.168.10.10] (helo=thorin) by aybabtu.com with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1LWtog-0003jM-7i; Tue, 10 Feb 2009 15:42:26 +0100 Received: from rmh by thorin with local (Exim 4.63) (envelope-from ) id 1LWttd-0006ml-BN; Tue, 10 Feb 2009 15:47:33 +0100 Date: Tue, 10 Feb 2009 15:47:33 +0100 From: Robert Millan To: Michel =?utf-8?Q?D=C3=A4nzer?= Message-ID: <20090210144733.GC25305@thorin> References: <1233040781.5108.98.camel@thor.local> <20090207194859.GC988@thorin> <20090207233836.1yh2s7te1ccgo0wc-cebfxv@webmail.spamcop.net> <1234259695.5081.680.camel@thor.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1234259695.5081.680.camel@thor.local> 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.13 (2006-08-11) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Cc: The development of GRUB 2 Subject: Re: hfs patch (Re: State of GRUB on PowerPC) 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: Tue, 10 Feb 2009 14:48:08 -0000 On Tue, Feb 10, 2009 at 10:54:55AM +0100, Michel Dänzer wrote: > > >> +static unsigned char caseorder[256] = { > > >> + 0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0A,0x0B,0x0C,0x0D,0x0E,0x0F, > > > > > > Could you be more specific about what the table contents mean? > > BTW, let me point out again that this table including comment is a > verbatim copy from the Linux kernel fs/hfs/string.c . Sorry if I didn't > make this clear enough in my original post. Since it's probably not copyright-significant, it may not be a problem to copy it from Linux sources. However, it's also possible for a list of numbers to be copyright significant, depending on their meaning (which is linked to my other question below). > > Michel may know better, but I think it's the order of characters. > > Those with the lower order go first in the sorted binary tree. Those > > with the same order are equivalent on the filesystem level. That is, > > "foo" can only be between "bar" and "quux" in the node tree. "foo" > > and "Foo" are the same tree node and thus the same file. > > I think that's a nice summary, thanks. Ok. There's a pair of things that need to be cleaned up though. If I understand correctly, the definition of caseorder[i] is such that given too distinct values of i, it can be used to sort them (if this is so, I think it should be explicitly mentioned in the comment). So if the table is basicaly storing values that enumerate something, why are we using hex to represent them? Hex gives the impression they're an opaque sort of thing, like code, bitmasks or magic numbers. The reference to "the Macintosh" is a bit confusing, it usually means a computer, or an OS. I assume it refers to HFS? We'd also need to know what are these "'casefold' and 'order' tables from ARDI's code", and what exactly means this is a "composition" of them. -- 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."