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

Groups > comp.lang.c > #29562

Re: passing uninitialised data

Show all headers | View raw

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.

-- 
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