Re: uint8_t and stdint.h

[Bruno Haible]

Hi Paul,

> >    - Whether C99 requires it or not, does not matter here: The 'glob'
> >      module depends on 'stdint', and the 'stdint' module provides
> >      uint8_t unconditionally (for several years already).
> 
> gl_STDINT_H's tests of uint8_t all depend on UINT8_MAX being defined, which 
> is 
> not true on hosts lacking uint8_t, so stdint won't provide uint8_t merely 
> because a standard-conforming stdint.h lacks uint8_t.

What I meant is that test-stdint.c contains this code (unconditionally):

  uint8_t b1[2] = { UINT8_C (17), UINT8_MAX };
  verify (TYPE_MAXIMUM (uint8_t) == UINT8_MAX);

On all platform we've tested on, since 2006, this worked fine.

gl_STDINT_H is just a heuristic that implements the decision whether to provide
a substitute stdint.h or use the system-provided one.


A propos

  verify (TYPE_MAXIMUM (uint8_t) == UINT8_MAX);

Hmm, should we make this test stronger by verifying that uint8_t is really
exactly 8 bits wide?

  verify (UINT8_MAX == 0xFF);


> We could finesse all this by simply using char instead of uint8_t, since the 
> values in question are all in the range 0..127 on all platforms we know about.

This would produce code maintainability problems. It's good to distinguish
'char' and 'unsigned char', which are used for the elements of strings, from
uint8_t, for use cases such as an arithmetic type or enum value (DT_DIR).

Bruno