Re: z/OS enum size pitfall

[Daniel Richard G.]

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.

One minor addendum: In reviewing the support ticket, I noticed a
suggestion to use

    #pragma enum(int)

as a workaround, which would probably be more convenient than a compiler
flag (this could go right into config.h). But even though it is supposed
to be equivalent to the ENUMSIZE option, it does not affect the output
of the test program. Seems like another PMR is in order...


--Daniel


-- 
Daniel Richard G. || address@hidden
My ASCII-art .sig got a bad case of Times New Roman.