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

[Akim Demaille]

Hi Paul,

> Le 2 oct. 2019 à 15:58, Paul Eggert <address@hidden> a écrit :
> 
> 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),

Wow!  I was unaware of this.  Ain't it this kind of machines that is still in 
use to run ancient COBOL programs?  Are they still used in production for 
programs written in C?

> 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

it states:

        The C standard also states that for sign and magnitude and two's 
complement, the value with sign bit 1 and all value bits zero can be a trap 
representation or a normal value.

Wow.  I was completely unaware of the existence of "trap values"...  Thanks!

> Bison should support the current C standard (who knows? maybe some 
> Bison-generated code will run on those Unisys mainframes :-)

Too bad programs don't have stickers to put on their backpack when they go to 
exotic places!

> and so I stuck with the standard values.

Sure.  Thanks for explaining!


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

I'll do that, when we drop the pens for the rest of these changes.

And yes, Kaz, I am perfectly aware that POSIX reserves yy_* for Yacc, but I was 
referring to the rest of their world :)