[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bug in Bash 2.05 and lower
From: |
scott douglass |
Subject: |
Re: Bug in Bash 2.05 and lower |
Date: |
Thu, 04 Oct 2001 09:43:59 +0100 |
Chet Ramey wrote:
> [format@chat.ru wrote:]
> > Here are some outputs:
> >
> > $echo -e '\x54'
> > T
> > $echo -e '\x544' # in fact it is hex 44
> > D
> > [...]
> >
> > So, left digit is siply ignored.
>
> More precisely, it's implicitly masked with CHAR_MAX.
>
> > Maybe i am wrong but I think that
> > this is not right. This is unclear and may cause errors.
>
> I agree that the code for echo, printf, and $'...' should only accept
> two hex digits after the `\x' to conform to ANSI C and be compatible
> with ksh.
If ksh limits \x to two hexidecimal digits then it's not possible to conform to
ANSI C and be compatible with ksh.
In ISO/ANSI C \<octal-digits> is limited to 3 octal digits. But
\x<hexidecimal-digits> is not limited -- the longest possible string of
hexidecimal digits is used to specify a single character. This is to allow
specification of character values on machines where e.g. CHAR_MAX = 0xffff.
This longest-possible-string-of-hexidecimal-digits behaviour is annoying when
generating strings using \x because you have to be sure that the character that
follows the hexidecimal digits is not also a hexidecimal digit. One way, in C,
to avoid any unwanted "gobbling" is to break the string in two after the
\x<hexidecimal-digits>, e.g.
"\x54" "4" /* equivalent to "T4" in ASCII */
and let string literal concatenation put them back together. This also works
for the echo case above:
echo -n -e '\x54' ; echo -e '4'
but it's not very graceful.