Re: Fix UINT{8,16}_C

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Jul  2 15:02, Eric Blake wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> According to POSIX, UINT{8,16}_C should result in an integer constant with
> "the same type as would an expression that is an object of the
> corresponding type converted according to the integer promotions."  And
> according to C, unsigned char promotes to signed int, when int is wider
> than char.  Gnulib now tests for bugs in stdint.h, and these are the
> remaining two issues that makes cygwin's version non-compliant:
> [...]
> @@ -169,8 +169,8 @@ typedef unsigned long long uintmax_t;
>  #define INT32_C(x) x ## L
>  #define INT64_C(x) x ## LL
>  
> -#define UINT8_C(x) x ## U
> -#define UINT16_C(x) x ## U
> +#define UINT8_C(x) x
> +#define UINT16_C(x) x
>  #define UINT32_C(x) x ## UL
>  #define UINT64_C(x) x ## ULL
>  

I have checked the stdint.h headers on glibc 2.3.4 and 2.4, as well as
on Solaris 10, NetBSD, FreeBSD and OpenBSD.  Only FreeBSD and OpenBSD
define them as just x, all others as x##U, one way or the other.

ISO/IEC 9899:TC2 (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf)
has the following to say:

  7.18.4.1 Macros for minimum-width integer constants

  The macro INTN_C(value) shall expand to an integer constant expression
  corresponding to the type int_leastN_t. The macro UINTN_C(value) shall
  expand to an integer constant expression corresponding to the type
  uint_leastN_t. For example, if uint_least64_t is a name for the type
  unsigned long long int, then UINT64_C(0x123) might expand to the
  integer constant 0x123ULL.

This is the case with our definition and with the definitions in glibc/
Solaris/NetBSD.  If the gnulib testsuite is right, then glibc fails the
test as well.  Has this been discussed/resolved on the appropriate
mailing lists?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat