Hi!
> Le 9 sept. 2021 à 00:32, Paul Eggert a écrit :
>
> On 9/8/21 2:18 PM, Karl Berry wrote:
>> Just an idea that I don't expect you to adopt, but just to mention --
>> you could only institute the breaking change if POSIXLY_CORRECT. That's
>> why POSIXLY_CORRECT exists. -k
>
> I like this id
On 9/8/21 2:18 PM, Karl Berry wrote:
Just an idea that I don't expect you to adopt, but just to mention --
you could only institute the breaking change if POSIXLY_CORRECT. That's
why POSIXLY_CORRECT exists. -k
I like this idea. It insulates us against POSIX decisions and/or
indecisions in thi
This is definitely a change that may break compatibility in some
cases, but it's out of our control: POSIX decided, we just comply.
Just an idea that I don't expect you to adopt, but just to mention --
you could only institute the breaking change if POSIXLY_CORRECT. That's
why POSIXLY_COR
Hi Paul,
Thanks for the quick answer.
> Le 8 sept. 2021 à 08:33, Paul Eggert a écrit :
>
> On 9/7/21 10:31 PM, Akim Demaille wrote:
>> However, I don't see a published version of the POSIX Yacc "specs" that
>> includes these changes.
>
> The next POSIX revision is targeted for 2022, according
On Wed, Sep 8, 2021, at 1:31 AM, Akim Demaille wrote:
> One big problem with the Autotools as of today is that they promote
> the use of macros/build rules for Yacc, not for Bison.
The contract of AC_PROG_YACC is to find something that will generate
parsers from POSIX-compliant input; all three of
