On Fri, Feb 22, 2013 at 04:48:55PM +0100, Alexander Klauer
alexander.kla...@itwm.fraunhofer.de wrote:
So, in essence, this means the current glibc realloc() violates the
C89 standard but is C99-conformant?
I think the problem was that the C89 wording was confusing, and the
way to proceed was
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
Hi,
On 02/20/2013 06:16 PM, Marc Lehmann wrote:
On Wed, Feb 20, 2013 at 05:28:57PM +0100, Alexander Klauer
alexander.kla...@itwm.fraunhofer.de 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().
D'oh, will I ever get it right? Find the correct version of libev.c
attached.
Best regards,
Alexander
#includeassert.h
#includeev.h
#includestdlib.h
static void * allocator( void * ptr, long size ) {
assert( ( size = 0 ) ( ( unsigned long ) size = ( size_t ) -1 ) );
return realloc( ptr,
On Thu, Feb 21, 2013 at 10:39:20AM +0100, Alexander Klauer
alexander.kla...@itwm.fraunhofer.de wrote:
1. if size is equal to zero, and ptr is
not NULL, then the call is equivalent to free(ptr).
The last assertion is incorrect. See 4. for a proof on concept in
libev below.
That assertion was
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
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
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
On Wed, Feb 20, 2013 at 04:42:54PM +0100, Alexander Klauer
alexander.kla...@itwm.fraunhofer.de 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
On Wed, Feb 20, 2013 at 04:50:33PM +0100, Alexander Klauer
alexander.kla...@itwm.fraunhofer.de 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
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,
On Wed, Feb 20, 2013 at 05:28:57PM +0100, Alexander Klauer
alexander.kla...@itwm.fraunhofer.de 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
On Wed, Feb 20, 2013 at 06:12:50PM +0100, Alexander Klauer
alexander.kla...@itwm.fraunhofer.de 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
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:
On Wed, Feb 20, 2013 at 12:24:35PM -0500, Kevyn-Alexandre Paré
kap...@rogue-research.com 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
16 matches
Mail list logo
