Re: Bison 1.28b

[Hans Aberg]

At 15:37 +0200 2001/08/04, Akim Demaille wrote:

#define polemics(x) /* Usually empty argument */

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

polemics(So you say: One should always try to conform to a faulty
standard.) :-)

>Hans> The input file should always have the .y extension.
>
>Then always use .y, you'll notice no difference ;)

But this is the problem: I want to use .y, but be able to choose output
source and header file extensions independently.

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

I don't have it yet -- but you are right, when using GCC on any platform,
this is not a problem. But because GCC does not have a GUI (or IDE,
"Integrated Development Environment), some may still use other compilers.

>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

This kind of comments (as I indicated in the post) only applies when
working it by hand, without "make", etc. It is up to you whether you want
to help such systems. I think that the GNU principle is GNU first, the rest
is extras.

>Hans> files.c: stpcpy & strndup does not seem to have prototypes.
>
>What header defines them on your arch?

None: The files stpcpy.c & strndup.c have special macros that can provide
prototypes within those files via config.h macros.

My impression is that these might be present in some GNU lib-header which
is not present in your distribution. I think the best thing would be to
copy the construction in the stpcpy.c & strndup.c files though.

>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'.

I think that there might: One want to get hold of size_t or something. On
some systems, this whatever is defined in <sys/types.h>, even though by now
there is a ANSI/ISO C standard header that has it. So the correct way would
have been to choose between these two.

>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.

I just tell how it works with the ISO C standard; it is up to you to decide
whether you want to recognize that standard or not. <sys/types.h> is not
standard for UNIX systems, because some are using <sys/times.h>, according
to Harbison & Steele, "C A Ref Manual".

> 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? :)

God knows. I must first get hold of a better computer, with a G3/G4 CPU in
it (I have an old 7200). I think myself that any less than a G4 is likely
to be worthless. Knowing Apple since MacPlus, I think it is wise to wait
until some of those bugs has gone away. They will also need to present some
new hardware models, in preparation for MacOS X being bundled with the
computers they sell (which currently is not the case).

>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.

I think there is a switch whether one wants to require prototypes or not. I
do not know which one is standard C++. Such usage could vary.

>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.

My compiler has a box "Enums are always int", and I made sure it was
checked; those warnings persisted. It might be that implicit conversions
works the one way but not the other (I don't know).

So I would suggest to check those things, because some of those details are
changing. There is a new standard now, C89, and compilers will start to
conform to that. Also, in C++ one is changing some of those details as well.

I have myself decided to stay out of those problems by not relying on some
of those dubious traditional C constructs. (Omitting "return" is another
one. Did you know that C++ now admits "return void"? -- Needed in
templates.)

  Hans Aberg