Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!border3.nntp.dca.giganews.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.earthlink.com!news.earthlink.com.POSTED!not-for-mail NNTP-Posting-Date: Fri, 21 Dec 2012 13:52:17 -0600 Message-ID: <50D4BDF4.466A@mindspring.com> Date: Fri, 21 Dec 2012 14:52:20 -0500 From: pete Reply-To: pfiland@mindspring.com Organization: PF X-Mailer: Mozilla 3.04Gold (WinNT; I) MIME-Version: 1.0 Newsgroups: comp.lang.c Subject: Re: passing uninitialised data References: <505351CA.4010204@verizon.net> <50CF8CDB.46EC@mindspring.com> <50D3C6A6.7137@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 101 X-Usenet-Provider: http://www.giganews.com NNTP-Posting-Host: 4.156.228.190 X-Trace: sv3-E2g29H1aig4z4OZ4R+uBlU/EJoaKcL1kEve9K+Z8ENW9Y2wEbNxkOvJ5SI3F7yMmhs45VebscjseB8R!yF5/XI+nKMfZHphkLeVIV2SwaNfunhrv6raSS3V0MDxJZw0zaag2VY1WOmBOEClZsHz4ww3Uu1Su!9TlNh9YtOgk= X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 5935 Xref: csiph.com comp.lang.c:29578 Tim Rentsch wrote: > > pete writes: > > > Tim Rentsch wrote: > >> > >> pete writes: > >> > >> > Tim Rentsch wrote: > >> >> > >> >> Barry Schwarz writes: > >> >> > >> >> > On Fri, 14 Sep 2012 11:48:26 -0400, James Kuyper > >> >> > wrote: > >> >> > > >> >> >>On 09/14/2012 11:09 AM, Mark wrote: > >> >> >>> Hello, > >> >> >>> > >> >> >>> I have quite a generic question. Suppose we work with fwrite(), or sendto() > >> >> >>> (not C standard function, but I'll assume everyone knows it) or any other > >> >> >>> API that takes a pointer to a buffer to trasnmit. When such a buffer is > >> >> >>> unititialised, does it in some ways impose undefined behaviour? > >> >> >> > >> >> >> > >> >> >>> I'm asking this, because when such code is run under 'valgrind' it reports a > >> >> >>> lot about uninitiased memory or 'unaddressable values in syscalls' -- does > >> >> >>> it imply such will act undefined due to uninit storages used as buffers? > >> >> >>> > >> >> >>> Would appreciate the comments on it. Thanks. > >> >> >> > >> >> >>"If an object that has automatic storage duration is not initialized > >> >> >>explicitly, its value is indeterminate." (6.7.9p10) > >> >> >> > >> >> >>An indeterminate value is defined as "either an unspecified value or a > >> >> >>trap representation" (3.19.2) > >> >> >> > >> >> >>"Certain object representations need not represent a value of the object > >> >> >>type. If the stored value of an object has such a representation and is > >> >> >>read by an lvalue expression that does not have character type, the > >> >> >>behavior is undefined. ... Such a representation is called a trap > >> >> >>representation." (6.2.6.1p5) > >> >> >> > >> >> >>So far, this looks bad. However, let's go a little further: > >> >> >>The description of fwrite() says "... For each object, size calls are > >> >> >>made to the fputc function, taking the values (in order) from an array > >> >> >>of unsigned char exactly overlaying the object. ..." (7.21.8.2p1). In > >> >> >>other words, it accesses the data using only lvalues of type unsigned > >> >> >>char, a character type. Therefore, the undefined behavior mentioned in > >> >> >>6.2.6.1p5 doesn't apply. > >> >> > > >> >> > While an unsigned char cannot contain a trap value, I believe J.2, > >> >> > even though it is not normative, gives the clearest statement of the > >> >> > intent: > >> >> > > >> >> > "The behavior is undefined in the following circumstances: ... The > >> >> > value of an object with automatic storage duration is used while it is > >> >> > indeterminate." > >> >> > >> >> Accessing an uninitialized variable of type unsigned char is (as > >> >> of C11) undefined behavior in some circumstances, but only some. > >> >> This result obtains by virtue of 6.3.2.1 p2, in particular the > >> >> last sentence. > >> >> > >> >> Obviously, accessing an uninitialized variable is not /always/ > >> >> undefined behavior, because if it were then there would be > >> >> no point in adding the new proviso to 6.3.2.1 p2; undoubtedly > >> >> the committee would simply have added some non-normative text > >> >> instead. > >> > > >> > The last statement of 6.3.2.1 p2, > >> > makes me think that > >> > if the lvalue designates an object of automatic storage duration > >> > that could have been declared with the register storage class > >> > (never had its address taken), > >> > and that object is uninitialized (not declared with an initializer > >> > and no assignment to it has been performed prior to use), > >> > then the program really doen't have to reserve storage for that object. > >> > >> You're assuming that the compiler can tell whether that > >> situation will occur. Sometimes it can, but in the > >> general case it can't (Halting Problem, etc). > > > > It's the only reason that I can think of for why > > > > int main(void) {unsigned char x; return x - x;} > > > > should be undefined. > > It turns out that some actual hardware has out-of-band marking > (for registers, I think) that indicate non-initialization. Those > machiness (can) trap on a reference to an unitialized register. > My understanding is that the passage we are discussing was added > specifically because such machines currently exist, and more > generally because it is useful to allow similar kinds of traps > or what-have-you, yet still be inside the boundaries of being > a conforming implementation. Thank you. -- pete