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
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
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
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
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)
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
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
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
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).
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
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
11 matches
Mail list logo