Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: Pragmas
Message-ID: <6966@brl-smoke.ARPA>
Date: 7 Jan 88 01:40:30 GMT
References: <11137@brl-adm.ARPA>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 39

In article <11137@brl-adm.ARPA> dsill@NSWC-OAS.arpa (Dave Sill) writes:
>Doug Gwyn writes:
>>In article <1766@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
>>Since a #pragma is not supposed to change the abstract "virtual
>>machine" operation, it's hard to see how this could happen.
>
>Where does it say this?

This is not explicitly stated; rather, it is deduced as follows:

The requirements for a conforming implementation are defined by
the standard as a whole, not just some portion of the standard taken
out of context.  A conforming implementation must simultaneously
meet all specified constraints.  Although the behavior of #pragma
is not spelled out, other than requiring each implementation to
describe its interpretation of pragmas, other portions of the
standard impose constraints on the C language.  If an implementation
were to attempt to make its interpretation of some #pragma result in
behavior counter to that specified in the rest of the standard,
	#pragma Pascal { The rest of this file is Pascal syntax! }
for example, then the total total set of rules is self-contradictory;
that is, such an implementation logically cannot be standard
conforming.  I chose the most reasonable example I could think of
for a radically-contradictory pragma; if I had introduced a more
subtle relevant one such as
	#pragma noalias variable_name
then the point would have been harder to see, but it's logically
the same issue.

In fact, I used to think that the presence of #pragma "spoiled"
the code, so that no portable application could ever contain a
#pragma directive.  But some other X3J11 committee members finally
convinced me that pragmas could not violate the abstract machine
semantics specified by the rest of the standard.  I should note
that at least one committee member has indicated that he still
thinks the way I used to.  If in fact I now have the intended, or
at least the consensual, understanding of this, then it would
probably be wise to have a discussion like the above in the
Rationale document.