This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: Puzzled!
- From: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- To: Paolo Carlini <pcarlini at unitus dot it>
- Cc: <libc-alpha at sources dot redhat dot com>, Ulrich Drepper <drepper at redhat dot com>, Roland McGrath <roland at redhat dot com>
- Date: Thu, 5 Dec 2002 23:44:23 +0000 (GMT)
- Subject: Re: Puzzled!
On Thu, 5 Dec 2002, Paolo Carlini wrote:
> * The |hh| specifier for |d|, |i|,|o|,|u|,|x|, or |X| conversion
> specifier does not convert the value to a |signed| or |unsigned|
> char before printing. This applies to both the wide and narrow
> versions of the input/output functions.
I don't think this is a bug; C99 specifies that the argument is a signed /
unsigned char, so I think that the behaviour is undefined if a value
outside the relevant range is passed. When I noticed such behaviour in
glibc some time ago I asked on comp.std.c about it; there was some
disagreement <http://groups.google.com/groups?th=8879d74992c25b91>; if
they think there's a glibc bug they should raise a DR.
> * The |INT/N/_C(value)| macros defined in |stdint.h| cause a
> compile-time error when the parameter /value/ is
> |INT_LEAST64_MAX|,|UINT_LEAST8_MAX|,|UINT_LEAST16_MAX|,|UINT_LEAST32_MAX|,|INTMAX_MAX|,
> or a similar type parameter. The implementation is appending a
> suffix to the name, generating an undeclared variable.
This is a testsuite bug. Appending a suffix is a correct (and intended)
way of implementing these macros; C99 clearly specifies that the argument
to the macros is a constant (not a constant expression), not another macro
expanding to a constant (or a constant expression, which is permitted for
those macros).
The web page in question is presumably
<http://www.dinkumware.com/conform_c.html>; you should point out the
testsuite bugs and ask them to test a system with GCC 3.2 and glibc 2.3
(e.g. Red Hat 8).
--
Joseph S. Myers
jsm28@cam.ac.uk