#pragma
Henry Spencer
henry at utzoo.uucp
Fri Jan 20 05:10:53 AEST 1989
In article <12570002 at hpclwjm.HP.COM> walter at hpclwjm.HP.COM (Walter Murray) writes:
>1. A #pragma causes an implementation to behave in an implementation-defined
> manner. Could that include, for example, following unsigned-preserving
> promotion rules, or must the behavior still be ANSI?
The standard is ambiguous on this point, unless there has been some last-
minute wording change I didn't notice. There is an important rule that
says you must read a standard as a whole, not take parts of it out of
context. That being the case, there are two interpretations:
1. #pragma is constrained by the rest of the standard, and
cannot alter its semantics except as provided for by
existing "implementation-defined" wording.
2. The rest of the standard is constrained by the presence of
#pragma's "implementation-defined" effect, so all bets
are off when #pragma appears.
Neither of these interpretations is internally contradictory, and it is
a near-certainty that most implementors will opt for interpretation 2.
>2. A strictly conforming program shall not produce output dependent on
> any implementation-defined behavior. Does it follow that a strictly
> conforming program shall not use a #pragma?
A strictly-conforming program may not depend on any other implementation-
defined behavior, so under interpretation 1 such a program can use
#pragma safely. Under interpretation 2, you are correct. Under the
draft standard and only the draft standard, either interpretation is
possible, hence interpretation 2 is possible, hence you are right again.
--
Allegedly heard aboard Mir: "A | Henry Spencer at U of Toronto Zoology
toast to comrade Van Allen!!" | uunet!attcan!utzoo!henry henry at zoo.toronto.edu
More information about the Comp.std.c
mailing list