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

Groups > comp.lang.c > #29578

Re: passing uninitialised data

Show all headers | View raw

Tim Rentsch wrote:
> 
> pete <pfiland@mindspring.com> writes:
> 
> > Tim Rentsch wrote:
> >>
> >> pete <pfiland@mindspring.com> writes:
> >>
> >> > 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.
> >>
> >> 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

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