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