[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bison 1.28b

From: Hans Aberg
Subject: Re: Bison 1.28b
Date: Sat, 4 Aug 2001 13:11:02 +0200

At 12:36 +0200 2001/08/03, Akim Demaille wrote:
>  ftp://alpha.gnu.org/gnu/bison/bison-1.28b.tar.gz   (574 kB)
>  ftp://alpha.gnu.org/gnu/bison/bison-1.28b.tar.bz2  (462 kB)

- I think the new idea of output file extensions dependent on input files
extensions is not good, because the file extensions should normally
identify the language or type of program processing it. In this case, the
input language is essentially the same and the program, Bison, certainly
is. From the practical point of view, many new file extensions means that
one will have to add these as entries when transported over the Internet.
Also, when dealing with say C++, the situation is not as easy as saying
that one always want the header to have .hh and the source .cc, or any
other rule joining them together depending on the single file input

So I think that this should be changed to %source_extension and
%header_extension options that can be put in the .y file. This can be
augmented with new start-up argument commands. The input file should always
have the .y extension.

- I think that the header that Bison writes should have
  #ifndef ...tab.h
  #define ...tab.h
  #endif /* ...tab.h */
written into it, preventing that the header is included twice: In some
setups, this may become a problem otherwise.

Some bugs and problems:

version.texi: 1.28a -> 1.28b

config.hin: If one uses this file for creating a config.h by hand, it
contains lots of strange "#undef" which will screw up the compile:
#undef const
#undef inline
#undef malloc
#undef mbstate_t
#undef off_t
#undef realloc
#undef size_t
Also, it might be great if it included the macros BISON_SIMPLE and BISON_HAIRY.

files.c: stpcpy & strndup does not seem to have prototypes.

xmalloc.c, xstrdup.c, quote.c, quotearg.c, strndup.c: Always includes
<sys/types.h>, despite that this file is not needed. There is a macro
HAVE_SYS_TYPES_H provided by config that can be used.

quotearg.c: When HAVE_MBRTOWC is defined to zero, the macro iswprint
becomes defined twice to those that already have it the ANSI C header

quote.c: Must have
  # include <stddef.h>  /* For the definition of size_t on windows w/MSVC.  */
before <quotearg.h> is included, as the latter header does not define
size_t. Alternatively, the HAVE_STDDEF_H include could be put in the
<quotearg.h> header.

output.c, print.c: I also get the
  Error   : local data >32k
due to the use of many obstack_fgrow1 in output_headers, but we agreed
formerly this was because the compiler is dumb. Also, the platform I use,
MacOS pre-X, is pretty much defunct, so there is no point in doing anything
about it for that reason. Possibly it means that with some compilers one
might experience problems with it.

bison.simple: For use on my platform I had to put in
  #include <alloca.h>
  #include <stdlib.h>
at the beginning of the file, because I was not able to make use of the
alloca mess there, and because the <stdlib.h> seems to be amiss. (I do not
recall why anymore.)
  Also, for use with C++, I had to put in a prototype:
#ifdef __cplusplus
int yyparse(YYPARSE_PARAM_ARG); // Prototype.
which I put right before yyparse.

I also got a couple of warnings:
  Warning : illegal implicit enum conversion from 'int' to 'token_e'
  lex.c line 364   return c;
  Warning : illegal implicit enum conversion from 'int' to 'token_e'
  lex.c line 505   return parse_percent_token ();
  Warning : illegal implicit enum conversion from 'int' to 'token_e'
  reader.c line 465   token_t token = 0;
  Warning : function has no prototype
  stpcpy.c line 38   {
Usually such warnings means that the writer has not yet have time to update
to the code to the 1990 ISO C standard. :-)

Hope this stuff is of some help.

  Hans Aberg

reply via email to

[Prev in Thread] Current Thread [Next in Thread]