Newsgroups: comp.std.c
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: #pragma
Message-ID: <1989Jan19.191053.15451@utzoo.uucp>
Organization: U of Toronto Zoology
References: <8770@bloom-beacon.MIT.EDU> <12570002@hpclwjm.HP.COM>
Date: Thu, 19 Jan 89 19:10:53 GMT

In article <12570002@hpclwjm.HP.COM> walter@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@zoo.toronto.edu