Re: dircolors database documentation

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Paul Eggert on 10/20/2005 1:33 PM:
> 
>>So am I allowed to assume 8-bit chars, or should I add code that checks
>>for char overflow, one hex digit at a time?  And with 8-bit chars, should
>>"\x100" parse as "\x10" "0", or should it raise a parse error?
> 
> 
> Nevermind....  I see now that printf.c bypasses all this gorp and says
> only that \x takes 1 or 2 hex digits.  Let's just do that.  The
> C rule is weird.

Fair enough.  A quick check of POSIX shows that \x is not standardized for
printf(1), anyways.  I also think it would be good to treat \x as an error
if there are no hex digits.

> 
> 
>>Also, should I try to attempt fixes where ls assumes ASCII?
> 
> 
> I wouldn't bother, unless you have an EBCDIC host to test your results
> on.  I suppose it wouldn't hurt to add a comment that the current code
> assumes something like ASCII.

OK, I'll add comments instead.

> 
> 
>>-           state = ST_OCTAL; /* Octal sequence */
>>+           state = ST_OCTAL2;        /* Octal sequence, max 2 chars */
> 
> 
> This doesn't look right; surely "\400" should be an error, not '\40'
> followed by '0'.

Depends on your background.  In Java, it is required to parse as '\40'
'0'.  C doesn't care (gcc prints a warning, and overflows char, ultimately
parsing as '\0').  gcc also parses '\48' as '\4' '8', rather than warning
that 8 is non-octal.  POSIX requires awk to parse the longest sequence of
up to three octal digits, but with no further directions as to what to do
to \400.  Anyone else have a preference?

- --
Life is short - so eat dessert first!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDWFs+84KuGfSFAYARAqsDAJ4gF7MZyNaU4bjdW7I0EEp+BClAYACg1IPr
9eF9lSgE8SCiPUKbiWjZ75I=
=PjHj
-----END PGP SIGNATURE-----