[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: problems with c89 and c++ on z/OS
From: |
James Tison |
Subject: |
Re: problems with c89 and c++ on z/OS |
Date: |
Tue, 9 Jul 2002 16:27:52 -0400 |
Paul,
No question, the z/OS compiler behaves in a ... uhh ... variant way. I did
file an internal problem report on this subject, and the preliminary
pushback I'm getting indicates I'm going to get another "working as
documented/designed" response. We'll see.
The workaround is to set _<fe>_ACCEPTABLE_RC=0, where <fe>={CC,C89,CXX},
then issue the compile. The default for _ACCEPTABLE_RC is 4, which is
creating the bad behavior. This example is from a z/OS 1.1 system:
---------
/u/jtison$ cat test.c
#include <stdint.h>
int main(int argc, char *argv[]) {
return argc;
}
/u/jtison$ _C89_ACCEPTABLE_RC=0 c89 -c -o test.o test.c
WARNING CBC3296 ./test.c:1 #include file <stdint.h> not found.
FSUM3065 The COMPILE step ended with return code 4.
FSUM3017 Could not compile test.c. Correct the errors and try again.
/u/jtison$ _C89_ACCEPTABLE_RC=0 c89 -c -o test.o test.c;echo $?
WARNING CBC3296 ./test.c:1 #include file <stdint.h> not found.
FSUM3065 The COMPILE step ended with return code 4.
FSUM3017 Could not compile test.c. Correct the errors and try again.
3
/u/jtison$ _CC_ACCEPTABLE_RC=0 cc -c -o test.o test.c;echo $?
WARNING CBC3296 ./test.c:1 #include file <stdint.h> not found.
FSUM3065 The COMPILE step ended with return code 4.
FSUM3017 Could not compile test.c. Correct the errors and try again.
3
----------
>From someone in the compiler lab in Toronto, I got a rather oblique
explanation that "C programmers are supposed to know what they're doing,
and if the failing #include generates cascading errors, then they'll figure
it out from that". I suspect that's probably the final answer I'm going to
get.
Any chance config.guess/config.sub could be called, and set two of the
variants of the _ACCEPTABLE_RC env variable properly when the right
canonical system name comes back?
Regards,
--Jim--
James S. Tison
Senior Software Engineer
TPF Laboratory / Architecture
IBM Corporation
+1 203 486-2835 (voice/fax)
address@hidden
Paul Eggert
<address@hidden To: James
Tison/Poughkeepsie/address@hidden
om> cc: address@hidden,
address@hidden, Michael
MacIsaac/Poughkeepsie/address@hidden
07/03/2002 02:51 Subject: Re: problems with c89
and c++ on z/OS
> From: "James Tison" <address@hidden>
> Date: Tue, 2 Jul 2002 17:25:57 -0400
>
> If someone can quote me chapter and verse from the Standard
> on the required behavior, I'll be happy to file a bug report against it.
Page 163 section 6.10.2 line 1 of the C99 standard says:
Constraints
A #include directive shall identify a header or source file
that can
be processed by the implementation.
The standard requires that every constraint violation must be
diagnosed, so a diagnostic is required from the C compiler if a
program attempts to include a nonexistent header or source file.
There is no requirement that c99 (or c89 or cc) must return a nonzero
error status in this case. However, longstanding tradition is that
nonexistent include files are serious errors, warranting a nonzero
exit status.
Many programs rely on the traditional behavior in order to configure
themselves properly. No program that I know of relies on the other
behavior (where missing include files are not considered to be
errors). So it's not useful for a compiler to depart from the
longstanding tradition here.