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."
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
