minar@reed.bitnet (Nelson Minar,L08,x640,7776519) (09/10/90)
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__.
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?
(from string.h - this is wrapped inside of an '#ifdef __STDC__')
extern char *strcpyn(...);
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?
Assuming these 2 things are illegal, are there any other non-ANSIisms people
out there in Apollo world have had to deal with?gwyn@smoke.BRL.MIL (Doug Gwyn) (09/10/90)
In article <15434@reed.UUCP> minar@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.
stephen@estragon.uchicago.edu (Stephen P Spackman) (09/11/90)
In article <15434@reed.UUCP> minar@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@estragon.uchicago.edu 312.702.3982
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
ndjc@hobbit.UUCP (Nick Crossley) (09/12/90)
In article <13798@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: >>(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. I thought all external names starting str[a-z]... were reserved to the implementation for future ANSI C string functions, so is strcpyn() really illegal? -- <<< standard disclaimers >>> Nick Crossley, ICL NA, 9801 Muirlands, Irvine, CA 92718-2521, USA 714-458-7282 uunet!ccicpg!ndjc / ndjc@ccicpg.UUCP
karl@haddock.ima.isc.com (Karl Heuer) (09/12/90)
In article <13798@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: >In article <15434@reed.UUCP> minar@reed.bitnet (Nelson Minar) writes: >>[someone's stdio says:] unsigned char *_ptr #attribute[aligned(1)]; >>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. [It's legal, unless it >collides with the ANSI `#' stringizing operator.] A safer solution would have been to use a double-underscore keyword instead. Gcc does this. (And the documentation notes that since they are equally legal but `__' is more flexible, there's no reason to support any `#pragma's.) >>(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. But it isn't arbitrary junk: `str*' is part of the reserved namespace associated with <string.h>, so this would seem to be legal. I'd guess this is probably the equivalent of the `vstrcat' function in the FAQ, and the vendor declared it with zero fixed arguments to avoid having to special-case the first string in the actual implementation. Karl W. Z. Heuer (karl@kelp.ima.isc.com or ima!kelp!karl), The Walking Lint
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/13/90)
In article <17963@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes: >But it isn't arbitrary junk: `str*' is part of the reserved namespace >associated with <string.h>, so this would seem to be legal. As some sort of twisted, perverted interpretation of the "law", I guess it might be so considered. Actually, though, reservation of that portion of the external identifier name space (for implementation use) was specifically aimed at avoiding potential problems with applications developed under the current C standard when and if implementations were to start conforming with some future enhanced version of the standard. It was certainly not intended to provide conforming implementations of the current standard a bunch of names to steal for nonstandard uses. To see what is wrong with them doing that, suppose that in a future version of the C standard a function named strcpyn() is standardized with different interface or semantics from Apollo's. Clearly that would put users of Apollo's supposedly standard C implementation in a bind in some cases. (Ignoring the even greater bind it would put the Apollo implementors in, because they deserve it.)
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/13/90)
In article <86589@hobbit.UUCP> ndjc@hobbit.UUCP (Nick Crossley) writes: >I thought all external names starting str[a-z]... were reserved to the >implementation for future ANSI C string functions, so is strcpyn() >really illegal? You put the problem very nicely -- in order to answer your question we would have to know what the future holds w.r.t. "strcpyn". Do you?
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/13/90)
In article <13827@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: >put users of Apollo's supposedly standard C implementation in a bind in >some cases. (Ignoring the even greater bind it would put the Apollo >implementors in, because they deserve it.) Since according to Steve's posting that just arrived here, the reported "standard conformance" wasn't supposed to be advertised as such, and that all the problems are fixed in the forthcoming (October) release, feel free to ignore the small dig at Apollo C implementors. They seem to have done all right after all..