bug-autoconf
[Top][All Lists]
Advanced

[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.








reply via email to

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