🚀 go-pugleaf

In article <1989May12.154810.21589@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>In article <10253@smoke.BRL.MIL> gwyn@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@bfmny0.UU.NET