I can't find a good definition anywhere...
Henry Spencer
henry at utzoo.uucp
Sun May 14 07:00:14 AEST 1989
In article <14324 at bfmny0.UUCP> tneff at 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 at zoo.toronto.edu
More information about the Comp.std.c
mailing list