"Peter Eisentraut" <peter_e@gmx.net> writes:
> Tom Lane wrote:
>> What bothers me about that is I don't think the C spec mandates the
>> representation width. If we could guarantee that enum typtype_type
>> was 1 byte I'd be all for it.
>
> The width is 4 both for the macro and the enum case. Both
>
> #define TYPTYPE_BASE 'b'
>
> and
>
> enum ... {
> TYPTYPE_BASE = 'b',
>
> effectively generate int constants named TYPTYPE_BASE with decimal value
> 98. So there are no storage advantages either way.
That's not accurate at all. The macro case gives you a constant you can only
use to initialize integer variables and members that are explicitly declared
with some integral type. If we consistently declare them "char" then they'll
be predictably 1 byte long.
The enum case does two things. It defines a syntactic meaning for the label,
*and* it defines a thing "enum typtype" which can be used to define variables
and members. If the latter is used then Tom is saying the standard doesn't
specify what width the variable or member will be.
We could use enum {} to define the labels and then make a rule that all actual
variables should be declared using "char" rather than declaring them as "enum
typtype". But I fear somebody would get that wrong some day. The worst thing
is that it might work on their compiler or it might even work on all compilers
and just silently be causing things to be aligned differently than they
expect.
On the other hand it I don't really think it would cause any problems if
people stored their typtypes in integers. Except for the actual FormData_pg_*
structures the precise alignment doesn't actually matter for anything does it?
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com