This is the mail archive of the gcc@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: malloc attributes and realloc


Daniel Jacobowitz <drow@mvista.com> writes:

| On Thu, Jan 01, 2004 at 05:06:35PM -0500, Jeff Sturm wrote:
| > On 1 Jan 2004, Gabriel Dos Reis wrote:
| > > | >> Can __attribute__((__malloc__)) safely be used on realloc-type
| > > | >> functions?
| > > | >
| > > | > My non-expert understanding is "no"...
| > > | >
| > > | >> /* Reallocate memory without fail.  This works like xmalloc.  Note,
| > > | >>    realloc type functions are not suitable for attribute malloc since
| > > | >>    they may return the same address across multiple calls. */
| > > | >
| > > | > This comment is misleading.  The pointer address returned by a
| > > | > malloc-type
| > > | > function isn't significant to alias analysis.
| > > |
| > > | This isn't true.
| > > | It's quite significant, because it means it can't be the same pointer
| > > | as before.
| > >
| > > Well, technically, it could be as hinted by the standard:
| > >
| > >        [#4] The realloc function  returns  a  pointer  to  the  new
| > >        object  (which  may  have the same value as a pointer to the
| > >        old object), or a null pointer if the new object  could  not
| > >        be allocated.
| > 
| > So, out of curiosity, what happens in an example like:
| > 
| > #include <stdlib.h>
| > int f(void) {
| >   int *p, *q;
| >   p = malloc(sizeof(int));
| >   *p = 0;
| >   q = realloc(p, sizeof(int));
| >   if (p == q) {
| >     *p = 1;
| >     return *q;
| >   }
| >   return 0;
| > }
| > 
| > Does the alias machinery determine that p,q alias after all?  Or is this
| > illegal for some reason?
| 
|        [#2] The realloc function deallocates the old object pointed
|        to by ptr and returns a pointer to a new object that has the
|        size specified by size.
| 
| I don't _think_ that you can validly make comparisons to a pointer
| after it has been freed.

Well, in general -- i.e. taken out of context -- I agree with your
sentence. 

However, in this specific context, the C standard does not say that
the object is deallocated through call to the standard free() function. 

There is a paragraph about lifetime and when a pointer value becomes
indeterminate 

       6.2.4  Storage durations of objects

       [...]

       [#2]  The  lifetime  of  an object is the portion of program
       execution during which storage is guaranteed to be  reserved
       for it.  An object exists, has a  constant  address,25)  and
       retains its last-stored value throughout  its  lifetime.26)
       If  an  object  is  referred to outside of its lifetime, the
       behavior is undefined.   The  value  of  a  pointer  becomes
       indeterminate  when  the object it points to reaches the end
       of its lifetime.

And it is not clear that you can conclude from this that the behaviour
is undefined.  If realloc returns a pointer that is equal to its
argument, it is clear that the storage is guranteed to be reserved for
the object pointed to.  But if it does return a different value, then
the behaviour becomes undefined.  That is, I think, what Joseph was
alluding to with his "bits compare". 

-- Gaby


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