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

Groups > comp.lang.c > #43840

Re: free a pointer and have it point to NULL

Show all headers | View raw

Keith Thompson <kst-u@mib.org> writes:
> James Kuyper <jameskuyper@verizon.net> writes:
> [...]
>> Keep in mind that it is possible for the value of a pointer to become
>> indeterminate without any change to it's bit patterns. There are real
>> systems which have the ability to make blocks of memory switch from
>> being valid to being invalid while a program is running, and because of
>> the clauses listed above, a fully conforming implementation of free()
>> could have that effect.
>>
>> I personally believe that such changes are the only permitted way for
>> free() to render a pointer invalid - that it is not permitted to modify
>> the bit pattern of the pointer itself. However, I've had extended
>> discussions about that on this newsgroup with people who felt otherwise,
>> with neither side ever accepting the validity of the other's arguments.
>>
>> Keep in mind that all pointers anywhere in the program that point at any
>> part of an allocated block of memory have an indeterminate value after
>> that block is deallocated. Nothing remotely resembling the normal
>> semantics for C function calls would allow all of those pointers to have
>> their bit patterns modified just by calling free() on one of those pointers.
>
> A compiler could treat the free() function specially, but it's unlikely
> that
>
>     char *p = malloc(10);
>     if (p ! NULL) {
>         p ++;
>         free(p-1);
>     }
>
> would modify the representation if p.
>
> Furthermore, the bytes that make up the representation of p are
> themselves objects which "retain their last-stored values between
> program startup and program termination".
>
> On the other hand, I seem to recall that there's a DR that says free()
> *can* change the representation of a pointer object after its value is
> passed to free().  I'll try to track it down later.

It's C99 DR #260, submitted by Clive D.W. Feather in 2004.
http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_260.htm

As far as I can tell, the DR didn't lead to any specific wording in the
C11 standard, but the committee response was:

    Question 1:
    Values may have any bit-pattern that validly represents them 
    and the implementation is free to move between alternate
    representations (for example, it may normalize pointers,
    floating-point representations etc.). In the case of an
    indeterminate value all bit-patterns are valid representations
    and the actual bit-pattern may change without direct action of
    the program.

    Question 2:
    If two objects have identical bit-pattern representations and 
    their types are the same they may still compare as unequal
    (for example if one object has an indeterminate value) and if
    one is an indeterminate value attempting to read such an object
    invokes undefined behavior. Implementations are permitted to 
    track the origins of a bit-pattern and treat those representing 
    an indeterminate value as distinct from those representing a
    determined value. They may also treat pointers based on different
    origins as distinct even though they are bitwise identical.

In reference to "Question 1", I agree that it makes sense to permit an
implementation to normalize pointers and floating-point objects when two
or more representations have the same value.  I wrote above that the
bytes making up the representation of an object are themselves objects,
which are required by 6.2.4p2 to "retain[] its last-stored value
throughout its lifetime".

I'm no longer quite as sure of that, given the way 6.2.6.1 defines
*object representation*:

    Values stored in non-bit-field objects of any other object type
    consist of n × CHAR_BIT bits, where n is the size of an object
    of that type, in bytes. The value may be copied into an object
    of type unsigned char [n] (e.g., by memcpy); the resulting set
    of bytes is called the *object representation* of the value.

which talks about the bytes *after copying them from the object*,
so at least that paragraph doesn't imply that the bytes within the
object itself are objects.

On the other hand, an object is defined as a "region of data storage in
the execution environment, the contents of which can represent values";
a byte within a pointer object, for example, would seem to qualify.

On the other other hand, a program that depends on a byte within a freed
pointer retaining its previous value would be perverse, and I don't feel
*too* bad about the possibility of breaking it.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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