Re: INTx_C/UINTx_C definitions result type

[Nicolas Joly <njoly%pasteur.fr@localhost>]

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 ...
> >
> >   7.18.4.1 Macros for minimum-width integer constants
> [...]
> > Actually only the smallest version (x < 32) suffers from this and
> > sizeof(INT8_C(0)) = 4 differs from sizeof(int_least8_t) = 1.
> > 
> > Any drawbacks to be expected with the following patch that adds casts
> > for the corresponding types ?
> 
> 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.

> My old copy of ISO C FDIS says
[...]
> Note that the requirement are: "suitable for initializing" in 7.18.4#1
> and "at least the specified width" in 7.18.4.1#1.
> 
> 7.18.4.1#2 says "and type int_leastN_t", which is confusing, but I
> think it's the sloppy wording in #2.

Yepm that's the one which confused me.

> Current draft http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1539.pdf
> seems to clarify that properly:
[...]
> Note in particular that 7.20.4#3 now explicitly talks about integer
> promotions and mandates that the macro could be used in #if.

Right, my patch do indeed breaks this part. Let's forget about it.

Thanks for correcting me.

-- 
Nicolas Joly

Biological Software and Databanks.
Institut Pasteur, Paris.