[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: Paul Eggert
Subject: Re: [PATCH 0/3] yacc: compute the best type for the state number
Date: Wed, 2 Oct 2019 06:58:35 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

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.

reply via email to

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