Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!usc!ucsd!ucbvax!tkou02.enet.dec.com!diamond From: diamond@tkou02.enet.dec.com ("diamond@tkovoa") Newsgroups: comp.std.c Subject: Re: #pragma Message-ID: <9011272328.AA03163@decpa.pa.dec.com> Date: 27 Nov 90 23:28:53 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 52 In article <12570055@hpclscu.HP.COM> shankar@hpclscu.HP.COM (Shankar Unni) writes: >Doug Gwyn writes in response to a note from Norman Diamond: > >>In article <3928@male.EBay.Sun.COM> diamond@tkou02.enet.dec.com (diamond@tkovoa) writes: nd>If this is really true, it defeats the purpose of #pragma. My understanding nd>was that #pragma may have any implementation-defined effect WHICH does not nd>change the meaning of a conforming program (though it may change the effect nd>of a nonconforming program). That definition would have been far more useful. dg>That was my argument, but when Walter Murray requested a formal ruling on dg>this, even I had to agree that the wording in the C standard leads to the dg>conclusion that a strictly conforming program cannot use #pragma. su>And that is as it should be. su> su>Consider for a moment if the ANSI committee had adopted something like su>Norman's interpretation: a program must behave the "same" way (whatever su>that is - leave it for the moment) with or without the #pragma. Where would su>that leave, just to take an example, "#pragma ALIGN "? su>Often, such alignment pragmas are required to help programs read binary su>struct images from other machines. Programs which depend on such pragmas su>are, of course, totally non-conforming. su>But if you forbid a pragma from ever having a non-behavior-modifying su>effect, you cannot even implement such a pragma for non-conforming programs su>(because that would make the compiler non-conforming, even though it is su>hard to test for such a situation with any kind of a verification suite). su>If you choose some other method of specifying it (say, "#align "), su>that also must be diagnosed by a conforming compiler implementation. su>Result: you cannot implement such a mechanism in a conforming compiler su>*at all*. su>Thus the only reasonable approach is to say that a "#pragma" can change the su>behavior of a program in really unspecified ways (unless you want to get su>into the business of standardizing specific pragmas, like Ada does). Not at all. A program which wants to be conforming and executable on all implementations, but obtain some feature from an implementation which recognizes a particular #pragma, should use #pragma. A program which DEPENDS on a non-portable construction should use an extended #directive and/or __identifier that is offered by the particular implementation. This is exactly why the standard says that if an implementation does not recognize a particular #pragma, it should ignore it. If an implementation does not recognize a #funny_directive or __reserved_identifier, it is supposed to issue a diagnostic. Implementation-dependent programs that are coded in Mr. Unni's style will not receive the desired diagnostics from other implementations. The instructions that an unrecognized #pragma be ignored are now either useless or, worse, counterproductive. Unfortunately, the ANSI committee seems to have forgotten their own wishes. -- Norman Diamond, Nihon DEC diamond@tkov50.enet.dec.com (tkou02 is scheduled for demolition) We steer like a sports car: I use opinions; the company uses the rack.