bison-patches
[Top][All Lists]
Advanced

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

Re: Reject invalid values for parse.lac in C++ skeleton lalr1.cc


From: Adrian Vogelsgesang
Subject: Re: Reject invalid values for parse.lac in C++ skeleton lalr1.cc
Date: Mon, 20 Jan 2020 23:48:18 +0000
User-agent: Microsoft-MacOutlook/10.10.b.190609

Hi Akim,

> Too many "rejects", and I guess "values".
> Rely on the default values here, pass only the first argument.
thanks for catching those. I fixed both of them in the attached patch and also 
updated the PR on Github

From: Akim Demaille <address@hidden>
Date: Sunday, 19 January 2020 at 21:32
To: Adrian Vogelsgesang <address@hidden>
Cc: "address@hidden" <address@hidden>, Hans Åberg <address@hidden>
Subject: Re: Reject invalid values for parse.lac in C++ skeleton lalr1.cc

Hi Adrian,

> Le 19 janv. 2020 à 19:41, Adrian Vogelsgesang <address@hidden> a écrit :
>
> Hi,
>
> As reported by Hans Åberg in 
> https://lists.gnu.org/archive/html/bug-bison/2020-01/msg00021.html<https://lists.gnu.org/archive/html/bug-bison/2020-01/msg00021.html>,
>  the C++ skeleton lalr1.cc<http://lalr1.cc> accepted arbitrary values for 
> parse.lac.

Yes. Too bad it was caught after the release of 3.5.1, I would have wanted it
to be part of it.

> The attached patch makes sure we only accept the two values “none” and “full” 
> and reject all other values. You can also find this patch on 
> https://github.com/akimd/bison/pull/23<https://github.com/akimd/bison/pull/23>

Great!

> I am not completely convinced this patch is the right solution, though.
> Although not intentionally, version 3.5.0 and 3.5.1 accepted “-Dparse.lac” to 
> enable LAC-support. With this patch, “-Dparse.lac” is rejected again and 
> “-Dparse.lac=full” has to be used instead. Personally, I think we can live 
> with this breaking behavior, In particular given that “-Dparse.lac” was never 
> documented and I would prefer to keep the set of supported parameters as 
> small as possible.
> What do you think?

I would have asked myself exactly the same questions, reaching the same
conclusion. I'll wrap 3.5.2 with this patch in a week or two, just in
case something else pops up. Maybe I'll be done with the CI under Windows,
and more tweaks might be needed.

Thanks for the prompt reaction.

A few minor issues:

> Just as the yacc.c skeleton, the lalr1.cc<http://lalr1.cc> skeleton should 
> reject
> reject invalid value for parse.lac.

Too many "rejects", and I guess "values".


+AT_BISON_CHECK([[-Dparse.lac=none input.y]], [[0]], [], [])
+AT_BISON_CHECK([[-Dparse.lac=none -L c++ input.y]], [[0]], [], [])
+AT_BISON_CHECK([[-Dparse.lac=full input.y]], [[0]], [], [])
+AT_BISON_CHECK([[-Dparse.lac=full -L c++ input.y]], [[0]], [], [])

Rely on the default values here, pass only the first argument.

Cheers!

Attachment: lalr1_reject_invalid_lac.patch
Description: lalr1_reject_invalid_lac.patch


reply via email to

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