Pete Wilson : Consultant Software Engineer
Lowell MA 978.454.4547 pete at pwilson dot net April 2008
Subject: Surprising change in C99's realloc
From: Tony Finch
X-Attribution: fanf hates supercite
Organization: dotat labs
Originator: fanf@news.chiark.greenend.org.uk ([127.0.0.1])
Date: Fri Jan 17 11:13:05 EST 2003
Lines: 45
X-Trace: DXC==BU:QGOJJ7nLdf0KjAEFMhC:3:I]XOl0dJl0i8e2XJ0`Gd@W2nGf1Gl
Here's a table for the expression ret = realloc(ptr, size)
ptr ret size semantics
NULL NULL >0 unsuccessful allocation
NULL valid >0 successful allocation
valid NULL >0 unsuccessful allocation, ptr not freed
valid valid >0 successful allocation, ptr has been freed
NULL NULL 0 no-op
NULL valid 0 successful zero-size allocation
valid NULL 0 ?????
valid valid 0 successful zero-size allocation, ptr has been freed
In the successful cases, ret subsequently needs to be freed in
order to avoid space leaks.
C99 says:
7.20.3.4p3: "... If memory for the new object cannot be allocated,
the old object is not deallocated and its value is unchanged."
7.20.3.4p4: "The realloc function returns ... a null pointer if the new
object could not be allocated."
It omits the text from C89:
7.10.3.4p2: "... If size is zero and ptr is not a null pointer, the
object it points to is freed."
In the ????? case, the rationale and C89 say that ptr has been freed
but C99 says not. As far as I know all implementations have the old
behaviour and are documented as such (pre-ANSI realloc was so bad it
was useless so everyone adopted the improvements); the FAQ says so
too. This change means that a program that wants to be portable between
C89 and C99 cannot use realloc in this commonly documented manner;
I expect it will introduce space leaks into previously-working code.
Tony.
comp.std.c #61711
From: Dan.Pop@cern.ch (Dan Pop)
Subject: Re: Surprising change in C99's realloc
Date: Fri Jan 17 11:49:00 EST 2003
Organization: DESY Zeuthen
Lines: 58
X-Trace: sunnews.cern.ch 1042822140 28759 (None) 137.138.161.126
X-Complaints-To: news@sunnews.cern.ch
X-Newsreader: NN version 6.5.1 (NOV)
In Tony Finch writes:
>Here's a table for the expression ret = realloc(ptr, size)
>
>ptr ret size semantics
>
>NULL NULL >0 unsuccessful allocation
>NULL valid >0 successful allocation
>valid NULL >0 unsuccessful allocation, ptr not freed
>valid valid >0 successful allocation, ptr has been freed
>NULL NULL 0 no-op
>NULL valid 0 successful zero-size allocation
>valid NULL 0 ?????
>valid valid 0 successful zero-size allocation, ptr has been freed
>
>In the successful cases, ret subsequently needs to be freed in
>order to avoid space leaks.
>
>C99 says:
>
>7.20.3.4p3: "... If memory for the new object cannot be allocated,
>the old object is not deallocated and its value is unchanged."
>
>7.20.3.4p4: "The realloc function returns ... a null pointer if the new
>object could not be allocated."
>
>It omits the text from C89:
>
>7.10.3.4p2: "... If size is zero and ptr is not a null pointer, the
>object it points to is freed."
>
>
>In the ????? case, the rationale and C89 say that ptr has been freed
>but C99 says not.
It does, too:
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.
The semantics of a null pointer return, when size is zero, are also
clearly described (7.20.3):
If the size
of the space requested is zero, the behavior is implementation-
defined: either a null pointer is returned, or the behavior is
as if the size were some nonzero value, except that the returned
pointer shall not be used to access an object.
This doesn't mean allocation failure, therefore the first sentence of
7.20.3.4p2 applies.
Dan
comp.std.c #61712
Subject: Re: Surprising change in C99's realloc
From: Tony Finch
X-Attribution: fanf hates supercite
Organization: dotat labs
Originator: fanf@news.chiark.greenend.org.uk ([127.0.0.1])
Date: Fri Jan 17 13:22:39 EST 2003
Lines: 33
X-Trace: DXC=>cL:OT];O6D815b7XmcnBFC:3:I]XOl0DJl0i8e2XJ0@Gd@W2nGf1GL
Dan.Pop@cern.ch (Dan Pop) wrote:
>Tony Finch writes:
>>
>>In the ????? case, the rationale and C89 say that ptr has been freed
>>but C99 says not.
>
>It does, too:
>
>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 read that as describing what happens when things go right. The "Returns"
paragraph says that a NULL return is a failure, in which case you have
to read other text to find out what happens.
>The semantics of a null pointer return, when size is zero, are also
>clearly described (7.20.3): [...]
>This doesn't mean allocation failure, therefore the first sentence of
>7.20.3.4p2 applies.
With that reading it's indeterminate whether ptr is freed when realloc
returns NULL with a zero size argument, because you can't tell if
realloc succeeded or failed.
If it's open to different interpretations like this then it's more
defective than I thought.
Tony.
comp.std.c #61722
From: Dan.Pop@cern.ch (Dan Pop)
Subject: Re: Surprising change in C99's realloc
Date: Mon Jan 20 08:03:47 EST 2003
Organization: DESY Zeuthen
Lines: 38
X-Trace: sunnews.cern.ch 1043067827 17083 (None) 137.138.161.126
X-Complaints-To: news@sunnews.cern.ch
X-Newsreader: NN version 6.5.1 (NOV)
Tony Finch writes:
>Dan.Pop wrote:
>>Tony Finch writes:
>>>
>>>In the ????? case, the rationale and C89 say that ptr has been freed
>>>but C99 says not.
>>
>>It does, too:
>>
>>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 read that as describing what happens when things go right. The "Returns"
>paragraph says that a NULL return is a failure, in which case you have
>to read other text to find out what happens.
>
>>The semantics of a null pointer return, when size is zero, are also
>>clearly described (7.20.3): [...]
>>This doesn't mean allocation failure, therefore the first sentence of
>>7.20.3.4p2 applies.
>
>With that reading it's indeterminate whether ptr is freed when realloc
>returns NULL with a zero size argument, because you can't tell if
>realloc succeeded or failed.
>
>If it's open to different interpretations like this then it's more
>defective than I thought.
In my reading of 7.20.3, an allocation request of zero bytes can
never fail.
Dan
--