Re: Bison 1.30f

[Hans Aberg]

At 12:26 -0800 2001/12/12, Paul Eggert wrote:
>> I get the following output, which is not in the skeleton file:
>>   ...
>>   #include <stdio.h>
>
>I agree that this shouldn't be in the output, as <stdio.h> intrudes on
>the user's namespace.  This is true for both C and C++.

If this is C99 and C99 has namespaces, I wouldn't know (I haven't gotten
this standard yet).

>The manual says "Don't do that" (:-).  Here's a quote from the manual:
>
>`YYSTACK_USE_ALLOCA'
>     Macro used to control the use of `alloca'. If defined to `0', the
>     parser will not use `alloca' but `malloc' when trying to grow its
>     internal stacks. Do _not_ define `YYSTACK_USE_ALLOCA' to anything
>     else.

One can also make sure that the alloca macro is included in the .y file, if
one wants to use alloca. For example,
  #include <alloca.h>
instead of
  #define YYSTACK_USE_ALLOCA

As bison.simple is written, this will work on platforms on which alloca is
a macro.

If one makes my suggested change, adding:
# if YYSTACK_USE_ALLOCA
#  include <alloca.h>           /* add this */
#  define YYSTACK_ALLOC alloca
#  define YYSIZE_T size_t
...
then on platforms which uses a different header name for alloca but where
alloca is a macro, one can merely include that header. That is, instead of
  #define YYSTACK_USE_ALLOCA
one can write
  #include <alloca_foo.h>

>> As for the comment (a little further down):
>> #      include <alloca.h> /* INFRINGES ON USER NAME SPACE */
>> it should probably be
>> #      include <alloca.h> /* MAY INFRINGE ON USER NAME SPACE */
>
>As far as I know, <alloca.h> does infringe on the user name space in
>all cases where <alloca.h> is actually included here.  Do you know of
>a counterexample?

It didn't look like that on mine (MacOS pre-X and old CodeWarrior
compiler), but I do not know what happens with size_t: alloca is macroed to
__alloca, which is a MacOS secret library function.

It is not an important matter, but it is not guranteed to violate namespaces.

>> You have forgotten to pick out some comments, such as:
>>   # ifdef __cplusplus
>>   #  include <cstddef> /* INFRINGES ON USER NAME SPACE */
>>   #  define YYSIZE_T std::size_t
>> as it now does not infringe on namespaces.
>
>Don't the macros defined by <cstddef> infringe on the user namespace?
>For example, doesn't <cstddef> define a macro NULL?  That would
>infringe on the user name space.

Macros do not belong to the C++ language but to the C/C++ preprocessor
language: Macros are expanded by the preprocessor, and then handed over to
the C or C++ compiler.

So no macro can ever be put in a namespace. You can make it violate
namespaces if you for example write
#undef NULL
#define NULL using namespace std
NULL;
but that is not the case of any of the standard C/C++ headers.

Thus, <cstddef> will not add any "using" directives, but <stddef.h> will.
Under C++ all C++ defined identifier names are in the std namespace; if one
adds the <foo.h> C compatibility header, one gets additional copies of
every defined standard identifier in the global "::" namespace via a "using
<name>" directive.

As for the other YYSTACK_USE_ALLOCA stuff, I misunderstood the
construction, because my platform is not mentioned in the bison.simple
alloca test (see the other email).

  Hans Aberg