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

Groups > comp.lang.c > #26473

Re: passing uninitialised data

Show all headers | View raw

On 09/14/2012 06:26 PM, Barry Schwarz wrote:
> On Fri, 14 Sep 2012 14:34:37 -0400, James Kuyper
> <jameskuyper@verizon.net> wrote:
> 
>> 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.
> 
> I believe p5 is providing a definition of trap representation (and the
> fact that unsigned char cannot have one) rather than limiting what
> behavior is undefined.

Even if your interpretation is correct, then 6.2.6.1p5 still doesn't
give such code undefined behavior, because in that case, the values can
only be unspecified, not trap representations, so the behavior of the
call to fwrite() is still defined.

As of C2011, the phrase "trap representation" is no longer in italics in
that section, and 3.19.4p1 is now the place where that phrase is
defined. That definition is "an object representation that need not
represent a value of the object type". It says nothing to exclude
character types, and the fact that, under certain circumstances, a trap
representation can result in undefined behavior, is not part of the
definition. I believe that this is not a change in the meaning of "trap
representation", but merely a clarification of something that C99 said
less clearly. The first and last sentences of that clause are now
redundant with 3.19.4p1, and could be removed; if so, "such a
representation" would have to be replaced with "a trap representation",
which would actually make the meaning clearer. Not naming the concept
until after it has been used several times was always rather clumsy writing.

6.2.6.1p5 is (now) solely about the circumstances under which a trap
representation can lead to undefined behavior. Reading one though an
lvalue of character type isn't one of them. The behavior of the fwrite()
call is defined by 7.21.8.2 even if the buffer is uninitialized: either
the specified number of bytes will be written from that buffer, or an
error code indicating an I/O error will be returned. If successful, the
actual values written to the file are unspecified, but if written and
read back using a binary stream, they must compare equal to the
unspecified values in the buffer (7.21.2p3). No matter what those values
are, fwrite() must return (after an unspecified amount of time, the same
as any call to fwrite() with defined behavior), and the succeeding lines
in the program will be executed. None of those things would be
guaranteed if the behavior were undefined.

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