On Wed, Jun 20, 2012 at 10:25:02AM +0800, yao liufeng <ylf...@163.com> wrote:
> > if size is equal to zero, and ptr is not NULL, then the call is
> > equivalent to free(ptr)
> >
> After doing some research, I think the issue is not about realloc(ptr, 0),
> it's about realloc(NULL, 0). According to C99 standard, malloc()
> If the size of the space requested is zero, the behavior is
> implementation-defined.
> If ptr is null, the realloc function behaves like the malloc function
> for the specified size.According to glibc, If n is zero, malloc
> returns a minumum-sized chunk. (The minimum
then debian broke compatibility with itself, because earleir manpages
document the traditional malloc(0)=0 behaviour of malloc.
debian should not have broken backwards compatibility when it can choose
between compatible implementation defined behaviour and incompatible
implementatioon defined behaviour, so this is a bug in debian in any case.
> And, just adding some trace to libev, we can find between ev_loop_new() and
> ev_loop_destroy(), several ev_realloc_emual(NULL, 0), by default
> realloc(NULL, 0) was triggered. This can explain where the memory leaks are
> from. And it's better for libev to deal with this situation.
As I said, yes, libev will work aorund this bug, but libev cannot deal
with this situation itself, because the problem is not in libev. If debian
chose to break all correct programs because they feel they need to change
malloc semantics then libev can't doa ynthing about this, as libev is
cetrainly not the only program that relied on documented behaviour here.
so libev can work around this in its own code, but not deal with this bug
in general.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schm...@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
