Re: z/OS enum size pitfall

[Ben Pfaff]

On Tue, Aug 22, 2017 at 10:09:22PM -0400, Daniel Richard G. wrote:
> On Tue, 2017 Aug 22 15:01-0700, Ben Pfaff wrote:
> > 
> > I don't know what XLC conforms to.
> >
> > C11 has the same text in 6.7.2.2p4.  The specification for enums has
> > not changed significantly since C89.
> >
> > Paul Eggert already explained the distinction between enumeration
> > constants and enumeration types, so I won't repeat it.
> 
> All the commentary here is greatly appreciated; please excuse my delay
> in replying.
> 
> Here is what IBM said relating to standards:
> 
>     The compiler behavior is correct. The C standard says that the
>     enumerated type can be char, or any signed or unsigned integer type
>     (6.7.2.2#4).
> 
>     The test case uses a default enumsize which is small and for the
>     range of values in the test case it reserves an unsigned int to hold
>     the enumeration values (this is documented in the User's Guide).
> 
>     The conversion rules make the signed into unsigned int (6.3.1.8#1)
>     meaning that expression becomes (unsigned int)x/BILLION because
>     BILLION is an unsigned int;
> 
>     The conversion of -999999999 produces 3294967297 (UINT_MAX +1
>     -999999999) which when divided by 1000000000 produces 3 as the
>     result.
> 
> There was no further qualification of "C standard" in the first
> paragraph. However, the test program still returns 3 when XLC is
> in C99 mode:
> 
>     $ xlc -qlanglvl=stdc99 -o enumsize enumsize.c
>     $ ./enumsize 
>     BILLION = 1000000000
>     x = -999999999
>     x / BILLION = 3
> 
> Now, from what I'm hearing here, it sounds like IBM may be in the wrong---
> and this would be quite convenient, because while they may not be too
> bothered when their interpretation of POSIX et al. is different from the
> rest of the world's, they _will_ care about a red-letter violation of a
> spec they claim to support.
> 
> I can't standards-lawyer my way out of a paper bag, but if someone here
> could provide a line of argument that IBM's enum shenanigans are
> categorically unsupported by the standard, I'll gladly send it on in the
> hope that it'll get the beast to move.

The C99 rationale is even clearer than the text, in section 6.4.4.3
"Enumeration constants":

    Whereas an enumeration variable may have any integer type that
    correctly represents all its values when widened to int, an
    enumeration constant is only usable as the value of an
    expression. Hence its type is simply int.