[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC] Use gnulib's stdint.h.
From: |
Bruno Haible |
Subject: |
Re: [RFC] Use gnulib's stdint.h. |
Date: |
Sat, 28 Jun 2008 02:59:26 +0200 |
User-agent: |
KMail/1.5.4 |
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