bug-bison
[Top][All Lists]
Advanced

[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 :-).

Attachment: 0001-Simplify-mfcalc-error-handling.patch
Description: Text Data

Attachment: 0002-doc-bison.texi-Table-of-Symbols-Mention-memory-exhau.patch
Description: Text Data


reply via email to

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