Re: problems with c89 and c++ on z/OS

[James Tison]

Werner,

First, let me disclaim all statements here: I do not speak for IBM, these
are my own observations.

Second, to understand the philosophical bent of the z/OS Unix System
Services shell & utilities implementation, you need to refer to the Open
Group's Single Unix Standard, Version 2. This is the certification that was
targeted (and acheived) by the implementors of USS so that they could
obtain the Unix brand. Many of your answers will be found here, with a
little extrapolation.

Thirdly, I've numbered your questions so I can respond numerically to them
here.

1) SUS V2 is the reason for the strange warnings here. See their definition
for the "trap" shell built-in. Note carefully that SIGPIPE is not defined
by number. "trap SIGPIPE" certainly works without errors.

2) I know of no way to make "c89" preferred over "cc". I'd suppose running
config.guess and config.sub, then parsing out the value, would be the thing
to do here, and set CC accordingly. It's lame, but it works. Again, I point
you to SUS V2 ... "cc" is marked "(LEGACY)", and we all know that LEGACY
== BAD :-)

3) Neither -v nor -V means "show me your version". -v emits JCL what the
compiler front end would emit in comparable JCL (don't go there), and -V
means "emit the listing to stdout". Neither of these switches is defined in
the SUS. You are correct: all four compiler front-ends eventually call the
same compiler.

4) The default source file suffix is controlled by a set of environment
variables. To force the "c++" front end to accept files suffixed in ".cc",
you need to export/set _CXX_CXXSUFFIX=cc -- this is the only other way I
know of than to alter CXXFLAGS. Note that there are three sets of each
environment variable depending on the front end in use: _C89 is the prefix
for the c89 f/e, _CC is the prefix for the cc f/e, and _CXX is the prefix
that affects both c++ and cxx.

5) I guess -Wc,HALT(4) must not have done this for you. I have no other
suggestions, since I don't have a reference copy of the ISO C standard
document. This compiler has been the subject of many bug reports. We might
have one here. 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.

Thanks,
--Jim--
James S. Tison
Senior Software Engineer
TPF Laboratory / Architecture
IBM Corporation
+1 203 486-2835 (voice/fax)
address@hidden


                                                                                
                                                
                      Werner LEMBERG                                            
                                                
                      <address@hidden>             To:       address@hidden     
                                              
                                               cc:       James 
Tison/Poughkeepsie/address@hidden, Michael                            
                      07/02/2002 03:06          
MacIsaac/Poughkeepsie/address@hidden                                            
     
                                               Subject:  problems with c89 and 
c++ on z/OS                                      
                                                                                
                                                
                                                                                
                                                
                                                                                
                                                




Here a list of problems with autoconf on z/OS, using native C and C++
compilers.  AFAIK, g++ hasn't been ported (yet).

 1 . Perhaps a cosmetic thing only: The value `13' in the signal list
    for `trap' causes a warning message about an `unusual trap signal'
    or something similar.  I've checked the list for signals for z/OS
    against my Linux box; the used values in autoconf are the same.
    Perhaps it is a good idea to redirect the output to /dev/null to
    suppress this warning message.

    Mike, James, why does SIGPIPE (which is value 13) cause this
    warning?

2  . The ANSI C compiler on z/OS is called c89; cc is a K&R compiler.
    Is there a way to make autoconf automatically prefer c89 over cc
    on this platform to avoid a `CC=c89'?

3  . c89, cc, and c++ (those three forms are only different front ends
    to a single compiler, AFAIK) need an argument (a valid source
    file) to make the switches -v and -V work.  The first line of the
    data returned by -V gives the compiler version.  -v is rather
    useless; the rest of the -V data isn't useful either for autoconf.

    Akim already answered to me that calling both -v and -V with an
    argument will be soon in autoconf.

4  . c++ doesn't accept the suffix `.cc' for C++ files by default.  It
    needs the option `-+' to do that.  I would like to have autoconf
    add that automatically.

5  . The major problem with c89 and cc (but not with c++) on z/OS is
    that a missing header file doesn't produce a fatal return code.
    This is weird, and I don't know whether this is the correct
    behaviour regarding to the C standard... Anyway, it makes a lot of
    autoconf's tests returning incorrect results.

    Looking into the config.log file (which I've already sent to Akim)
    I can see that the test for sys/dir.h correctly finds out that
    this file doesn't exist.  My question now: Is it possible to use
    this double test (preprocessor/compiler) for checking all header
    files?  Alternatively, can autoconf be forced to do that?
    Ideally, autoconf should do that automatically if running on the
    z/OS platform.

    BTW, the missing header file in question is `stdint.h'.


      Werner