Re: [RFC] Use gnulib's stdint.h.

[Bruno Haible <bruno at clisp dot org>]

Hi,

For some context, the message you were replying to is
<http://sourceware.org/ml/gdb-patches/2008-06/msg00513.html>.

Generally the experience we've made with gnulib is:

  * It's wise to include the system headers first, and the application
    headers after that. This minimizes the risk that #defines in the
    application headers make the system headers malfunction. (Examples:
    '#define unused' on Windows, '#define PC' on SVR4 systems, many more ...)

  * Never assume that a particular header has not been included. Assuming
    that, say, <stdio.h> functions are not declared is
      1. a portability problem, because <wchar.h> may need to include <stdio.h>,
         or similar,
      2. a maintainability problem, because when you want to use, say, perror()
         in such a file, you are at a dead end.

Daniel Jacobowitz wrote:
> Joel Brobecker wrote:
> > There are two distinct issues that I have seen so far:
> > 
> >   1. dfp.c includes libdecnumber/dpd/decimal128.h which ends up
> >      including gstdint.h. But before we included decimal128.h, we
> >      had already included defs.h which includes gnulib/stdint.h.
> >      The two files end up colliding.
> > 
> >      For instance, gstdint.h contains:
> >         typedef int16_t    int_least16_t;
> >      
> >      But gnulib/stdint.h also contains:
> >         #define int16_t short int
> >         #define int_least16_t int16_t
> > 
> >      So we end up with the above being rewritten to:
> >         typedef short int short int;

> And if we change libdecnumber to use gnulib's version we'll
> undoubtedly break gcc.

libdecnumber's gstdint.h appears to be generated by the autoconf macro
GCC_HEADER_STDINT - obviously in the hand of the GCC maintainers.

There are basically two ways out:

  a) Make gstdint.h use the types from <stdint.h> if they are present.
     Change
        typedef int16_t    int_least16_t;
     to
        #if !(defined INT_LEAST16_MIN && defined INT_LEAST16_MAX)
        typedef int16_t    int_least16_t;
        #endif

  b) Make gstdint.h override the types from <stdint.h> if they are present.
     Change
        typedef int16_t    int_least16_t;
     to
        #undef int_least16_t
        #define int_least16_t gcc_int_least16_t
        typedef int16_t    int_least16_t;

The first approach is likely to need some additional tweaks for various
platforms, whereas the second approach will work out-of-the-box. But if
the APIs of libdecnumber use the int_least16_t etc. types, the first
approach is better because it does not create two (possibly different)
types for the same thing.

> >   2. ctype/safe-ctype conflict. For instance, cp-support.c includes
> >      safe-ctype.h.  But at the same time, we previously included
> >      defs.h, which itself includes gnulib/stdint.h, which includes
> >      <wchar.h> which includes <ctypes.h>.
> 
> > Problem #2 is a lot more problematic, however. I might argue that
> > this is a actually bug inside gnulib and that gnulib/stdint.h
> > should be generated in a way that avoids including other standard
> > header files.

No. gnulib makes no guarantee that particular headers or symbols are
not defined. For three reasons:
  1. We cannot control the #includes inside system headers.
  2. gnulib turns on _GNU_SOURCE on glibc systems and __EXTENSIONS__ on
     Solaris.
  3. In those places where gnulib could control these extra #includes,
     the price would be sets of #ifdefs that would be too clumsy to be
     maintainable.

The bug is in safe-ctype.h:

  #ifdef isalpha
   #error "safe-ctype.h and ctype.h may not be used simultaneously"
  #endif

Actually I don't see the reason for this #error: safe-ctype.h defines only
uppercase-named macros, and <ctype.h> defines only lowercase-named or
underscore-prefixed macros.

> > ... help avoiding the include. Ideally, gnulib would take
> > care of that and avoid the include

No, gnulib will not make not-include guarantees. See above.

Bruno