Memory leak in ev.c, the second

Alexander Klauer Alexander.Klauer at itwm.fraunhofer.de
Fri Feb 22 16:48:55 CET 2013


Hi,

On 02/21/2013 04:01 PM, Marc Lehmann wrote:
> The C89 standard says (any typos are mine):
>
>     7.10.3.4 the realloc function
>
>     [...]
>
>     If size is zero and ptr is not a null pointer, the object it points to is
>     freed.
>
> Your quote is from 7.10.3, and only applies if an allocation is actually
> requested ("If the size of the space requested..."), which isn't the case
> for the case above.

taking 7.10.3.4 into account, yes, I agree.

> If you want to argue that the ISO-C requirement "the object it points to
> is freed" does not mean free(ptr) or an equivalent is called then we will
> have to disagree.

I agree it means free(ptr). I wasn't aware of the wording change. Thanks 
for the heads-up.

So, in essence, this means the current glibc realloc() violates the C89 
standard but is C99-conformant? I like the C89 behaviour – it enables 
one to wrap all allocation business neatly into one single function. 
Yet, the defect report you pointed out appears to undermine this usage 
even further.

As for libev, for the benefit of its users, I suggest to explain the 
expected behaviour of the allocator function explicitly in the 
documentation, to avoid confusion due to more recent standards steering 
more and more away from the C89 realloc() specification. I have attached 
a patch for ev.pod to that effect.

Best regards,
Alexander
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libev.patch
Type: text/x-patch
Size: 1895 bytes
Desc: not available
URL: <http://lists.schmorp.de/pipermail/libev/attachments/20130222/18f07813/attachment.bin>


More information about the libev mailing list