🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.std.c
Article #2010

Re: Another sizeof question

#2010
From: Shankar Unni
Date: Tue, 20 Nov 1990 01:43
41 lines
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!shankar
References: <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