> On 26 Oct 2019, at 09:05, Akim Demaille wrote:
>
>> Le 25 oct. 2019 à 18:13, Paul Eggert a écrit :
>>
>> On 10/25/19 7:15 AM, Théophile Ranquet wrote:
>>>
>>> This sounds interesting and I would love reading what people have to
>>> say about this. However, I have failed at finding any such
> Le 25 oct. 2019 à 18:13, Paul Eggert a écrit :
>
> On 10/25/19 7:15 AM, Théophile Ranquet wrote:
>>
>> This sounds interesting and I would love reading what people have to
>> say about this. However, I have failed at finding any such discussion
>> or source. Could you perhaps share a few po
On 10/25/19 7:15 AM, Théophile Ranquet wrote:
This sounds interesting and I would love reading what people have to
say about this. However, I have failed at finding any such discussion
or source. Could you perhaps share a few pointers?
I don't know of a good central email thread about this, b
Hi Paul,
On Tue, Oct 1, 2019 at 10:35 AM 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 chec
> On 7 Oct 2019, at 07:15, Akim Demaille wrote:
>
>> Le 2 oct. 2019 à 15:58, Paul Eggert a écrit :
>>
>> On 10/1/19 10:27 PM, Akim Demaille wrote:
>>> I don't understand why you shy away from -128 and -32768 though.
>>
>> The C Standard doesn't guarantee support for -128 and -32768. This
>>
The C Standard doesn't guarantee support for -128 and -32768. This originally
was for ones' complement machines such as the Unisys ClearPath Dorado
enterprise servers (still in use via firmware translation to Intel Xeon, and
they have a C compiler),
Are they still used in production for progr
Hi Paul,
> Le 2 oct. 2019 à 15:58, Paul Eggert a écrit :
>
> On 10/1/19 10:27 PM, Akim Demaille wrote:
>> I don't understand why you shy away from -128 and -32768 though.
>
> The C Standard doesn't guarantee support for -128 and -32768. This originally
> was for ones' complement machines such
On 10/6/19 4:57 AM, Akim Demaille wrote:
With the appended commits, the CI is green again, and I was able to push my
other changes.
Thanks. I reproduced the GCC 4.8 problem and installed a patch that works around
it without casts (see first attached patch).
"\"".c:1102:41: error
Hi Kaz,
Thanks for your input in this thread!
> Le 1 oct. 2019 à 20:40, Kaz Kylheku a écrit :
>
> 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 th
Hi Paul!
> Le 6 oct. 2019 à 03:58, Paul Eggert a écrit :
>
> On 10/5/19 7:41 AM, Akim Demaille wrote:
>
>> Maybe you want to extend the notes you added to NEWS. Including
>> the bits about limits.h and stdint.h. Maybe that should also make
>> its way into the doc, yet I wouldn't know where to
> Le 5 oct. 2019 à 09:28, Akim Demaille a écrit :
>
> I can't wait: these errors are blocking from me from pushing other changes
> that I was about to send.
With the appended commits, the CI is green again, and I was able to push my
other changes.
commit 4246cd81df3101b1abef3f5914f6b3fa7d1
On 10/5/19 7:41 AM, Akim Demaille wrote:
Why have they chosen this? I guess the point is speed.
Yes, typically these machines are not byte-addressable and it's faster to make
every integer the same size. This is sort of the "BCPL variant" of C, which the
C standard allows.
Maybe you want
> Le 5 oct. 2019 à 11:21, Paul Eggert a écrit :
>
> On 10/1/19 1:35 AM, Paul Eggert wrote:
>> Actually those arrays use int_fast16_t not int16_t, as C99/C11/C18 does not
>> require support for int16_t. It could well be more efficient for them to use
>> int_least16_t instead, for better cachi
> Le 5 oct. 2019 à 12:30, Paul Eggert a écrit :
>
> On 10/5/19 3:07 AM, Akim Demaille wrote:
>
>>> This is a bug in Clang, as both operands of ? are ptrdiff_t. You might try
>>> filing a bug report with the Clang folks.
>> Maybe the error in actually in the division by the unsigned and the
I installed the attached patch, which should work around the clang 8 bug. At
least, it fixes things on Fedora 30, which has clang version 8.0.0 (Fedora
8.0.0-3.fc30).
>From e69b47cd189d7eb45668acce4cf17815401bf2a5 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sat, 5 Oct 2019 03:41:53 -0700
Su
On 10/5/19 3:07 AM, Akim Demaille wrote:
This is a bug in Clang, as both operands of ? are ptrdiff_t. You might try
filing a bug report with the Clang folks.
Maybe the error in actually in the division by the unsigned and the diagnostic is wrong.
Although that's possible, it'd still be a C
On 10/5/19 3:13 AM, Akim Demaille wrote:
-ARGMATCH_DEFINE_GROUP(report, enum report);
+ARGMATCH_DEFINE_GROUP(report, enum report)
It looks ugly to me eyes. How about I change ARGMATCH_DEFINE_GROUP so that it finishes with a function prototype, for instance, and we restore that semicolon?
Feel
> Le 5 oct. 2019 à 10:48, Paul Eggert a écrit :
>
> -ARGMATCH_DEFINE_GROUP(report, enum report);
> +ARGMATCH_DEFINE_GROUP(report, enum report)
It looks ugly to me eyes. How about I change ARGMATCH_DEFINE_GROUP so that it
finishes with a function prototype, for instance, and we restore that
> Le 5 oct. 2019 à 10:50, Paul Eggert a écrit :
>
> On 10/5/19 12:28 AM, Akim Demaille wrote:
>> I can't wait: these errors are blocking from me from pushing other changes
>> that I was about to send.
>
> Thanks for fixing that. I don't want to block you, and please feel free to
> revert or
Hi Paul,
Thanks for the quick response!
> Le 5 oct. 2019 à 10:48, Paul Eggert a écrit :
>
> On 10/3/19 10:02 PM, Akim Demaille wrote:
>
>> I'm going back to Clang 3.3 and GCC 4.6. That's all I managed to set up on
>> Travis. I would also like to try tcc, but only to run the tests, not build
On 10/1/19 1:35 AM, Paul Eggert wrote:
Actually those arrays use int_fast16_t not int16_t, as C99/C11/C18 does not
require support for int16_t. It could well be more efficient for them to use
int_least16_t instead, for better caching
Attached is a proposed patch to implement this for Bison. Th
On 10/5/19 12:28 AM, Akim Demaille wrote:
I can't wait: these errors are blocking from me from pushing other changes that
I was about to send.
Thanks for fixing that. I don't want to block you, and please feel free to
revert or amend any of my changes. I don't know C++ and don't particularly
On 10/3/19 10:02 PM, Akim Demaille wrote:
I'm going back to Clang 3.3 and GCC 4.6. That's all I managed to set up on
Travis. I would also like to try tcc, but only to run the tests, not build
bison itself. Travis also supports MSVC; when I feel brave enough, I'll see if
I can use it for Bi
Hi Paul,
> Le 4 oct. 2019 à 07:02, Akim Demaille a écrit :
>
>>> Old compilers choke on the current code in master, we have to stop and
>>> focus on this first.
>>
>> I can help with that if you'll give me advice about how old to worry about
>> (as long as it's not before GCC 3.4.3 :-).
>
>
Hi!
> Le 3 oct. 2019 à 20:20, Paul Eggert a écrit :
>
> On 10/2/19 11:28 PM, Akim Demaille wrote:
>
>> Please, in the future, make smaller commits, per topic.
>
> Yes, I'll try to split things up better.
Thanks.
>> And run the test suite with an old compiler too.
> How old? Are we backward
Hi Paul,
> Le 3 oct. 2019 à 20:20, Paul Eggert a écrit :
>
> On 10/2/19 11:28 PM, Akim Demaille wrote:
>
>> But I see you already pushed it, although there are things I would have
>> liked to discuss first. Also, we now have failures in the history of master
>> and maint, which I strive to a
On 10/2/19 11:28 PM, Akim Demaille wrote:
But I see you already pushed it, although there are things I would have liked
to discuss first. Also, we now have failures in the history of master and
maint, which I strive to avoid. And the CI is red currently.
Sorry, I'm so rusty at Bison develo
Hi Paul,
> Le 3 oct. 2019 à 02:15, Paul Eggert a écrit :
>
> On 10/1/19 10:27 PM, Akim Demaille wrote:
>> Let's start from this to finish the changes wrt state types
>
> I went through the skeletons and got rid of unsigned types as best I could,
> and installed the attached patch.
This is mas
On 10/1/19 10:27 PM, Akim Demaille wrote:
Let's start from this to finish the changes wrt state types
I went through the skeletons and got rid of unsigned types as best I
could, and installed the attached patch. This also removes some casts
that I think are no longer needed. (It also adds cas
On 10/2/19 10:55 AM, Kaz Kylheku wrote:
Over time, POSIX has invented new identifiers that didn't follow
any namespace pattern. Or they suddenly invented new namespace
prefixes, unpredictably. We've survived.
To be fair, they've largely done this only when you include a POSIX header.
If some
On 2019-10-01 22:27, Akim Demaille wrote:
Apparently like Kaz, I like to name my types *_t, so I'd be happy with
yy_state_t (scalars) and yy_state_least_t/yy_small_state_t (arrays)
The claiming of _t by POSIX is largely bunk.
Here is one counterargument:
1. Every finite string has the empty s
On 10/1/19 10:27 PM, Akim Demaille wrote:
I don't understand why you shy away from -128 and -32768 though.
The C Standard doesn't guarantee support for -128 and -32768. This originally
was for ones' complement machines such as the Unisys ClearPath Dorado enterprise
servers (still in use via f
> On 2 Oct 2019, at 00:43, Paul Eggert wrote:
>
> However, we should avoid unsigned types that are 'unsigned' or wider, as they
> have too many issues. I doubt whether there are practical uses of Bison with
> more than INT_MAX states; but if there are, we should use ptrdiff_t to count
> stat
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
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
> 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 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 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 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 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
Hi Tom,
This should address your concern.
Hi Paul,
I need your expertise here, if you have some time.
Currently we use the "best" integral type for tables, including those
storing state numbers. However the variables used in yyparse (and its
dependencies such as yy_stack_print) use a mixture o
41 matches
Mail list logo
