I can't find a good definition anywhere...
Tom Neff
tneff at bfmny0.UUCP
Sun May 14 00:44:53 AEST 1989
In article <1989May12.154810.21589 at utzoo.uucp> henry at utzoo.uucp (Henry Spencer) writes:
>In article <10253 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn) writes:
>>There is some sentiment that whatever #pragma does, the rest of the
>>specifications in the Standard still have to be conformed to, so it's
^^^^^^^^^^^^^^^^^^^^^
That is, in order for
the resulting program
to remain ANSI conformant...
>>not quite "anything". Valid examples are output listing control,
>>levels of optimization, etc.
>
>Unfortunately, while there is some sentiment for this view, it's not
>guaranteed by the Standard (unless the relevant text has changed since
>the October draft), so it should not be relied on. There are two
>possible interpretations of the actual wording, neither of which is
>internally contradictory: either #pragma is allowed to change the
>rules, or it isn't. Opinions vary on which interpretation is preferable,
>but the Standard doesn't say.
I don't think there's any doubt whatsoever that #pragma cannot be used
to "change the rules" in the sense that saying something like
#pragma operator_precedence(+/*-.[]->)
would yield a *valid ANSI C* program whose operator precedence differed
radically from the Standard. My reading of the draft suggests that you
are allowed to put anything you want in a #pragma and still have a
valid ANSI C program *so long as the rest of the source would be valid
ANSI C anyway.* That's why output listing control and optimization are
the "friendliest" examples. Less friendly are things like
#pragma allow_our_weird_extended_keywords=YES
which then allows statements like
extern void massively_parallel testfunc(int a);
or
shared char *mydata;
to compile. Implementors are certainly going to do this, since #pragma
is a very natural facility for it. (I think MS already does to some
extent.) The question is, is the resulting *program* ANSI C? Not at
all -- #pragma was used to break conformance. It'll be a rare
implementation where this isn't possible one way or another, if only
because every compiler has predecessors from the same vendor who will
want a safety valve for backward compatibility. Is a compiler that's
*capable* of compiling a non-conformant program via #pragma, but is
also capable of compiling conformantly otherwise, still allowed to
define _STDC_ 1? Yes! if the killer #pragma isn't in effect. I think
this is what Henry's really asking.
--
Tom Neff UUCP: ...!uunet!bfmny0!tneff
"Truisms aren't everything." Internet: tneff at bfmny0.UU.NET
More information about the Comp.std.c
mailing list