Re: [PATCH 0/3] yacc: compute the best type for the state number

[Paul Eggert]

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

> > +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. 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.

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

> And see what to do about C++ parsers.

I was hoping our C++ expert could look into that....

0001-Use-least-types-for-integers-in-Yacc-tables.patch
Description: Text Data

0002-Move-the-integer-type-selection-into-c.m4.patch
Description: Text Data