Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #29426

Re: passing uninitialised data

Show all headers | View raw

Tim Rentsch wrote:
> 
> Barry Schwarz <schwarzb@dqel.com> writes:
> 
> > On Fri, 14 Sep 2012 11:48:26 -0400, James Kuyper
> > <jameskuyper@verizon.net> 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.

-- 
pete

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

passing uninitialised data "Mark" <mark_cruzNOTFORSPAM@hotmail.com> - 2012-09-14 11:09 -0400
  Re: passing uninitialised data Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-09-14 11:45 -0400
  Re: passing uninitialised data James Kuyper <jameskuyper@verizon.net> - 2012-09-14 11:48 -0400
    Re: passing uninitialised data Barry Schwarz <schwarzb@dqel.com> - 2012-09-14 10:34 -0700
      Re: passing uninitialised data James Kuyper <jameskuyper@verizon.net> - 2012-09-14 14:34 -0400
        Re: passing uninitialised data Barry Schwarz <schwarzb@dqel.com> - 2012-09-14 15:26 -0700
          Re: passing uninitialised data James Kuyper <jameskuyper@verizon.net> - 2012-09-17 12:18 -0400
      Re: passing uninitialised data Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-17 11:52 -0800
        Re: passing uninitialised data pete <pfiland@mindspring.com> - 2012-12-17 16:21 -0500
          Re: passing uninitialised data Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-20 10:23 -0800
            Re: passing uninitialised data pete <pfiland@mindspring.com> - 2012-12-20 21:17 -0500
              Re: passing uninitialised data Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-21 09:20 -0800
                Re: passing uninitialised data pete <pfiland@mindspring.com> - 2012-12-21 14:52 -0500
                Re: passing uninitialised data glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-21 21:19 +0000
        Re: passing uninitialised data Shao Miller <sha0.miller@gmail.com> - 2012-12-17 19:45 -0500
  Re: passing uninitialised data Angel <angel+news@spamcop.net> - 2012-09-14 19:03 +0000
    Re: passing uninitialised data James Kuyper <jameskuyper@verizon.net> - 2012-09-14 15:15 -0400
      Re: passing uninitialised data Angel <angel+news@spamcop.net> - 2012-09-14 20:26 +0000
        Re: passing uninitialised data James Kuyper <jameskuyper@verizon.net> - 2012-09-14 16:45 -0400
      Re: passing uninitialised data Kaz Kylheku <kaz@kylheku.com> - 2012-09-14 21:19 +0000

csiph-web