[Top][All Lists]

[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:
> address@hidden 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]