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

Groups > comp.lang.c > #29570

Re: passing uninitialised data

Show all headers | View raw

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.

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