[Top][All Lists]

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

Re: Bison 3.8.2 portability report

From: Akim Demaille
Subject: Re: Bison 3.8.2 portability report
Date: Sun, 10 Oct 2021 18:06:13 +0200

Hi Tom,

> Le 9 oct. 2021 à 21:31, Tom Shields <> a écrit 
> :
> Akim,
> I thought you might be interested in the results of portability testing for 
> the Ox 1.10 release (available yesterday).

Yes, I am.  Thanks a lot for this effort!

> Ox 1.10 has 6 parsers generated by bison 3.8.2, using the skeleton.
> For portability testing, I run the regression tests on each operating systems 
> using each C++ compiler listed below.

This is great!

> The Solaris Studio errors noted below are due to a defect in support for the 
> C++ 2011: a noexcept operator within a noexcept specifier for an overloaded 
> version of std::swap in several header files is the source of the error 
> messages above.  The exact same signature is found in the equivalent GNU & 
> LLVM header files.  As an experiment (on Solaris 11.4), I edited the 
> offending signature in the header files to bypass the problem, which allowed 
> Ox to compile.  Ox then failed to link due to several versions of the C++ 
> std::ostream '<<' operator missing from the C++ library.

Is this a problem?  I'd rather avoid having to work around portability issues 
of C++11 :(

I know by experience how much effort portability requires.

>  - Homebrew GNU C++ 11.2: compile warnings for each parser:
> warning: 'AGC::lexer::glr_stack' has a field 
> 'AGC::lexer::glr_stack::yyerror_range' whose type uses the anonymous 
> namespace [-Wsubobject-linkage]
> warning: 'AGC::lexer::glr_stack' has a field 
> 'AGC::lexer::glr_stack::yystateStack' whose type uses the anonymous namespace 
> [-Wsubobject-linkage]

I am unable to reproduce it on the "Several parsers" test in the test suite 
(after having added -Wsubobject-linkage to the list of warning flags to use).  
I used g++-mp-11 (MacPorts gcc11 11.2.0_1) 11.2.0.

But I can see the configuration.  Indeed we define the glr_stack class in a 
named namespace, but in the *.cc file only, and glr_stack uses glr_stack_item, 
which is defined in the same *.cc, but within an unnamed namespace.

I can see why in general this is dangerous, but in the present case, I don't 
see how it could go wrong: every bit is in the same *.cc file.

We could define glr_stack_item in a named namespace (since it is my 
understanding Tom that you no longer try to have several parsers in the same 
namespace), but it still annoys me because I was happy to limit the number of 
visible symbols exposed by the compilation unit.  In order to help speeding up 


reply via email to

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