🚀 go-pugleaf

In article <1989May12.154810.21589@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes:
> In article <10253@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
> >There is some sentiment that whatever #pragma does, the rest of the
> >specifications in the Standard still have to be conformed to, so it's
> >not quite "anything".
> Unfortunately, while there is some sentiment for this view, it's not
> guaranteed by the Standard (unless the relevant text has changed since
> the October draft), so it should not be relied on.

In the second formal public review, X3J11 responded to an issue summarized
as "May #pragma alter the I/O behavior of a strictly conforming program?"
with the following:

	It is true that according to a *literal* reading of Section 1.7,
	a *strictly conforming program* could not safely contain #pragma,
	because the effect of #pragma is entirely *implementation defined*
	according to Section 3.8.6, and that certainly could include
	affecting the I/O behavior.  However, that is not the intent of
	#pragma, because the "requirements" in Section 3.8.6 are not the
	whole story -- the requirements imposed by the rest of the
	Standard must be met as well, and these sufficiently limit the
	effect that a #pragma can have.

	Given the confusion over this, to be safe you should probably
	avoid using #pragma in strictly conforming programs.  (Besides,
	some implementation may choose to interpret another's benign
	#pragma as, for example, a request to call you in the middle of
	the night to let you know when your program is being compiled,
	and you may find that an unpleasant surprise.)

I would hope that in the "interpretations phase" of X3J11 existence, it
will reaffirm this position.  The other interpretation (that #pragma
exempts an implementation from conforming to the specifications) would be
folly, because the same reasoning could be applied to other instances of
implementation-defined behavior, making a farce of the whole notion.