[Top][All Lists]

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

Re: Bison 1.30f

From: Akim Demaille
Subject: Re: Bison 1.30f
Date: 10 Dec 2001 11:25:29 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service)

| >Sorry but I won't change this.  Teach your compiler how to use `/'.  I
| >know on Mac CodeWarrior works properly, GCC too etc.  There is
| >certainly an option to educate it.
| I am not sure what you are saying here: There is, what I know, no standard
| way to interpret a "/" in a C/C++ #include filename. I know of no option to
| educate my compiler to translate between local (like MacOS pre-X) and UNIX
| filename paths.

I mean that Bison is part of the GNU system, and as such it aims at
POSIX hosts.  We do try to help other system, but as long as it
doesn't impact on the code.  In the present case, it does.

I am very surprised that your IDE cannot adjust / into :.

| By contrast, it is very easy to alter the file access search paths: The
| solution seems to be to view "intl/" as a kind of library directory, so it
| should be added to the library search path, and then one should use
|   #include <libgettext.h>
| in the sources (system.h).

I know that, but I do fear picking up some wrong file.  I much prefer
using qualified path in includes.

Nonetheless, if you really have no means to have your compiler speak
Unix, then OK, I'll do that.  But it's against the rules of the GNU

| - I got the following:
| Link Error   : multiply-defined 'error_one_per_line' (data)
| Defined in error.c
| Defined in complain.c


| I took out the complain.c duplicate. It then compiled, and so did the Bison
| generated parser in my test.
| - If you have time, I think you should change the YYSTACK_USE_ALLOCA mess
| in bison.simple. It seems that there are three modes
|   YYSTACK_USE_ALLOCA    Bison parser
|   undefined             tries to use alloca if available, otherwise malloc
|   1                     uses alloca
|   0                     uses malloc


| One should then first have:
|   // Check if alloca is avalable: If so,
|      #define YYSTACK_USE_ALLOCA 1
|   else must use malloc
|      #define YYSTACK_USE_ALLOCA 0
| #endif

This is no longer how it works: it now directly defines what it needs
and no longer uses YYSTACK_USE_ALLOCA afterwards.  That's Paul
decision, and if you want to debate about this, do that with him.

But I should emphasize that these are internal details, and as long as
it works...

| Then the next step is to find where alloca/malloc are defined. On most
| platforms, I think one would use:
| # include <alloca.h>
| #else
| #include <stdlib.h>  /* Std C location for malloc. */
| #endif
| Some platforms may have exceptions to this.
| This does not work under C++ because then one should use
|   #include <cstdlib> // Std C++ location for malloc.
| in order to not get malloc into a global namespace. Then one also has to use
|   #define YYSTACK_ALLOC std::malloc
| and similarly for realloc and free.
| Under C++, one should also use
|   #include <cstddef>
|   #define YYSIZE_T std::size_t
| and
|   #include <cstdio>
|   # define YYDPRINTF(Args)                    \
|   do {                                                \
|     if (yydebug)                                      \
|       std::fprintf Args;                              \
|   } while (0)
| Later, one might replace it with
|   #include <ostream>
| and std::cerr, or perhaps std::clog, which is used for logging purposes
| (more buffering allowed, I recall).

I tend to think that if people want to use Bison C parsers with C++,
_they_ have to include the relevant headers.  When Bison outputs C++,
we will include the right headers.  But that's another story.

reply via email to

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