[Top][All Lists]

[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: Akim Demaille
Subject: Re: [PATCH 0/3] yacc: compute the best type for the state number
Date: Sun, 6 Oct 2019 14:07:36 +0200

Hi Paul!

> Le 6 oct. 2019 à 03:58, Paul Eggert <address@hidden> 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 write that.
> OK, I did that in the revised patch (first attachment).

Great, thanks!

>>> +typedef int yytype_uint8;
>>>  #endif
>> Wow!  Why do we fallback to int? Is this part where unsigned int == unsigned 
>> short == unsigned char on a little number of architecture?
> Yes, it's for those odd platforms. Though I now see that the above was too 
> extreme: it should have been 'short', not 'int'. Fixed in the first attached 
> patch.
>> The medicine seems worse than the disease to me.
> Well, let's use stronger medicine then :-). I did it in a different way in 
> the first attached patch, so that yytype_uint8 should be 'unsigned char' 
> except for the odd but valid platforms where unsigned char and/or unsigned 
> short do not promote to int.

Ok.  I'm only worried that this might happen a little too often with some 
compilers that we don't have on our radar.

> On compilers not compatible with GCC, the revised patch includes <limits.h> 
> and (if available) <stdint.h> which infringes on the user namespace, but 
> yacc.c already infringes elsewhere for other reasons so that should be OK.

I would think so too.

>> Eventually, all this should move up into c.m4, and be applied to
>> glr.c too.
> Done in the second attached patch. (I haven't installed either patch yet.)

Great!  Feel free to install this.

>> And see what to do about C++ parsers.
> I was hoping our C++ expert could look into that....

:) :) :)

Actually, "Eventually, all this should move up..." really did not mean "Paul, 
please do...", but a note for the future, and I do plan to propagate what we 
did to C++ once the dust has settled down.  It requires some expertise to M-w, 
C-x b lalr1.cc <RET>, C-y :)

reply via email to

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