Re: Bison 1.30f

[Hans Aberg]

At 16:01 -0800 2001/12/17, Paul Eggert wrote:
>> Date: Sun, 16 Dec 2001 11:36:07 +0100
>> From: Hans Aberg <address@hidden>
>
>> first you said
>> >Also, strictly speaking it is required for POSIX conformance.
>> >POSIX 1003.1-2001 says:
>> >
>> >   Conforming applications shall not use names beginning in yy or YY
>> >   since the yacc parser uses such names. Many of the names appear in the
>> >   final output of yacc, and thus they should be chosen to conform with
>> >   any additional rules created by the C compiler to be used. In
>> >   particular they appear in #define statements.
>>
>> and later you say:
>>
>> >> As for the real C++ support, I think that names yyfoo should become
>> >> yy::foo, and YYFOO macro names should as far as possible be
>>eliminated and
>> >> replaced by yy C++ names. For example, in C++, one might replace
>> >>   # define        help_key        258
>> >> by
>> >>   const int help_key = 258;
>> >> which would make use of fewer macros.
>> >
>> >For C, this would contradict the POSIX standard, which requires that
>> >the symbols be visible to the preprocessor.  It would also break some
>> >real code.
>
>I don't see why these two quotes are contradictory.  The first quote
>is about internal names in the generated code, which must begin with
>yy or YY (in both C and C++, since they would otherwise run afoul of
>preprocessor macros).  The second quote is about names that are put
>into y.tab.h; they aren't internal.

I did not mention about contradictions: I do not see how you infer that the
Yacc program must start the names in the generated parser with yy or YY, or
that names be visible to the preprocessor; to me, it says that other
programs should not use them as the Yacc program may use them. Also, C++
isn't (I take it) part of POSIX, so whatever POSIX says about macros under
C, it is not valid under C++.

  Hans Aberg