incorrect print -1 using %hhd

Bernd Petrovitsch bernd at petrovitsch.priv.at
Wed Mar 28 10:12:43 UTC 2012


On Mit, 2012-03-28 at 09:52 +0200, Bernhard Reutner-Fischer wrote:
> On 28 March 2012 08:38, Andrew Rybchenko <Andrew.Rybchenko at oktetlabs.ru> wrote:
> > On 03/28/2012 02:36 AM, Michael Deutschmann wrote:
> >> On Tue, 27 Mar 2012, Mike Frysinger wrote:
> >>> On Tuesday 27 March 2012 10:28:29 Andrew Rybchenko wrote:
> >>>> Is it known issue that uClibc 0.9.32 incorrectly prints -1 using
> >>>> %hhd (and %hhi) specifier? The following program:
> >>>
> >>> please file a bug
> >>
> >> No need, this is bug #1783.
> >>
> >> It was closed as fixed-in-the-next-release when I reported it against
> >> 0.9.31, but somehow the fix hasn't percolated into any release version of
> >> uClibc yet.
> >>
> >> The fix is really simple.  Just change the cast from "(char)" to "(signed
> >> char)" in libc/stdio/_load_inttype.c .  The bug was introduced not by any
> >> change in the sourcecode itself, but because the Makefiles started

That *was/is* a/the bug as "char", "signed char" and "unsigned char" are
actually 3 different types in C nowadays (well, not back then in K&R but
since ages, at least C89 ...).
"char" as such doesn't have a concept of "positive" or "negative" - see
e.g. http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf on
page 44 towards the end of the second paragraph (which is the first
complete paragraph on that page).

> >> specifying -funsigned-char everywhere.

That made the bug just visible ...

> And that's exactly why using -funsigned-char is a really bad idea.

More like changing that option exposes (potential) bugs. Hmm, the
simpler change would have been to add -fsigned-char as that's
(apparently) gcc's implementation defined solution.

And because of the 3 different char types, C compiler actually needs
this option so that one can tell the C compiler if a "char" has to be
promoted to a "signed char" or "unsigned char", respectively, if it is
used as an integral type (ie. used for calculations). "char" (as such)
is not an integral type and may contain only characters for printing
purposes and the like (and it is debatable what the behavior should be
if one stores values not from the ASCII range in there).

*eg* the more evil regression test is to compile uClibc with
-funsigned-char and -fsigned-char and check if it produces the same.

	Bernd
-- 
Bernd Petrovitsch                  Email : bernd at petrovitsch.priv.at
                     LUGA : http://www.luga.at



More information about the uClibc mailing list