[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 0/3] yacc: compute the best type for the state number
From: |
Paul Eggert |
Subject: |
Re: [PATCH 0/3] yacc: compute the best type for the state number |
Date: |
Thu, 3 Oct 2019 11:20:36 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0 |
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 development I did not know the current
rules. What CI is that? I don't see it mentioned in
<https://www.gnu.org/software/bison/> or in
<https://savannah.gnu.org/projects/bison/>; should it be?
Please, in the future, make smaller commits, per topic.
Yes, I'll try to split things up better.
And run the test suite with an old compiler too.
How old? Are we backward compatible to (say) GCC 3.4.3? That's the
oldest I have convenient access to, though it's on reaally slow hardware.
The Bison manual says that Bison itself needs only C99, and that
Bison-generated C parsers need only C89 (or C99 for glr) or C++98, but I
don't know how that relates to compiler (and presumably library) version
numbers.
At some point I suppose we should drop support for C89 as it is now more
trouble than it's worth. But that can wait.
I don't want to break the API for the generated locations in C++. At least we
need to talk about this with users.
Yes, that makes sense. Also, if we're going to change the API for line
and column numbers, I suggest we go to a wider type instead of stopping
at 'int'. These days, 'int' and 'unsigned' are both too narrow for some
possible applications of Bison, and the only portable-to-all-modern-C
solutions that are signed are 'intmax_t' and 'long long'. I could go
with either of those.
How can we change the API to switch from 'unsigned' to 'intmax_t' (or to
'long long') without breaking existing apps? I don't have enough C++
expertise to know how to do this in the best way.
Also, I dislike the fact that the examples in the documentation become
more complex for being more robust. I fully agree that examples should
not be too naive, but IMHO going from
if (i == length)
{
length *= 2;
symbuf = realloc (symbuf, length + 1);
}
to
if (bufsize <= i)
{
ptrdiff_t maxsize
= (PTRDIFF_MAX < SIZE_MAX
? PTRDIFF_MAX : SIZE_MAX);
if ((maxsize - 40) / 2 < bufsize)
abort ();
bufsize = 2 * bufsize + 40;
symbuf = realloc (symbuf, bufsize);
if (!symbuf)
abort ();
}
clutters the documentation.
OK, I changed it back, and put in a little note saying "this code
assumes that malloc and realloc calls always succeed" or something like
that. See the first attached patch. The second attachment fixes a lack
of clarity with the documentation of malloc elsewhere, which I noticed
with the first patch.
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 :-).
0001-Simplify-mfcalc-error-handling.patch
Description: Text Data
0002-doc-bison.texi-Table-of-Symbols-Mention-memory-exhau.patch
Description: Text Data
- Re: [PATCH 0/3] yacc: compute the best type for the state number, (continued)
- Re: [PATCH 0/3] yacc: compute the best type for the state number, Akim Demaille, 2019/10/02
- Re: [PATCH 0/3] yacc: compute the best type for the state number, Kaz Kylheku, 2019/10/02
- Re: [PATCH 0/3] yacc: compute the best type for the state number, Paul Eggert, 2019/10/02
- Re: [PATCH 0/3] yacc: compute the best type for the state number, Akim Demaille, 2019/10/03
- Re: [PATCH 0/3] yacc: compute the best type for the state number,
Paul Eggert <=
- Re: [PATCH 0/3] yacc: compute the best type for the state number, Akim Demaille, 2019/10/03
- Re: [PATCH 0/3] yacc: compute the best type for the state number, Akim Demaille, 2019/10/04
- Re: [PATCH 0/3] yacc: compute the best type for the state number, Akim Demaille, 2019/10/05
- Re: [PATCH 0/3] yacc: compute the best type for the state number, Paul Eggert, 2019/10/05
- Re: [PATCH 0/3] yacc: compute the best type for the state number, Akim Demaille, 2019/10/05
- Re: [PATCH 0/3] yacc: compute the best type for the state number, Akim Demaille, 2019/10/06
- Re: [PATCH 0/3] yacc: compute the best type for the state number, Paul Eggert, 2019/10/06
- Re: [PATCH 0/3] yacc: compute the best type for the state number, Paul Eggert, 2019/10/05
- Re: [PATCH 0/3] yacc: compute the best type for the state number, Akim Demaille, 2019/10/05
- Re: [PATCH 0/3] yacc: compute the best type for the state number, Paul Eggert, 2019/10/05