Re: inttypes.h error for Bison

[Bruno Haible]

Joel E. Denny wrote:

> --- gnulib/lib/stdint_.h      21 Jun 2007 04:39:10 -0000      1.43
> +++ gnulib/lib/stdint_.h      2 Jul 2007 04:22:09 -0000
> @@ -43,6 +43,9 @@
>       in <inttypes.h> would reinclude us, skipping our contents because
>       _GL_STDINT_H is defined.
>       The include_next requires a split double-inclusion guard.  */
> +# if defined __cplusplus && ! defined __STDC_LIMIT_MACROS
> +#  define __STDC_LIMIT_MACROS
> +# endif
>  # @INCLUDE_NEXT@ @NEXT_STDINT_H@
>  #endif
>  
> Will this cause trouble?

It will not cause trouble, but it will not fix the problem either, in general:
On a platform where <stdint.h> is POSIX compliant and <inttypes.h> is not,
this patch will have no effect, and <inttypes.h> will still try to use
INT32_MAX etc. which are not defined.

I'm applying this fix for the general problem.

2007-07-02  Bruno Haible  <address@hidden>

        * m4/inttypes.m4 (gl_INTTYPES_H): Define __STDC_LIMIT_MACROS in C++
        mode, when inttypes.h comes from gnulib.
        Reported by Joel E. Denny <address@hidden>.

*** m4/inttypes.m4      21 Jun 2007 04:39:09 -0000      1.19
--- m4/inttypes.m4      2 Jul 2007 23:23:10 -0000
***************
*** 1,4 ****
! # inttypes.m4 serial 9
  dnl Copyright (C) 2006-2007 Free Software Foundation, Inc.
  dnl This file is free software; the Free Software Foundation
  dnl gives unlimited permission to copy and/or distribute it,
--- 1,4 ----
! # inttypes.m4 serial 10
  dnl Copyright (C) 2006-2007 Free Software Foundation, Inc.
  dnl This file is free software; the Free Software Foundation
  dnl gives unlimited permission to copy and/or distribute it,
***************
*** 144,149 ****
--- 144,165 ----
      AC_REQUIRE([gl_INTTYPES_H_DEFAULTS])
      gl_CHECK_NEXT_HEADERS([inttypes.h])
  
+     dnl Ensure that <stdint.h> defines the limit macros, since gnulib's
+     dnl <inttypes.h> relies on them.  This macro is only needed when a
+     dnl C++ compiler is in use; it has no effect for a C compiler.
+     dnl Also be careful to define __STDC_LIMIT_MACROS only when gnulib's
+     dnl <inttypes.h> is going to be created, and to avoid redefinition 
warnings
+     dnl if the __STDC_LIMIT_MACROS is already defined through the CPPFLAGS.
+     AC_DEFINE([__STDC_LIMIT_MACROS_TRIGGER], 1,
+       [Define to make the limit macros in <stdint.h> visible.])
+     AH_VERBATIM([__STDC_LIMIT_MACROS_ZZZ],
+ [/* Ensure that <stdint.h> defines the limit macros, since gnulib's
+    <inttypes.h> relies on them.  */
+ #if defined __cplusplus && !defined __STDC_LIMIT_MACROS && 
__STDC_LIMIT_MACROS_TRIGGER
+ # define __STDC_LIMIT_MACROS 1
+ #endif
+ ])
+ 
      PRIPTR_PREFIX=
      if test -n "$STDINT_H"; then
        dnl Using the gnulib <stdint.h>. It always defines intptr_t to 'long'.

> > Here we see that there is also a problem in bison:
> > examples/calc++/calc++-scanner.cc is compiled through the command line
> >     g++  -I. -I../../lib -g -O2 ... -c -o calc++-scanner.o calc++-scanner.cc
> > which makes ../../lib/inttypes.h visible, but ../../lib/config.h has never
> > been included.
> 
> I must confess that I don't understand these issues.  The above tests an 
> example from the manual that Bison users should be able to compile after 
> installing Bison.  Do we expect Bison users to use Bison's config.h or to 
> use Gnulib in their parsers?

There's no reason to enforce such a requirement. The calc++-scanner.cc
example is fine as is; only the examples/calc++/Makefile.am is lacking a
custom definition of DEFAULT_INCLUDES that will override automake's default
definition.

Bruno