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