builtin printf behaves incorrectly with "c and 'c character-value arguments

2007-11-01 Thread Rich Felker
$ printf %d\\n \'À -61 (expected 192) This should be 192 regardless of locale on any system where wchar_t values are ISO-10646/Unicode. Bash is incorrectly reading the first byte of the UTF-8 which happens to be -61 when interpreted as signed char; on a Latin-1 based locale it will probably give -

Re: builtin printf behaves incorrectly with "c and 'c character-value arguments

2007-11-05 Thread Rich Felker
On Mon, Nov 05, 2007 at 09:10:29AM -0500, Chet Ramey wrote: > Rich Felker wrote: > > $ printf %d\\n \'À > > -61 > > (expected 192) > > > > This should be 192 regardless of locale on any system where wchar_t > > values are ISO-10646/Unicode. Bash is i

Re: builtin printf behaves incorrectly with "c and 'c character-value arguments

2007-11-05 Thread Rich Felker
On Mon, Nov 05, 2007 at 10:23:43PM -0500, Chet Ramey wrote: > Rich Felker wrote: > > > I'm not sure what you mean. For a Latin-1 locale there is no > > difference, but if the locale is a different legacy locale, the > > wchar_t value (Unicode scalar value on sy

bash's fallback implementation of vsnprintf(3) is nonconformant and breaks printf(1)

2007-11-09 Thread Rich Felker
bash-3.2.0(1)-release built on a system without native asprintf: $ printf %x\\n 0x8000 -8000 %x is an unsigned format specifier; printing it as signed is bogus. I tracked the problem down to the implementation of vsnprintf_internal which bash uses to implement asprintf if it's not present.

nonconformant behavior for printf(1) (you cannot interpret - as an option char)

2007-11-26 Thread Rich Felker
$ printf ---%s---\\n test bash: printf: --: invalid option printf: usage: printf [-v var] format [arguments] expected: ---test--- This seems to be the third bug I've found in bash's internal printf(1) which breaks conformance to POSIX. Could you either fix this, or else disable the printf (and po

echo(1) non-conformant (processing -e and -E)

2007-11-26 Thread Rich Felker
When running in POSIX/sh mode, bash should either disable the echo builtin or stop giving special treatment to -e and -E. In particular, POSIX provides well-defined behavior for: echo -e bash gives: blank line posix gives: line containing only "-e" echo -E bash gives: blank line posix gives: line

Re: nonconformant behavior for printf(1) (you cannot interpret - as an option char)

2007-11-26 Thread Rich Felker
On Mon, Nov 26, 2007 at 10:09:11PM -0700, Eric Blake wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > According to Rich Felker on 11/26/2007 10:02 PM: > > On Mon, Nov 26, 2007 at 09:54:52PM -0700, Eric Blake wrote: > >> -BEGIN PGP SIGNED M

Re: nonconformant behavior for printf(1) (you cannot interpret - as an option char)

2007-11-26 Thread Rich Felker
On Mon, Nov 26, 2007 at 10:24:08PM -0700, Eric Blake wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > According to Eric Blake on 11/26/2007 10:09 PM: > >> Again, go read POSIX and if you're still unclear file a RFI. But it's > >> very clear and bash is incorrect in this respect. > > >