This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Undefined behavior or not?


On 03/11/2017 09:08 AM, Segher Boessenkool wrote:
On Sat, Mar 11, 2017 at 04:38:56PM +0100, onkel.jack@t-online.de wrote:
Dont mess up p and (*p).

Its true the the content of the memory p points to may change after free, depending on what other threads do and what the operating system is doing on free.
but the value of p, which contains the address of the allocated memory, does not change at free.
Its till holds that address.

This means, p stay as is but *p may change.

No, that is not how it works.  6.2.4/2 says: [...] "The value of a
pointer becomes indeterminate when the object it points to (or just
past) reaches the end of its lifetime."

It does not matter whether the value of p changes in *your* system,
or in most systems.  Using the value of p after deallocating the object
it pointed to is undefined behaviour.

Right.  And because reading an indeterminate value is undefined,
the effect of reading such a value can actually be one of reading
a different value each time, with no apparent modification to it
in between successive reads on the part of the program.

While it's true that the free() library function would have a hard
time changing its argument, nothing prevents the compiler from
setting it to any arbitrary value after free returns (when called
with a non-null argument), including 0xdeadbeef or even null.

The C committee has discussed this topic a number of times in
their quest to nail down more precisely what kinds of optimzations
are and aren't allowed, and what valid programs can rely on.  The
term that describes this phenomenon that seems to have stuck is
a "wobbly value."

Martin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]