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

Groups > comp.lang.c > #43822

Re: free a pointer and have it point to NULL

Show all headers | View raw

On 2014-04-29, Johannes Bauer <dfnsonfsduifb@gmx.de> wrote:
> On 22.04.2014 23:37, Keith Thompson wrote:
>> G G <gdotone@gmail.com> writes:
>>> memory allocated on the heap once freed should the pointer be assigned NULL?
>> 
>> Maybe.
>> 
>> After free(ptr), the value of ptr is *indeterminate*, meaning that any
>> attempt to refer to its value has undefined behavior.
>
> Woo, really? I find that rather surprising. Does this mean that free()
> specifically is a special case or was this just a writing error on your
> part? If free behaved like all other functions, the value of ptr would
> be well defined after the free (to be the same value as before the free,
> since pointers are call-by-value).

A pointer which refers to any object object that has been destroyed
(a "dangling pointer") is indeterminate. This is not limited to the free
function: pointers to objects defined in automatic storage (block scope
non-static local variables) also become indeterminate when their enclosing
block terminates.

This can happen without a change in the value which is stored.  The value
remains the same, but its meaning changes.  The value is no longer on the
roster of valid pointers, and so it is possible to diagnose any use of that
value, even a harmless transmission from one variable to another without
dereferencing.

A tracing technique related to garbage collection could be used to find
all dangling pointers and overwrite them with a value like null or some other
value deemed useful for debugging. Because such pointers have indeterminate
values, implementors have this freedom.

By far the most common implementation is that nothing happens to such values at
all, and when the storage is re-used for a new object, dangling pointers appear
to be valid pointers referencing the new object.

The rule allows for sophisticated debugging tools which catch problems as early
as possible.

Usually, any use whatsoever of a dangling pointer indicates a bug; there is no
useful purpose behind it.

The exception are introspective programs designed to inspect the behaviors of
memory allocation: to answer questions like "is an object recycled
immediately?":

  {
    char *p = malloc(10), *q;
    free(p);
    q = malloc(10);

    if (p == q) {
       puts("ten byte object was recycled immediately");
    }

    free(q);
  }

Or:

  void *p, *q;

  {
    int x;
    p = &x;
  }

  {
    int y;
    q = &y;
  }

  if (p == q) {
    puts("Cool: x and y were placed in overlapping storage");
  }

The rules in C are such that an implementation can diagnose these programs, and
even halt their execution.

(There is a workaround for that: to use memcmp to compare the pointers.
However, that raises the risk of the comparison being spoiled by
padding bits in a pointer which change its bitwise image, but not
it value (where it points)).

> Defererencing that pointer after a free has obviously indeterminate
> consequences, but is also the pointer *value* indeterminate?

It is the indeterminacy of the value which causes the behavior, upon
dereferencing, to be undefined.

The idea that the pointer value remains "good" from the point of view
of access, but cannot be dereferenced, would require a new category of value in
C, which isn't worth it: a category that isn't "indeterminate", but something
else.

There is a pointer value which has that behavior: it can be used, but not
dereferenced. Namely, the null pointer.  However, a location which might hold a
null pointer can be accessed for a useful purpose: to test whether or not it is
null.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

free a pointer and have it point to NULL G G <gdotone@gmail.com> - 2014-04-22 14:22 -0700
  Re: free a pointer and have it point to NULL James Kuyper <jameskuyper@verizon.net> - 2014-04-22 17:32 -0400
  Re: free a pointer and have it point to NULL G G <gdotone@gmail.com> - 2014-04-22 14:36 -0700
  Re: free a pointer and have it point to NULL Keith Thompson <kst-u@mib.org> - 2014-04-22 14:37 -0700
    Re: free a pointer and have it point to NULL Johannes Bauer <dfnsonfsduifb@gmx.de> - 2014-04-29 13:10 +0200
      Re: free a pointer and have it point to NULL Richard <rgrdev_@gmail.com> - 2014-04-29 13:14 +0200
        Re: free a pointer and have it point to NULL Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-29 13:19 +0100
          Re: free a pointer and have it point to NULL Kaz Kylheku <kaz@kylheku.com> - 2014-04-29 13:57 +0000
      Re: free a pointer and have it point to NULL Kaz Kylheku <kaz@kylheku.com> - 2014-04-29 13:43 +0000
      Re: free a pointer and have it point to NULL James Kuyper <jameskuyper@verizon.net> - 2014-04-29 09:59 -0400
        Re: free a pointer and have it point to NULL Keith Thompson <kst-u@mib.org> - 2014-04-29 07:58 -0700
          Re: free a pointer and have it point to NULL Keith Thompson <kst-u@mib.org> - 2014-04-29 11:50 -0700
            Re: free a pointer and have it point to NULL James Kuyper <jameskuyper@verizon.net> - 2014-04-29 15:47 -0400
        Re: free a pointer and have it point to NULL James Kuyper <jameskuyper@verizon.net> - 2014-04-29 12:41 -0400
          Re: free a pointer and have it point to NULL Robert Wessel <robertwessel2@yahoo.com> - 2014-04-29 13:15 -0500
            Re: free a pointer and have it point to NULL glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-29 21:29 +0000
      Re: free a pointer and have it point to NULL glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-29 15:26 +0000
  Re: free a pointer and have it point to NULL jt@toerring.de (Jens Thoms Toerring) - 2014-04-22 21:43 +0000
    Re: free a pointer and have it point to NULL Keith Thompson <kst-u@mib.org> - 2014-04-22 14:53 -0700
      Re: free a pointer and have it point to NULL Öö Tiib <ootiib@hot.ee> - 2014-04-24 00:38 -0700
        Re: free a pointer and have it point to NULL James Kuyper <jameskuyper@verizon.net> - 2014-04-24 07:52 -0400
          Re: free a pointer and have it point to NULL <william@wilbur.25thandClement.com> - 2014-04-24 16:13 -0700
            Re: free a pointer and have it point to NULL Ian Collins <ian-news@hotmail.com> - 2014-04-25 12:02 +1200
              Re: free a pointer and have it point to NULL <william@wilbur.25thandClement.com> - 2014-04-24 22:03 -0700
                Re: free a pointer and have it point to NULL Ian Collins <ian-news@hotmail.com> - 2014-04-25 17:22 +1200
                Re: free a pointer and have it point to NULL <william@wilbur.25thandClement.com> - 2014-04-24 23:00 -0700
          Re: free a pointer and have it point to NULL Öö Tiib <ootiib@hot.ee> - 2014-04-27 08:32 -0700
    Re: free a pointer and have it point to NULL Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2014-04-22 16:19 -0600
      Re: free a pointer and have it point to NULL Kaz Kylheku <kaz@kylheku.com> - 2014-04-22 22:41 +0000
        Re: free a pointer and have it point to NULL Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2014-04-22 18:17 -0600
          Re: free a pointer and have it point to NULL Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2014-04-24 08:48 -0600
    non-NULL pointers which have the value 0 (Was: Re: free a pointer and have it point to NULL) Andrew Cooper <root@127.0.0.1> - 2014-04-23 03:28 +0100
      Re: non-NULL pointers which have the value 0 (Was: Re: free a pointer and have it point to NULL) Kaz Kylheku <kaz@kylheku.com> - 2014-04-23 04:37 +0000
      Re: non-NULL pointers which have the value 0 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-23 06:14 +0000
  Re: free a pointer and have it point to NULL Kaz Kylheku <kaz@kylheku.com> - 2014-04-22 22:18 +0000
  Re: free a pointer and have it point to NULL Michael Angelo Ravera <maravera@prodigy.net> - 2014-05-03 01:00 -0700

csiph-web