#pragma

[diamond@tkovoa]

In article <12570055 at hpclscu.HP.COM> shankar at hpclscu.HP.COM (Shankar Unni) writes:
>Doug Gwyn writes in response to a note from Norman Diamond:
>
>>In article <3928 at male.EBay.Sun.COM> diamond at tkou02.enet.dec.com (diamond at 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 <something>"?
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 <xx>"),
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 at tkov50.enet.dec.com
                                    (tkou02 is scheduled for demolition)
We steer like a sports car:  I use opinions; the company uses the rack.