Re: Bison 1.30f

[Hans Aberg]

At 11:25 +0100 2001/12/10, Akim Demaille wrote:
>| 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.

Are you saying that POSIX specifies how "/" should be interpreted in a
C/C++ #include statement? -- I doubt it; the C++ standard, verses 16.2:2-3,
says:

2 A preprocessing directive of the form
    # include <h-char-sequence> new-line
searches a sequence of implementation-defined places for a header
identified uniquely by the specified sequence between the < and >
delimiters, and causes the replacement of that directive by the entire
contents of the header. How the places are specified or the header
identified is implementation-defined.

3 A preprocessing directive of the form
    # include "q-char-sequence" new-line
causes the replacement of that directive by the entire contents of the
source file identified by the specified sequence between the " delimiters.
The named source file is searched for in an implementation-definedmanner.
If this search is not supported, or if the search fails, the directive is
reprocessed as if it read
    # include <h-char-sequence> new-line


In other words, the C/C++ preprocessor can use pretty much which method it
wants when interpreting filenames.

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

I think that is the common thing for compilers. As for MacOS, it has now
switched to BSD, so it should not matter.

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

I'll just patch it, just as with the other things. You only had one use of it.

>  But it's against the rules of the GNU
>project.

Well, you have to indicate a snapshot from the POSIX standard, indicating
how the C/C++ preprocessor should interpret the filenames, before you can
draw that conclusion.

>| - 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
>
>Correct.
>
>| One should then first have:
>| #ifndef YYSTACK_USE_ALLOCA
>|   // 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.

I do not care about this myself; but if one should have backwards
compatibility, then that is how it should have worked.

Are you saying that one now always gets an error when YYSTACK_USE_ALLOCA is
not defined?

>| Then the next step is to find where alloca/malloc are defined. On most
>| platforms, I think one would use:
>| #if YYSTACK_USE_ALLOCA
>| # 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.

The problem is that under C++, the C compatibility headers <foo.h> adds
  using name;
for the names in the header <foo> are put into the namespace "std". And in
C++, there is no way to cancel that "using" addition.

So if bison.simple under C++ includes the C compatibility headers, there is
no way to correct for this by an inclusion of additional C++ headers.

Therefore, while waiting for the full C++ support, this seems to be a
reasonable thing. -- It does not look that difficult to do.

BTW, should not really bison.simple be named simple.bison, following the
common usage for filename extensions? (That is, it is a file to the Bison
skeleton language.)

  Hans Aberg