Re: Bison 1.28b

[Akim Demaille]

>>>>> "Hans" == Hans Aberg <address@hidden> writes:

Hi Hans!

Hans> - I think the new idea of output file extensions dependent on
Hans> input files extensions is not good, because the file extensions
Hans> should normally identify the language or type of program
Hans> processing it. 

I understand what you mean, but anyway it's already a standard to use
.yy for C++ etc.  Cf Automake.

Hans> The input file should always have the .y extension.

Then always use .y, you'll notice no difference ;)



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

Good call, will do.

Hans> Some bugs and problems:

Hans> version.texi: 1.28a -> 1.28b

Groumph, thanks.

Hans> config.hin: If one uses this file for creating a config.h by
Hans> hand, it contains lots of strange "#undef" which will screw up
Hans> the compile: #undef const #undef inline #undef malloc #undef
Hans> mbstate_t #undef off_t #undef realloc #undef size_t 

That's an Autoconf related question, nothing related to Bison.  And
anyway that's only a template, with a std layout.  I don't think it
will ever change, the machinery to instantiate this template is
extremely delicate to write in a portable way.  Making it more evolved
is an unnecessary complication.

Why don't you run configure?  After all Mac OS X should be able to.

Hans> Also, it might be great if it included the macros BISON_SIMPLE
Hans> and BISON_HAIRY.

Agreed, but no.  The GNU coding standard specify that the user can

        ./configure
        make prefix=/foo

(which is something I can't stand, but GCS are GCS, we have to follow
them), which prevents doing what you suggest.

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

What header defines them on your arch?

Hans> xmalloc.c, xstrdup.c, quote.c, quotearg.c, strndup.c: Always
Hans> includes <sys/types.h>, despite that this file is not
Hans> needed. 

We already had this debate.  If you want to change something, interact
with its author.

/* Written by Paul Eggert <address@hidden> */


Hans> There is a macro HAVE_SYS_TYPES_H provided by config that can be
Hans> used.

Errr, there is no relationship between `despite that this file is not
needed' and `There is a macro HAVE_SYS_TYPES_H'.

Anyway, Autoconf has to be the most portable of all the programs.
Bison doesn't.  Until someone demonstrates that a regular Unix
platform has problems with sys/types.h, it will remain like this, just
like for all the other GNU packages.

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

Paul Eggert.

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

Idem.

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

We'll see then.  When will you upgrade? :)

Hans> bison.simple: For use on my platform I had to put in #define
Hans> YYSTACK_USE_ALLOCA #include <alloca.h> #include <stdlib.h> at
Hans> the beginning of the file, because I was not able to make use of
Hans> the alloca mess there, and because the <stdlib.h> seems to be
Hans> amiss. (I do not recall why anymore.)

I'll have a look, thanks.

Hans> Also, for use with C++, I had to put in a prototype: #ifdef
Hans> __cplusplus int yyparse(YYPARSE_PARAM_ARG); // Prototype.
Hans> #endif which I put right before yyparse.

??? Why?  I've never had this problem.

Hans> I also got a couple of warnings: Warning : illegal implicit enum
Hans> conversion from 'int' to 'token_e' lex.c line 364 return c;
Hans> Warning : illegal implicit enum conversion from 'int' to
Hans> 'token_e' lex.c line 505 return parse_percent_token (); Warning
Hans> : illegal implicit enum conversion from 'int' to 'token_e'

Err...  Are you sure you are using a C compiler?  enum and int in C
are just the same.  Sure it is debatable from the point of view of the
C language definition, but given the current definition, AFAIK, your
compiler is broken.

But I'll have a look, thanks.

Hans> reader.c line 465 token_t token = 0; Warning : function has no
Hans> prototype stpcpy.c line 38 { Usually such warnings means that
Hans> the writer has not yet have time to update to the code to the
Hans> 1990 ISO C standard. :-)

OK, I'll have a look too, thanks!

Hans> Hope this stuff is of some help.

Yep, it does!