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: Thu, 20 Dec 2012 20:17:08 -0600 Message-ID: <50D3C6A6.7137@mindspring.com> Date: Thu, 20 Dec 2012 21:17:10 -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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 86 X-Usenet-Provider: http://www.giganews.com NNTP-Posting-Host: 4.154.216.160 X-Trace: sv3-s1REP8r/5C/JwNSfmcIW+OdXQBA2EMyiyTxcMIXxK07k37QiJFjgvF0+pFAyQdSEv1joVh0lt7VboPU!gq1XP06EWYNipczOHXubjnbb7Q7g0+lqeLC5mj7fDQap4p6s11WeBgv8n9jkN0XxMWQoNkitiizj!AYPTGQ2Iemo= 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: 5022 Xref: csiph.com comp.lang.c:29562 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. -- pete