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


Groups > comp.lang.c > #26349

Re: passing uninitialised data

From James Kuyper <jameskuyper@verizon.net>
Newsgroups comp.lang.c
Subject Re: passing uninitialised data
Date 2012-09-14 11:48 -0400
Organization A noiseless patient Spider
Message-ID <505351CA.4010204@verizon.net> (permalink)
References <k2vhbd$fhj$1@speranza.aioe.org>

Show all headers | View raw


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 sendto() is not a C standard library function, if it's written in
C, the fact that you mention it in this context suggests that it may be
the kind of function that would also access the data buffer one char
(signed, plain or unsigned) at a time; if so, it's safe too.

If sendto() is not written in C, the behavior is undefined by the C
standard, regardless of whether or not the buffer is uninitialized.
Programs that call functions which are not part of the C standard
library, and are not written in C, are outside the scope of the C
standard, and therefore have undefined behavior due to "the
omission of any explicit definition of behavior." (4p2)

Still, the buffer contains unspecified values. What point is there in
writing it? I've heard of such tricks being used to access whatever data
was last stored in the same block of memory, thereby circumventing
certain weak kinds of security measures - but that's why many systems
now automatically fill uninitialized memory with a fixed bit pattern
such as 0 or 0XDEADBEEF.

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