headers
Joel E. Denny | 2 Jul 00:23

inttypes.h error for Bison

I get this error for C++ test cases in Bison from CVS:

-----------------------------------
In file included from /home/jdenny/bison/lib/stdint.h:71,
                 from /usr/local/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../include/c++/4.1.0/bits/postypes.h:49,
                 from /usr/local/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../include/c++/4.1.0/iosfwd:49,
                 from /usr/local/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../include/c++/4.1.0/bits/stl_algobase.h:69,
                 from /usr/local/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../include/c++/4.1.0/bits/char_traits.h:46,
                 from /usr/local/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../include/c++/4.1.0/string:46,
                 from expect2.hh:43,
                 from expect2.cc:59:
/home/jdenny/bison/lib/inttypes.h:44:3: error: #error "This file assumes 
that 'int' has exactly 32 bits. Please report your platform and compiler 
to <bug-gnulib <at> gnu.org>."

% uname -a
Linux slackware 2.6.13 #1 Sat Sep 3 21:11:20 PDT 2005 i686 unknown unknown 
GNU/Linux

% g++ --version
g++ (GCC) 4.1.0
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
PURPOSE.

% echo '#include <inttypes.h>'  > tmp.cc
% g++ -E tmp.cc | grep inttypes.h
# 1 "/usr/include/inttypes.h" 1 3 4
# 26 "/usr/include/inttypes.h" 3 4
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Youngman | 2 Jul 00:54
Picon
Gravatar

Re: inttypes.h error for Bison

On 7/1/07, Joel E. Denny <jdenny <at> ces.clemson.edu> wrote:
> I get this error for C++ test cases in Bison from CVS:

> % uname -a
> Linux slackware 2.6.13 #1 Sat Sep 3 21:11:20 PDT 2005 i686 unknown unknown
> GNU/Linux
>
> % g++ --version
> g++ (GCC) 4.1.0

Thanks for the detailed bug report; what are the values of these C
proprocessor macros on your system when you use the same set of
compiler options as you were using to build Bison?

INT_MIN
INT_MAX
INT32_MIN
INT32_MAX

> In Gnulib's lib/inttypes_.h, if I change all occurrences of INTTYPES_H to
> _INTTYPES_H, which is the macro used in /usr/include/inttypes.h, all Bison
> test cases pass again.

Thanks,
James.
Permalink | Reply | 0 comments |
headers
Joel E. Denny | 2 Jul 02:58

Re: inttypes.h error for Bison

On Sun, 1 Jul 2007, James Youngman wrote:

> Thanks for the detailed bug report; what are the values of these C
> proprocessor macros on your system when you use the same set of
> compiler options as you were using to build Bison?
> 
> INT_MIN
> INT_MAX
> INT32_MIN
> INT32_MAX

I created tmp.c:

---------------------------
#include <inttypes.h>
INT_MIN
INT_MAX
INT32_MIN
INT32_MAX
---------------------------

Using the same compiler options as for building Bison:

---------------------------
% gcc -std=gnu99 -I. -I. -I../lib -I../lib \
-Wall -Wextra -Wno-sign-compare -Wcast-align -Wcast-qual -Wformat \
-Wpointer-arith -Wwrite-strings -Wbad-function-cast -Wmissing-declarations \
-Wmissing-prototypes -Wshadow -Wstrict-prototypes -Werror -E tmp.c \
| tail -4
(-2147483647 - 1)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bruno Haible | 2 Jul 03:44

Re: inttypes.h error for Bison

Joel E. Denny wrote:
> Using the same compiler options as for building Bison:
> 
> ---------------------------
> % gcc -std=gnu99 -I. -I. -I../lib -I../lib \
> -Wall -Wextra -Wno-sign-compare -Wcast-align -Wcast-qual -Wformat \
> -Wpointer-arith -Wwrite-strings -Wbad-function-cast -Wmissing-declarations \
> -Wmissing-prototypes -Wshadow -Wstrict-prototypes -Werror -E tmp.c \

gnulib does not support -Werror in general. Using -Werror may work on some
particular platforms, under some particular circumstances. But it general
it is not an achievable to goal to avoid _all_ warnings in _all_ circumstances.
Especially if you are asking for tons more warnings, as you do above.

Can you report a gnulib malfunction when -Werror is not used?

Bruno
Permalink | Reply | 0 comments |
headers
Joel E. Denny | 2 Jul 03:55

Re: inttypes.h error for Bison

On Mon, 2 Jul 2007, Bruno Haible wrote:

> Joel E. Denny wrote:
> > Using the same compiler options as for building Bison:
> > 
> > ---------------------------
> > % gcc -std=gnu99 -I. -I. -I../lib -I../lib \
> > -Wall -Wextra -Wno-sign-compare -Wcast-align -Wcast-qual -Wformat \
> > -Wpointer-arith -Wwrite-strings -Wbad-function-cast -Wmissing-declarations \
> > -Wmissing-prototypes -Wshadow -Wstrict-prototypes -Werror -E tmp.c \
> 
> gnulib does not support -Werror in general. Using -Werror may work on some
> particular platforms, under some particular circumstances. But it general
> it is not an achievable to goal to avoid _all_ warnings in _all_ circumstances.
> Especially if you are asking for tons more warnings, as you do above.
> 
> Can you report a gnulib malfunction when -Werror is not used?

I have the same trouble without -Werror.  I'm not encountering a warning 
that's being treated as an error.  I'm encountering a #error in Gnulib's 
lib/inttypes_.h.
Permalink | Reply | 0 comments |
headers
Joel E. Denny | 2 Jul 04:08

Re: fprintf -> YYFPRINTF

On Fri, 29 Jun 2007, Bob Smith wrote:

> Using bison 2.3 to generate a parser which runs under Windows, I browsed the
> .C file which bison generates and noticed that I wasn't seeing all of the
> messages in the output that bison generates, e.g.
> 
> Reducing stack by rule 6 (line 122):
>    $1 = nterm Stmt ()
> 
> Then I noticed that there are three places in the .C file generated by bison
> where fprintf is used (two in the body of yy_reduce_print and one in the
> #define for YY_LOCATION_PRINT).  To make it easier to redirect those calls, it
> would be helpful if those names were changed to YYFPRINTF or some other
> redefinable name.

Thanks for the report.

yy_reduce_print is fixed in CVS.

YYFPRINTF is defined only when YYDEBUG is true, but YY_LOCATION_PRINT does 
not have this dependency.  Moreover, YY_LOCATION_PRINT is already 
redefinable.  Thus, I think it may be best to leave it as is.

I just noticed that fprintf is used in a section in glr.c where YYFPRINTF 
seems better.  Unfortunately, this section is guarded by #ifdef YYDEBUG 
rather than the usual #if YYDEBUG.  Surely this is a mistake.  I committed 
the following to fix this:

Index: ChangeLog
===================================================================
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bruno Haible | 2 Jul 04:15

Re: inttypes.h error for Bison

Joel E. Denny wrote:
> I have the same trouble without -Werror.

OK, then can you please - as always in a bug report - tell how to
reproduce the problem?
  - Which platform?
  - Which version of gcc?
  - Bison from CVS HEAD, then "./bootstrap", right?
  - How did you configure it?

Bruno
Permalink | Reply | 0 comments |
headers
Joel E. Denny | 2 Jul 04:23

Re: inttypes.h error for Bison

On Mon, 2 Jul 2007, Bruno Haible wrote:

> OK, then can you please - as always in a bug report - tell how to
> reproduce the problem?
>   - Which platform?
>   - Which version of gcc?

You must have missed the first message in this thread:

  http://lists.gnu.org/archive/html/bug-gnulib/2007-07/msg00008.html

>   - Bison from CVS HEAD, then "./bootstrap", right?

Yes.

>   - How did you configure it?

Either:

  ./configure
  ./configure --enable-gcc-warnings
Permalink | Reply | 0 comments |
headers
Bruno Haible | 2 Jul 05:00

Re: inttypes.h error for Bison

Joel E. Denny wrote:
> >   - Bison from CVS HEAD, then "./bootstrap", right?
> 
> Yes.
> 
> >   - How did you configure it?
> 
> Either:
> 
>   ./configure
>   ./configure --enable-gcc-warnings

The latter doesn't count, since it enables -Werror. But without
-enable-gcc-warnings I reproduce the error. The problem is that gnulib's
inttypes_.h heavily relies on the INT*_MAX, INT*_MIN, UINT*_MAX macros
from <stdint.h>, but <stdint.h> does not define these macros in C++ mode if
__STDC_LIMIT_MACROS is not defined.

It is not clear to me how we can fix this. In the meantime, you can,
as a workaround, use CPPFLAGS=-D__STDC_LIMIT_MACROS .

Bruno
Permalink | Reply | 0 comments |
headers
Joel E. Denny | 2 Jul 06:50

Re: inttypes.h error for Bison

On Mon, 2 Jul 2007, Bruno Haible wrote:

> The problem is that gnulib's
> inttypes_.h heavily relies on the INT*_MAX, INT*_MIN, UINT*_MAX macros
> from <stdint.h>, but <stdint.h> does not define these macros in C++ mode if
> __STDC_LIMIT_MACROS is not defined.
> 
> It is not clear to me how we can fix this. In the meantime, you can,
> as a workaround, use CPPFLAGS=-D__STDC_LIMIT_MACROS .

Thanks.  Could Gnulib's lib/stdint_.h define __STDC_LIMIT_MACROS for C++?

If this problem requires a change in Bison, I'll leave it to someone like 
Paul Eggert who understands this stuff better than I do.
Permalink | Reply | 0 comments |

Gmane