How ANSI is Apollo's cc 6.7 (SR 10.2)

Stephen P Spackman stephen at estragon.uchicago.edu
Tue Sep 11 06:10:56 AEST 1990


In article <15434 at reed.UUCP> minar at reed.bitnet (Nelson Minar,L08,x640,7776519) writes:
   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__.

Defining __STDC__ has nothing to do with it. SR 10.1 defined __STDC__
and was nothing close to conforming (things like "const" and "signed"
didn't exist and so forth; to compile NetHack we had to disable "ANSI"
processing, though NH is pretty close to conformant by now).

   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.  Since I don't have a copy of the ANSI draft here,
   could some kind soul tell me if these constructs are legal ANSI?

   (from stdio.h)
   extern  struct  _iobuf {
	   unsigned char   *_ptr #attribute[aligned(1)];
	   [ some removed ]
	   unsigned char   *_base #attribute[aligned(1)];
	   [ . . . ]
   } _iob[];

   Just what is '#attribute' supposed to mean? I assume it is supposed to be
   picked up by the preprocessor, but isn't that what #pragma is for?

No, they aren't legal. #attribute is an Apollo-specific extension that
is used to pass information into the compiler in much the same way
#pragma does; but it has the advantage of being part of the SYNTAX (it
attatches to a particular place in the parse tree). This "corrects" a
major oversight in the #pragma design, but leaves you with a programme
that will gack another compiler.

   My reading of K&R2 is that all variable argument functions must have at least
   one named argument, but I am not very clever with such things. Is this legal?

Sucky, isn't it? They want to add a proper varargs mechanism in the
syntax, but aren't going to be bothered to provide semantic support
(if there's always one named argument, that means you always have
something to pass to the stupid macro, of course, for it to take the
address of....).

I much prefer the way TurboC handles it internally; putting ... in a
header effectively declares a constant "...", which is a void*
pointing to the first anonymous argument. That's much nicer.

   Assuming these 2 things are illegal, are there any other non-ANSIisms people
   out there in Apollo world have had to deal with?

Sorry, haven't used 10.2; but as I say, in 10.1 only about half of the
changes to ANSI were implemented (and there were some bugs, I seem to
recall, in the rest).

stephen p spackman  stephen at estragon.uchicago.edu  312.702.3982



More information about the Comp.std.c mailing list