Re: [PATCH] Allow Bison-generated C++ parsers to compile with -fno-exceptions.

[Brooks Moses]

Akim,

Thanks for the comments!  And no worries on the delay; I've certainly been
on the "maintainer" side of this sort of delay many times.

Your proposed patch seems reasonable to me, and we could add "magic" for
other compilers (and it also allows people to set YY_EXCEPTIONS directly if
it doesn't do the magic they want).  I can confirm it will work for Clang
as well as GCC.

I'd be happy with either this or a new Bison variable.  However, I think
this way may be a bit better -- it's entirely possible that someone may
write a parser that chooses to either throw an exception or abort depending
on whether exceptions are enabled, so this can be a choice of the person
compiling the parser, as well as a choice of the person writing the parser.

Best,
- Brooks




On Thu, Aug 16, 2018 at 10:33 PM, Akim Demaille <address@hidden> wrote:

>
> > Le 16 août 2018 à 07:36, Akim Demaille <address@hidden> a écrit :
> >
> >> Le 16 août 2018 à 07:22, Akim Demaille <address@hidden> a écrit :
> >>
> >> Would it be acceptable to introduce a new Bison directive to disable
> >> exceptions?  Something like
> >>
> >> %define api.exceptions no
> >
> > Or maybe something like what you proposed, but with
> >
> > #if defined __GNUC__ && !defined __EXCEPTIONS
>
> I’m ambivalent on this.  The use of exceptions or not is clearly
> a design decision of the author of the grammar, not a decision
> left at c++-compile time.  So I tend to prefer a new Bison variable
> to this end.  Unfortunately this variable should have been disabled
> by default when the feature was introduced, but I suppose it’s too
> late now to change the default value.
>
> Setting a Bison variable to disable the support of exceptions
> means more things to know for the users, while something
> like what follows seems to do the right thing, but in a magical
> way, and only for GCC (and I guess clang, which faithfully copies
> all the macros of GCC).
>
>