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

Groups > comp.lang.c > #26353

Re: passing uninitialised data

Show all headers | View raw

On 09/14/2012 01:34 PM, Barry Schwarz wrote:
> 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."

You might be right about the intent, but if so, what significance should
we attach to the fact that 6.2.6.1p5 goes out of its way to say "that
does not have character type"? If it doesn't mean that accesses through
lvalues of character type are safe, what does it mean? If such accesses
were not intended to be safe, why bother writing that phrase at all? The
passage would be easier to read, write, and understand without that
phrase, so I doubt that the phrase's presence was a mere accident.

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