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

[Paul Eggert]

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 firmware translation to Intel Xeon, and they have a C 
compiler), as well as for signed-magnitude machines that are no longer in use. 
Nowadays at least in theory this can be useful for debugging implementations on 
two's-complement machines, which can use -32768 as a trap representation, though 
it appears nobody is currently doing that and the next C standard may change in 
this area. See:

Seacord RC. Uninitialized reads: understanding the proposed revisions to the C 
language. ACM Queue. 2017;14(6). https://queue.acm.org/detail.cfm?id=3041020

Bison should support the current C standard (who knows? maybe some 
Bison-generated code will run on those Unisys mainframes :-) and so I stuck with 
the standard values.

> > 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) instead of int and yy_state_num 
> > currently. But we've had disagreements on this regard, yet I don't know where 
> > you stand today (given that here, we're kind of protected by yy_*: POSIX/ISO etc. would be really bad people to start using them.)

In the past I was reasonably strict about avoiding user-defined type names 
ending in "_t", mostly because that suffix is reserved by POSIX, but partly 
because I simply dislike the tradition of the Hungarian notation 
<https://en.wikipedia.org/wiki/Hungarian_notation>. But you're right that 
"yy_*_t" should be safe enough.