printf %hh bugs

["Joseph S. Myers" <jsm28 at cam dot ac dot uk>]

glibc 2.1.94 has a couple of bugs in handling the "hh" (char) printf
length modifier:

* It fails to convert values outside of the range of unsigned char to
unsigned char for %hhu.  See article below from comp.std.c: glibc yields
the output 257 instead of 1 for the program given.

* It fails to honour the hh modifier in a %hhn format, so overwriting more
data than it should when writing the value (and presumably giving an
obviously wrong answer on bigendian architectures).

-- 
Joseph S. Myers
jsm28@cam.ac.uk

From: "Clive D.W. Feather" <clive@on-the-train.demon.co.uk>
Newsgroups: comp.std.c
Subject: Re: printf %h and %hh formats
Date: Wed, 20 Sep 2000 20:02:14 +0100
Organization: Demon Internet
Message-ID: <P7+lGrK2mQy5EwP8@romana.davros.org>
References: <8qau43$ihv$1@pegasus.csx.cam.ac.uk>
Reply-To: "Clive D.W. Feather" <clive@demon.net>

In article <8qau43$ihv$1@pegasus.csx.cam.ac.uk>, Joseph S. Myers
<jsm28@cam.ac.uk> writes
>Suppose CHAR_BIT is 8.  Consider the following program:
>
>       #include <stdio.h>
>       int
>       main(void)
>       {
>         printf("%hhu\n", 257);
>       }
>
>The argument 257 has type int which is the correct type from promotion
>of unsigned char, but the value 257 could not have arisen from passing
>an unsigned char argument.  Is the implementation required to convert
>the value 257 to unsigned char and print 1, or is the behavior
>undefined?

I would take the view that the implementation is required to convert it
to unsigned char (which in this case involves reduction modulo 256). Had
you put %hhd it would be implementation-defined (since the conversion
is) or a signal is raised.

-- 
Clive D.W. Feather    | Internet Expert      | Work: <clive@demon.net>
Tel: +44 20 8371 1138 | Demon Internet       | Home: <clive@davros.org>
Fax: +44 20 8371 1037 | Thus plc             | Web:  <http://www.davros.org>
Written on my laptop; please observe the Reply-To address