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

Groups > comp.lang.c > #29449

Re: passing uninitialised data

Show all headers | View raw

On 12/17/2012 14:52, 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.
>

And since the question is about a pointer into a buffer being passed, 
then it'd seem that there're no trap representations for the 'unsigned 
char' values in that buffer, right?

This goes back to Defect Report 260, doesn't it?

   http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_260.htm

- Shao Miller

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