Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| 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> |
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
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