[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 12 Jun 2023 19:54:38 -0400
From: Rich Felker <dalias@...c.org>
To: Bruno Haible <bruno@...sp.org>
Cc: musl@...ts.openwall.com
Subject: Re: swprintf cannot handle the character 0xff
On Tue, Jun 13, 2023 at 01:09:26AM +0200, Bruno Haible wrote:
> Rich Felker wrote:
> > However, for wide printf:
> >
> > c
> > If no l (ell) qualifier is present, the int argument shall be
> > converted to a wide character as if by calling the btowc()
> > function and the resulting wide character shall be written.
> >
> > There's no specification of what happens if btowc fails here, but
> > passing EOF to btowc is required to fail and return WEOF.
>
> Possibly. But in the test program that I provided, I pass 255, not
> -1 (= EOF).
Right. I'm not questioning that your bug report is correct, just my
initial proposal for fixing it. Since wide printf is supposed to
perform the conversion as if by btowc, it should presumably handle -1
(as opposed to 255) as an error path.
> It's well-known that the preferred way to convert a 'char' to 'int'
> is not by direct assigment/cast, but by casting to 'unsigned char'.
> That's well-known from [f]getc(), the <ctype.h> functions, etc.
> You don't need to particularly care about programmers who pass
> '\xff' to a function that expects an 'int'.
On targets where plain char is signed, '\xff' has value -1, meaning it
would work for %c with narrow printf but not with wide printf. I
wonder if this should actually be a defect and if wide printf should
be specified as converting the value, converted to (unsigned char), as
if by btowc, rather than the raw value.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
