Memory leak in ev.c

2013-02-20 Thread Alexander Klauer
Hi, in ev.c, there is the definition #define ev_free(ptr)ev_realloc ((ptr), 0) This causes a memory leak on systems where zero-sized objects are being kept track of. Therefore, I suggest this definition to be changed to #define ev_free(ptr)free ((ptr)) A patch to this effect has bee

Re: Memory leak in ev.c

2013-02-20 Thread Alexander Klauer
Hi, On 02/20/2013 04:42 PM, Alexander Klauer wrote: in ev.c, there is the definition #define ev_free(ptr)ev_realloc ((ptr), 0) This causes a memory leak on systems where zero-sized objects are being kept track of. Therefore, I suggest this definition to be changed to #define ev_free(p

Re: Memory leak in ev.c

2013-02-20 Thread Alexander Klauer
Hi, forget my last post, I wasn't thinking properly. Sorry for the noise. Best regards, Alexander ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev

Memory leak in ev.c, the second

2013-02-20 Thread Alexander Klauer
Hi, let's see if I get it right this time. libev maps allocation, reallocation, and freeing of memory to calls of one single function, set by ev_set_allocator(), or the default ev_realloc_emul(). The libev API specification mandates that the allocator function fulfils the requirements of real

Re: Memory leak in ev.c

2013-02-20 Thread Marc Lehmann
On Wed, Feb 20, 2013 at 04:42:54PM +0100, Alexander Klauer wrote: > #define ev_free(ptr)ev_realloc ((ptr), 0) > > This causes a memory leak on systems where zero-sized objects are Only if the user-supplied allocator is buggy - the default implementation calls free. > #define ev_free(ptr)

Re: Memory leak in ev.c

2013-02-20 Thread Marc Lehmann
On Wed, Feb 20, 2013 at 04:50:33PM +0100, Alexander Klauer wrote: > alternatively, one might also change ev_realloc_emul() in the same > file to keep only the #else part of the #ifdef __GLIBC__. This might > be the better solution if there are non-standard systems out there > which do not properl

Re: Memory leak in ev.c

2013-02-20 Thread Alexander Klauer
Hi Marc, On 02/20/2013 06:04 PM, Marc Lehmann wrote: libev doesn't run on systems that don't implement free(0) (which ones, anyway?) - maybe you are meaning something else? Also, there is no such #ifdef in ev_realloc_emul anymore - you are looking at old code it seems. yep, I see it now, it

Re: Memory leak in ev.c, the second

2013-02-20 Thread Marc Lehmann
On Wed, Feb 20, 2013 at 05:28:57PM +0100, Alexander Klauer wrote: > semantics as a call to free(ptr). A C89-conformant implementation may > return a unique non-NULL pointer which may be safely passed to > free(). And when does this happen *in libev*? realloc frees the memory for cases where the

Re: Memory leak in ev.c

2013-02-20 Thread Marc Lehmann
On Wed, Feb 20, 2013 at 06:12:50PM +0100, Alexander Klauer wrote: > documentation of ev_set_allocator() because realloc(ptr, 0) is not > required by C89 to have the same semantics as free(ptr) (see other > thread). True, but in the important cases, it is required to be equivalent to free (ptr).

Re: Memory leak in ev.c

2013-02-20 Thread Kevyn-Alexandre Paré
Hi, This is not causing a memory leak. The man page of realloc says that: if size is equal to zero, and ptr is not NULL, then the call is equivalent to free(ptr). My only concern about this way of freeing is about that post: https://www.securecoding.cert.org/confluence/display/seccode/MEM04

Re: Memory leak in ev.c

2013-02-20 Thread Marc Lehmann
On Wed, Feb 20, 2013 at 12:24:35PM -0500, Kevyn-Alexandre Paré wrote: > My only concern about this way of freeing is about that post: > > https://www.securecoding.cert.org/confluence/display/seccode/MEM04-C.+Do+not+perform+zero-length+allocations I am not a friend of the secure coding standards