[Octave-bug-tracker] [bug #60586] type 'yysymbol_kind_t' violates the C++ One Definition Rule'

[John W. Eaton]

Follow-up Comment #8, bug #60586 (project octave):

Sorry for the delay.  I thought I would be able to look at this problem on
Friday and that it would be simply a matter of submitting a bug report for
bison.  But the more I looked at it, I couldn't be sure whether the bug was in
bison or gcc.

We can't easily use the api.namespace definition because even though Octave
compiles the generated parser files using a C++ compiler, we are still using
the C interface files that bison generates, not the C++ interface files. 
Maybe we can switch to using the C++ interface for bison-generated parsers in
the future, but that's not a change I want to tackle now.

In the generated files, yysymbol_kind_t is an enum and a typedef for enum
yysymbol_kind_t (C!).  The declaration of the enum is different in the
generated oct-parse.cc and oct-tex-parser.cc files.  But in each case, it is
only used internally in the generated parser file and in argument lists of
some static functions.  So I don't see how multiple declarations like that
could cause trouble.  Is the GCC warning wrong?  What symbol is actually
defined multiple times here?

The problem can be avoided if the api.prefix is applied to yysymbol_kind_t. 
Doing that in the same way as other yy symbols means adding a preprocessor
macro to the generated parser files like this:


#define yysymbol_kind_t octave_symbol_kind_t


Maybe bison should be fixed to do that.  It should only require adding the
line


#define yysymbol_kind_t  ]b4_prefix[symbol_kind_t


to the bison source file data/skeletons/glr.c (and maybe other skeleton files
in that directory).

But even if that change is made to bison, or if the gcc warning turns out to
be incorrect and is eliminated in the future, we would probably still want to
work around it until a fix is widely available.  So, I checked in the
following changeset for Octave:

http://hg.savannah.gnu.org/hgweb/octave/rev/7f339da6cabd

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?60586>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/