I have a test failing on gcc 4.1.1 with glibc 2.4. This test from cstdint_test.cpp fails: integral_constant_type_check(boost::uint8_t(0), UINT8_C(0)); http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/in... At least some discussions I found seems to say that UINT8_C cannot be used to deduce types because of some integer promotion issues and that UINT8_C should return int. The UINT8_C macro has been changed from returning c ## u, to returning just c, between version 2.3.5 and 2.4 of glibc. http://comments.gmane.org/gmane.os.cygwin.patches/3101 Is the test wrong or is the C standard library in error? -- Lgb
"Lars Gullik Bjønnes" wrote:
I have a test failing on gcc 4.1.1 with glibc 2.4.
This test from cstdint_test.cpp fails:
integral_constant_type_check(boost::uint8_t(0), UINT8_C(0));
http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/in...
At least some discussions I found seems to say that UINT8_C cannot be used to deduce types because of some integer promotion issues and that UINT8_C should return int.
The UINT8_C macro has been changed from returning c ## u, to returning just c, between version 2.3.5 and 2.4 of glibc.
http://comments.gmane.org/gmane.os.cygwin.patches/3101
Is the test wrong or is the C standard library in error?
Strangely this is one case where C99 appears to be quite specific, section 7.18.4.1 p2 says: "The macro INTN_C(value) shall expand to a signed integer constant with the specified value and type int_leastN_t. The macro UINTN_C(value) shall expand to an unsigned integer constant with the specified value and type uint_leastN_t." Except, I note that the discusssion you site rejects this argument :-( Then there's TR1, which is rather under-specified in this area, so double :-( To be honest I'm not sure what we should do here: in C++ we really do want these types to be unsigned!!! John.
"John Maddock" <john@johnmaddock.co.uk> writes: | Strangely this is one case where C99 appears to be quite specific, section | 7.18.4.1 p2 says: | | "The macro INTN_C(value) shall expand to a signed integer constant with the | specified value and type int_leastN_t. The macro UINTN_C(value) shall expand | to an unsigned integer constant with the specified value and type | uint_leastN_t." | | Except, I note that the discusssion you site rejects this argument :-( Yes, this is the wording in the ChangeLog for the change in glibc: * sysdeps/generic/stdint.h (UINT8_C, UINT16_C): Don't append 'U', since C99 requires the result to promote to 'int' when uint_least8_t and uint_least16_t promote to 'int'. | Then there's TR1, which is rather under-specified in this area, so double | :-( | | To be honest I'm not sure what we should do here: in C++ we really do want | these types to be unsigned!!! Is this something that could be run through comp.lang.c++.moderated? Or is it so that you cannot expect to get a specific type out of UINT8_C? (meaning that the test really is wrong, and that it is doing something that is not guaranteed.) -- Lgb
"Lars Gullik Bjønnes" wrote:
Then there's TR1, which is rather under-specified in this area, so double :-(
To be honest I'm not sure what we should do here: in C++ we really do want these types to be unsigned!!!
Is this something that could be run through comp.lang.c++.moderated? Or is it so that you cannot expect to get a specific type out of UINT8_C? (meaning that the test really is wrong, and that it is doing something that is not guaranteed.)
Unfortunately, I think there is a problem with our test, I've now found http://www.open-std.org/JTC1/SC22/WG14/www/docs/dr_209.htm which makes it clear that the behaviour was changed in the C99 TC :-( So I'll change the test to stop testing the unsigned requirements for types smaller than int. John.
participants (2)
-
John Maddock -
larsbj＠gullik.net