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

[Joel Brobecker <brobecker@adacore.com>]

Hi Daniel,

> 2008-06-26  Daniel Jacobowitz  <dan@codesourcery.com>
> 
> 	* Makefile.in (GNULIB_H): Use GNULIB_STDINT_H.
> 	(gdb_stdint_h, gdb_stdint.h, stamp-int): Delete.  Remove
> 	all dependencies on $(gdb_stdint_h).
> 	(distclean): Do not delete gdb_stdint.h.
> 	* acinclude.m4: Do not use stdint.m4.
> 	* configure.ac: Set GNULIB_STDINT_H.  Remove tests for stdint.h,
> 	uintptr_t, and gdb_stdint.h.
> 	* defs.h: Include <stdint.h>.
> 	* gdb_thread_db.h: Assume stdint.h is already included.
> 	* breakpoint.c, findcmd.c, hppa-tdep.c, inf-ptrace.c, proc-service.c,
> 	rs6000-nat.c, spu-linux-nat.c, target.c, win32-nat.c: Do not
> 	include gdb_stdint.h.
> 	* configure, config.in: Regenerate.

Bad luck, I'm seeing a couple of issues on mips-irix, for instance.

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;

  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>.

I can see various ways how we could fix problem #1. The quick and
dirty way that I used to make quick progress was to move the include
for dpd/decimal128.h before the include for defs.h - but this isn't
right, because it's still a risk to have two different versions of
stdint.h included at the same time.  Another way is to transition
libdecnumber to using gnulib/stdint.h, but I am not sure about how
to do that in practice, as I don't think we can make libdecnumber
use stuff from GDB.

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. Although this might be the case for the current
stdint.h files that exist, I don't think there is an explicit
rule against it. Even if not categorized as a bug, perhaps it
would be a worthwhile enhancement, as the documented reason for
including this file is to get a couple of macros:

    #if ! defined __cplusplus || defined __STDC_CONSTANT_MACROS
    
    /* Get WCHAR_MIN, WCHAR_MAX.  */
    # if ! (defined WCHAR_MIN && defined WCHAR_MAX)
    #  include <wchar.h>
    # endif
    
    #endif

Perhaps we could somehow generate the macro definitions ourselves,
which would help avoiding the include. Ideally, gnulib would take
care of that and avoid the include, or we could compute the WCHAR_MIN
and WCHAR_MAX during the GDB configury and define the macros just
before including gnulib/stdint.h.

Does all the above sound pretty kludgy to you too? :-(

-- 
Joel