realloc bug

Joel Sherrill joel.sherrill at OARcorp.com
Thu Sep 4 19:45:23 UTC 2003


Kamen Penev wrote:

> I submitted this with GNATS, and it said it took it, but I never
> received the confirmation email and it doesn't show up in the query, so
> here it is again:

I don't know why you didn't receive the confirmation email but
I got email that it was filed as PR479.  I confirmed that
the Open Group Single UNIX Specification defined the same behavior
and then committed a fix to both the CVS trunk and 4.6 branch.
I then closed it.  According to its history, it lasted about 8
hours. :)

Arrival-Date: 	Wed Sep 03 21:34:00 CDT 2003
Closed-Date: 	Thu Sep 04 07:43:15 CDT 2003

Thanks for the fix.

> Synopsis: realloc deallocates argument pointer if new_area cannot be
> obtained
> Release: RTEMS-4.5 ss20030417
> Description:
> Accordingly to "C Reference Manual", p. 388, documentation of realloc:
> 
> "If the request cannot be satisfied, a null pointer is returned and the
> old region is not disturbed."
> 
> However, the RTEMS definition of realloc contains this:
> -----------------------------------
>  new_area = malloc( size );
> 
>  MSBUMP(malloc_calls, -1);   /* subtract off the malloc */
> 
>  if ( !new_area ) {
>    free( ptr );
>    return (void *) 0;
>  }
> -----------------------------------
> 
> free( ptr ) is erroneous and should be removed. When realloc fails, the
> old region must remain intact.
> 
> How-To-Repeat:
> Allocate an array and keep growing it with realloc until realloc fails.
> 
> Fix:
> Remove the call to free() at malloc.c:282.
> 





More information about the users mailing list