Article View: comp.std.c
Article #2010Re: Another sizeof question
From: Shankar Unni
Date: Tue, 20 Nov 1990 01:43
Date: Tue, 20 Nov 1990 01:43
41 lines
2651 bytes
2651 bytes
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: > >If this is really true, it defeats the purpose of #pragma. My understanding > >was that #pragma may have any implementation-defined effect WHICH does not > >change the meaning of a conforming program (though it may change the effect > >of a nonconforming program). That definition would have been far more useful. > > That was my argument, but when Walter Murray requested a formal ruling on > this, even I had to agree that the wording in the C standard leads to the > conclusion that a strictly conforming program cannot use #pragma. And that is as it should be. Consider for a moment if the ANSI committee had adopted something like Norman's interpretation: a program must behave the "same" way (whatever that is - leave it for the moment) with or without the #pragma. Where would that leave, just to take an example, "#pragma ALIGN <something>"? Often, such alignment pragmas are required to help programs read binary struct images from other machines. Programs which depend on such pragmas are, of course, totally non-conforming. But if you forbid a pragma from ever having a non-behavior-modifying effect, you cannot even implement such a pragma for non-conforming programs (because that would make the compiler non-conforming, even though it is hard to test for such a situation with any kind of a verification suite). If you choose some other method of specifying it (say, "#align <xx>"), that also must be diagnosed by a conforming compiler implementation. Result: you cannot implement such a mechanism in a conforming compiler *at all*. Thus the only reasonable approach is to say that a "#pragma" can change the behavior of a program in really unspecified ways (unless you want to get into the business of standardizing specific pragmas, like Ada does). ----- Shankar Unni E-Mail: Hewlett-Packard California Language Lab. Internet: shankar@hpda.hp.com Phone : (408) 447-5797 UUCP: ...!hplabs!hpda!shankar
Technical Details
Message-ID:
<12570055@hpclscu.HP.COM>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!sdd.hp.com!hplabs!hpda!hpcuhb!hpcllla!hpclisp!hpclscu!shankarReferences:
<13171@crdgw1.crd.ge.com>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!sdd.hp.com!hplabs!hpda!hpcuhb!hpcllla!hpclisp!hpclscu!shankar From: shankar@hpclscu.HP.COM (Shankar Unni) Newsgroups: comp.std.c Subject: Re: Another sizeof question Message-ID: <12570055@hpclscu.HP.COM> Date: 20 Nov 90 01:43:03 GMT References: <13171@crdgw1.crd.ge.com> Organization: Hewlett-Packard Calif. Language Lab Lines: 41