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 <[EMAIL PROTECTED]>
* m4/inttypes.m4 (gl_INTTYPES_H): Define __STDC_LIMIT_MACROS in C++
mode, when inttypes.h comes from gnulib.
Reported by Joel E. Denny <[EMAIL PROTECTED]>.
*** 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
