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

[Doug Gwyn]

In article <15434 at reed.UUCP> minar at reed.bitnet (Nelson Minar) writes:
>(from stdio.h)
>extern  struct  _iobuf {
>        unsigned char   *_ptr #attribute[aligned(1)];
>	[ some removed ]
>        unsigned char   *_base #attribute[aligned(1)];
>	[ . . . ]
>} _iob[];

The headers provided by the implementation need not be in themselves
strictly conforming code samples.  However, the above worries me in
that I wonder what an application that used the two tokens "#" and
"attribute" in the replacement list of a function-like macro would
have happen.  It is likely that it would be preprocessed correctly,
IF the preprocessing be performed as a structurally separate pass,
but I can imagine circumstances under which it could fail to conform.

>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?

Apparently Apollo thought they needed finer-grained control than the
statement-oriented #pragma directive provides.  Obviously, this
particular #attribute specifies alignment of the structure members.
Apart from the replacement-list concern I mentioned above, this would
be a conforming extension to the language, since no strictly conforming
program could be affected by this extension (other than as used within
the C implementation itself).

>(from string.h - this is wrapped inside of an '#ifdef __STDC__')
>extern char *strcpyn(...);

Actually, this should be EXCLUDED when __STDC__ is in effect, since
the C standard prohibits inclusion of arbitrary junk in standard
headers for a conforming (__STDC__) implementation.

>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?

That's correct, and if you were to use this in your own program, a
conforming implementation is obliged to produce a diagnostic, since
this usage violates a syntax rule.  Without knowing the details of
Apollo's C implementation, I don't know whether or not they have
provided some special loophole for their own use within their C
implementation.  Again, a conforming implementation itself need not
be (part of) a strictly conforming program.

Basically, you the programmer have to follow the rules, at least if
you desire portability, but the implementor can do anything at all so
long as strictly-conforming programs are properly accepted and other
programs result in diagnostics whenever they violate a syntax rule or
constraint of the C standard.  Note that that leave a third class of
programs, those that are not strictly conforming but not in flagrant
violation of the C standard; that permits conforming programs to
exploit certain kinds of vendor-specific extensions.