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


Groups > comp.lang.c > #26369

Re: passing uninitialised data

From Kaz Kylheku <kaz@kylheku.com>
Newsgroups comp.lang.c
Subject Re: passing uninitialised data
Date 2012-09-14 21:19 +0000
Organization Aioe.org NNTP Server
Message-ID <20120914140633.872@kylheku.com> (permalink)
References <k2vhbd$fhj$1@speranza.aioe.org> <slrnk56vs4.7fv.angel+news@pearlgates.net> <50538247.40507@verizon.net>

Show all headers | View raw


On 2012-09-14, James Kuyper <jameskuyper@verizon.net> wrote:
> On 09/14/2012 03:03 PM, Angel wrote:
>> On 2012-09-14, Mark <mark_cruzNOTFORSPAM@hotmail.com> 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 transmit. When such a buffer is 
>>> unititialised, does it in some ways impose undefined behaviour?
>> 
>> Passing a pointer to a function that expects such is well defined, no
>> matter if the object the pointer points to is initialized or not.
>
> There's a reason why valgrind is giving him warning messages about this.

Valgrind does not complain when pointers to unitialized storage are propagated
through the program, only when unitialized storage is accessed. At that time,
the origin of the storage is traced (such as the call trace to the malloc
call that produced the storage).

> It's quite trivial to write code that has undefined behavior when passed
> a pointer to an uninitialized buffer. What precisely is encompassed by
> the phrase "that expects such"?

  /* well-defined behavior possible */
  void expects_pointer_to_unitialized_foo(struct foo *init_me)
  {
    init_me->important_field = 42;
  }

Back to comp.lang.c | Previous | Next — Previous 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