cameron@usage.csd.oz (Cameron Simpson,Uhmmm..???? Who knows) (09/11/90)
[followups directed to comp.sys.apollo] From article <15434@reed.UUCP>, by minar@reed.bitnet (Nelson Minar,L08,x640,7776519): | I've run into the following constructs in Apollo's standard include files. | The documentation (and the tech rep) both claimed that Apollo's C compiler is | ANSI C. This is born out by the compiler defining __STDC__. The tech rep is wrong. I think the documentation says evasive things like "many ANSI extensions" and so forth. You'll discover that their definition of __STDC__ is also evasive - they define it to 0. | I wouldn't care about the compiler as I have gcc running on the machine. | However, I have to use the header files that came with the machine, and here | is where I have a problem. [...] | unsigned char *_ptr #attribute[aligned(1)]; Others have remarked about the #attribute. At least their lint passes it. Line 37 of our Apollo BSD setjmp.h has extern int sigsetjmp() #options(abnormal); Apollo's lint says: /usr/include/setjmp.h(37): illegal character: 37777777777 (octal) /usr/include/setjmp.h(37): cannot recover from earlier errors: goodbye! Ugly, no? I use lint a lot. I feel bad having #ifdef apollo # ifndef lint # include <setjmp.h> # endif #else # include <setjmp.h> #endif in my global include file. Fortunately I don't use setjmp() much. On the subject of the semiANSIness of the Apollo cc, peering at my a configuration file I have here the following weirdness applied under 10.1. I think most of them still apply under 10.2 (we run it but I haven't checked). - "const" doesn't work. - the ANSI #include files aren't there (limits.h and so forth). - self-referential macros fail, viz #define it(x) (fputs("hi\n",stderr),it(x)) - stdio isn't ANSI. Supposedly fflush(NULL) will flush all streams. Not on Apollos. Rumour hath it that 10.3 has an ANSI compiler. That would be nice. A better lint would be nice, too. - Cameron Simpson cameron@spectrum.cs.unsw.oz.au
hanche@imf.unit.no (Harald Hanche-Olsen) (09/11/90)
In article <847@usage.csd.unsw.oz.au> cameron@usage.csd.oz (Cameron Simpson,Uhmmm..???? Who knows) writes:
Rumour hath it that 10.3 has an ANSI compiler. That would be nice.
A better lint would be nice, too.
Then rumour is unprecise. What is true is that the 6.8 compiler is an
ANSI one, but only if you run it under SR10.3. And then the programs
you compile with the ANSI option set will not run under SR10.2 and
earlier (at least that is how I read the documentation). By the way,
the suite of *.8 compilers will be known as the CR1.0 compilers, for
reasons unknowable to man. By the way, I would have thought that type
checking and the proper use of function prototypes would help to make
lint obsolete?
- Harald Hanche-Olsen <hanche@imf.unit.no>
Division of Mathematical Sciences
The Norwegian Institute of Technology
N-7034 Trondheim, NORWAYrees@pisa.ifs.umich.edu (Jim Rees) (09/12/90)
In article <847@usage.csd.unsw.oz.au>, cameron@usage.csd.oz (Cameron Simpson,Uhmmm..???? Who knows) writes:
On the subject of the semiANSIness of the Apollo cc, peering at my
a configuration file I have here the following weirdness applied under 10.1.
I think most of them still apply under 10.2 (we run it but I haven't checked).
- "const" doesn't work.
- the ANSI #include files aren't there (limits.h and so forth).
- self-referential macros fail, viz
#define it(x) (fputs("hi\n",stderr),it(x))
- stdio isn't ANSI. Supposedly fflush(NULL) will flush all streams.
Not on Apollos.
The most frequent problem I've run across is that cpp doesn't handle '##'.
You can fix all these problems by using the '-A nansi' flag, which tells the
compiler "don't even pretend to be ANSI compliant." But that's a pretty big
hammer. The X imake config file has a switch that says "ANSI C but no '##'."
Sure would be nice if all sources were configurable at such fine grain.
As for stdio, I don't see this as a compiler issue. I've never even heard
of it before.
Rumour hath it that 10.3 has an ANSI compiler. That would be nice.
A better lint would be nice, too.
The compiler has now been decoupled from the OS, or so I hear. It's always
been a separate installable product. So there isn't really a "sr10.3
compiler." But I've also heard that the new compiler will be full ANSI.hp@vmars.tuwien.ac.at (Peter Holzer) (09/12/90)
cameron@usage.csd.oz (Cameron Simpson,Uhmmm..???? Who knows) writes: >The tech rep is wrong. I think the documentation says evasive things like >"many ANSI extensions" and so forth. You'll discover that their definition >of __STDC__ is also evasive - they define it to 0. Not on 10.2. __STDC__ is defined as 1. >| I wouldn't care about the compiler as I have gcc running on the machine. >| However, I have to use the header files that came with the machine, and here >| is where I have a problem. [...] >| unsigned char *_ptr #attribute[aligned(1)]; >On the subject of the semiANSIness of the Apollo cc, peering at my >a configuration file I have here the following weirdness applied under 10.1. >I think most of them still apply under 10.2 (we run it but I haven't checked). > - "const" doesn't work. > - the ANSI #include files aren't there (limits.h and so forth). > - self-referential macros fail, viz > #define it(x) (fputs("hi\n",stderr),it(x)) > - stdio isn't ANSI. Supposedly fflush(NULL) will flush all streams. > Not on Apollos. Add: - "signed char" doesn't work. - stdargs don't work either. -- | _ | Peter J. Holzer | Think of it | | |_|_) | Technische Universitaet Wien | as evolution | | | | | hp@vmars.tuwien.ac.at | in action! | | __/ | ...!uunet!mcsun!tuvie!vmars!hp | Tony Rand |
minar@reed.bitnet (Nelson Minar,L08,x640,7776519) (09/12/90)
In article <1810@tuvie> hp@vmars.tuwien.ac.at (Peter Holzer) writes: >cameron@usage.csd.oz (Cameron Simpson,Uhmmm..???? Who knows) writes: >Not on 10.2. __STDC__ is defined as 1. >[host of things that don't work according to ANSI] So why does the Apollo C compiler define __STDC__ to be 1, thus signaling to the world "Hey! We're an ANSI C compiler!" Is this just a sick joke, or the result of bad testing from the compiler shop, or an honest misunderstanding of what it means to be ANSI? Or is it just patently broken?
cameron@usage.csd.oz (Cameron Simpson,Uhmmm..???? Who knows) (09/12/90)
From article <HANCHE.90Sep11182351@hufsa.imf.unit.no>, by hanche@imf.unit.no (Harald Hanche-Olsen): | In article <847@usage.csd.unsw.oz.au> cameron@usage.csd.oz (Cameron Simpson) writes: | Rumour hath it that 10.3 has an ANSI compiler. That would be nice. | A better lint would be nice, too. | Then rumour is unprecise. [more detailed compiler info ...] | By the way, I would have thought that type | checking and the proper use of function prototypes would help to make | lint obsolete? Prototypes are a great help. But lint does much more than this. It catches miscellaneous conflicting unprototyped functions. It catches unportable code. It catches uninitialised and unused variables. And so on. It would be nice if the compiler caught some of these. Some of these checks (IMHO) don't belong in the compiler, and should stay in lint. Some of these checks _can't_ be caught by the compiler in a convenient fashion (eg cross checking). I like lint. - Cameron Simpson cameron@spectrum.cs.unsw.oz.au
Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips) (09/12/90)
>>>>> On 11 Sep 90 10:16:56 GMT, cameron@usage.csd.oz (Cameron Simpson,Uhmmm..???? Who knows) said:
Cameron> You'll discover that their definition of __STDC__ is also evasive
Cameron> - they define it to 0.
I wish. On our 10.1.1 systems, it's defined to be "1".
--
Chuck Phillips MS440
NCR Microelectronics Chuck.Phillips%FtCollins.NCR.com
2001 Danfield Ct.
Ft. Collins, CO. 80525 uunet!ncrlnk!ncr-mpd!bach!chuckprees@pisa.ifs.umich.edu (Jim Rees) (09/13/90)
In article <15444@reed.UUCP>, minar@reed.bitnet (Nelson Minar,L08,x640,7776519) writes:
So why does the Apollo C compiler define __STDC__ to be 1, thus signaling to
the world "Hey! We're an ANSI C compiler!" Is this just a sick joke, or the
result of bad testing from the compiler shop, or an honest misunderstanding of
what it means to be ANSI? Or is it just patently broken?
My understanding is that this is historical. __STDC__ was originally turned
on back when the only thing it meant was "function prototypes." (This would
have been about two or three years ago.) As actual code started using more
of the ANSI features, the compiler didn't keep up.nazgul@alphalpha.com (Kee Hinckley) (09/13/90)
In article <848@usage.csd.unsw.oz.au> cameron@spectrum.cs.unsw.oz.au (Cameron Simpson) writes: >Prototypes are a great help. But lint does much more than this. I totally agree that lint should work on Apollo header files, however... >It catches unportable code. It catches uninitialised and unused variables. >And so on. It would be nice if the compiler caught some of these. The Apollo compiler catches both of these, there's a flag for unportable code, uninit and unused variables are caught normally. Furthermore you can turn on the -info flags and catch more things than you ever wanted to know. -- Alphalpha Software, Inc. | motif-request@alphalpha.com nazgul@alphalpha.com |----------------------------------- 617/646-7703 (voice/fax) | Proline BBS: 617/641-3722 I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.