🚀 go-pugleaf

In article <14324@bfmny0.UUCP> tneff@bfmny0.UUCP (Tom Neff) writes:
>>... 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...
>
>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.*

Can you justify this with chapter and verse?  No other construct follows
such a rule; a partial program is often not a legal program.

It *is* true that you must read the whole standard, not an isolated part
of it, to get the correct meaning.  Unfortunately, the whole standard
includes that marvellous line about how #pragma has "implementation-defined
effects", so you cannot understand the meaning of (say) the section on
the "for" statement without considering that a #pragma might have an
implementation-defined effect on it.

The definition of "implementation-defined" does plausibly imply that the
program should be legal without the #pragma, but I wouldn't call the
issue clear-cut.  And nothing says that the semantics have to be the same.
Your precedence example isn't a good one.  Changing the operator precedence
will not usually make a program illegal, unless type-compatibility issues
intervene.  It just changes the meaning.

In practice, all bets are off when a #pragma appears.
-- 
Mars in 1980s:  USSR, 2 tries, |     Henry Spencer at U of Toronto Zoology
2 failures; USA, 0 tries.      | uunet!attcan!utzoo!henry henry@zoo.toronto.edu