#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