bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: z/OS enum size pitfall


From: Tim Rühsen
Subject: Re: z/OS enum size pitfall
Date: Tue, 22 Aug 2017 22:43:07 +0200
User-agent: KMail/5.2.3 (Linux/4.12.0-1-amd64; KDE/5.28.0; x86_64; ; )

On Dienstag, 22. August 2017 13:25:55 CEST Ben Pfaff wrote:
> On Tue, Aug 22, 2017 at 04:13:54PM -0400, Daniel Richard G. wrote:
> > Hello list,
> > 
> > I'm writing in to report a bizarre issue with the IBM z/OS XLC compiler
> > that is currently causing one gnulib test to fail (test-timespec), and
> > may present an issue for application code simply because no other
> > compiler does things this way. My hope is to have gnulib integrate a
> > workaround so that this won't bite anyone else.
> > 
> > I have been in contact with IBM about this, originally reporting the
> > issue as a compiler bug. However, they responded that the compiler
> > behavior is conformant to the C standard and that they are less
> > concerned with matching the behavior of other systems than keeping
> > things as-is for the benefit of existing customer application code.
> > 
> > The problem has to do with the implicit integer type that is used for
> > enum symbols. Here is a sample program that illustrates the issue:
> > 
> > --------8<--------
> > #include <stdio.h>
> > 
> > enum { BILLION = 1000000000 };
> > 
> > static const unsigned int BILLION2 = 1000000000;
> > 
> > int main(void) {
> > 
> >     int x = -999999999;
> >     printf("BILLION = %d\n", (int)BILLION);
> >     printf("x = %d\n", x);
> >     printf("x / BILLION = %d\n", (int)(x / BILLION));
> >     return 0;
> > 
> > }
> > -------->8--------
> > 
> > On GNU/Linux and AIX, with a minimal compiler invocation, this
> > program prints
> > 
> >     BILLION = 1000000000
> >     x = -999999999
> >     x / BILLION = 0
> > 
> > However, on z/OS, it prints
> > 
> >     BILLION = 1000000000
> >     x = -999999999
> >     x / BILLION = 3
> > 
> > What happens is that BILLION is implicitly typed as an unsigned int,
> > rather than an int. If you edit the code above to use BILLION2 instead
> > of BILLION, you'll see the same result on GNU/Linux.
> 
> It's odd that they claim that this conforms to the C standard.  C11
> says, in section 6.4.4.3 "Enumeration constants":
> 
>     An identifier declared as an enumeration constant has type int.
> 
> It also says in section 6.7.2.2 "Enumeration specifiers":
> 
>     The identifiers in an enumerator list are declared as constants that
>     have type int and may appear wherever such are permitted.
> 
> This seems pretty clear to me, so I wonder how this interpretation
> arises.

Do you know to which C standard the XLC compiler complies to ?

C99, 6.7.2.2p4 says

    Each enumerated type shall be compatible with char, a signed integer type, 
or an unsigned integer type. The choice of type is implementation-defined,108) 
but shall be capable of representing the values of all the members of the 
enumeration.

Regards, Tim

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

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