On 9/29/19 11:34 AM, Akim Demaille wrote:
As a matter of fact, we used two types:
- most arrays (such as state stack, and its correspondance in the LAC
infrastructure) are using int16_t. A few "temporary" variables also
have this type.
- yystate, which is an intermediate variable, was an
> On 1 Oct 2019, at 10:35, Paul Eggert wrote:
>
> In other GNU applications, we've been moving away from using unsigned types
> due to their confusing behavior (particularly when comparing signed vs
> unsigned), and because modern tools such as 'gcc -fsanitize=undefined' can
> check for sign
On 2019-10-01 01:35, Paul Eggert wrote:
On 9/29/19 11:34 AM, Akim Demaille wrote:
As a matter of fact, we used two types:
- most arrays (such as state stack, and its correspondance in the LAC
infrastructure) are using int16_t. A few "temporary" variables also
have this type.
- yystate, w
On 2019-10-01 06:53, Hans Åberg wrote:
One should note that the unsigned types are required to be 2’s
complement C/C++, unlike the signed ones, cf.
That is untrue by definition, since two's complement is strictly
a mechanism for representing negative values, which the unsigned
types do not do.
> On 1 Oct 2019, at 21:21, Kaz Kylheku wrote:
>
> On 2019-10-01 06:53, Hans Åberg wrote:
>> One should note that the unsigned types are required to be 2’s
>> complement C/C++, unlike the signed ones, cf.
>
> That is untrue by definition, since two's complement is strictly
> a mechanism for rep
On 10/1/19 11:40 AM, Kaz Kylheku wrote:
That said, parser states are more of an enumeration. They are identifiers.
We shouldn't be doing any math on them of this sort.
That may be true in theory, but not in practice. For example, the GLR
skeleton's yyLRgotoState has this line:
int yyr = yy
Hi Paul,
Thanks for the answer! (And thanks to Kaz too)
> Le 1 oct. 2019 à 10:35, Paul Eggert a écrit :
>
> On 9/29/19 11:34 AM, Akim Demaille wrote:
>
>> In my proposal below, I fuse both cases to use a single type,
>> yy_state_num, which is the smallest type that contains the set of
>> sta
Hi Tom,
> Le 27 sept. 2019 à 21:28, Tom Kramer a écrit :
>
> Hello bison bug fixers -
>
> I installed bison 3.4.2 this afternoon. During the process I ran 'make check".
>
> 252 254 255 282 283 284 285 425 430 432 434 435 445 446 447 525 failed. A zip
> file with the logs is attached.
All the
