Re: INTx_C/UINTx_C definitions result type

["Valeriy E. Ushakov" <uwe%stderr.spb.ru@localhost>]

On Mon, Dec 06, 2010 at 10:06:34 +0100, Nicolas Joly wrote:

> On Mon, Dec 06, 2010 at 05:00:05AM +0300, Valeriy E. Ushakov wrote:
> > On Sun, Dec 05, 2010 at 22:11:32 +0100, Nicolas Joly wrote:
> > 
> > > I just noted that INTx_C/UINTx_C macros does not seems to return
> > > costants of the specified `uint_leastx_t' type as expected ...
> >
> > I think your patch is not correct.  What is the problem you are trying
> > to solve?
> 
> While checking pcc behaviour to compile a few tools, i noticed the
> following line from configure output :
> 
>         checking whether stdint.h conforms to C99... no
> 
> and wondered what was the problem.
> 
> The corresponding macro contains the following construct:
> 
> struct s {
>   [...]
>   /* Detect bugs in glibc 2.4 and Solaris 10 stdint.h, among others.
>   */
>   int check_UINT8_C:
>         (-1 < UINT8_C (0)) == (-1 < (uint_least8_t) 0) ? 1 : -1;
>   int check_UINT16_C:
>         (-1 < UINT16_C (0)) == (-1 < (uint_least16_t) 0) ? 1 : -1;
>   [...]
> };
> 
> Tests which failed with pcc:
> 
> njoly@petaure [~]> ./xx
> xx: (-1 < UINT8_C (0)) ... 1
> xx: (-1 < (uint_least8_t) 0) ... 0
> 
> I then checked the definition and (mis-)read the corresponding
> standard.
> 
> After some more checking, the problem seems to come from integer
> promotion with `(uintX_t)0' constructs (x<32); and not UINTx_C macros.

Right.

We used to have a bug in UINT{8,16}_C macros (more narrow than int).
We used to add U suffix, which changed results of integer promotion,
but that was fixed in current:

http://mail-index.netbsd.org/source-changes/2010/05/29/msg010475.html

-uwe