This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug malloc/14981] mtrace realloc
- From: "bugdal at aerifal dot cx" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Sun, 23 Dec 2012 02:31:08 +0000
- Subject: [Bug malloc/14981] mtrace realloc
- Auto-submitted: auto-generated
- References: <bug-14981-131@http.sourceware.org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=14981
Rich Felker <bugdal at aerifal dot cx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bugdal at aerifal dot cx
--- Comment #1 from Rich Felker <bugdal at aerifal dot cx> 2012-12-23 02:31:08 UTC ---
This program has a memory leak. On glibc, malloc(0) and realloc(i, 0) both
return a unique pointer that cannot be dereferenced. Failure to free this
pointer is a memory leak.
realloc(i, 0) is only equivalent to free(i) on implementations where malloc(0)
returns 0.
I suspect you're confused by the language in POSIX that says "If size is 0 and
ptr is not a null pointer, the object pointed to is freed." This does not
preclude a memory leak. Note that POSIX later says "If size is 0, either a null
pointer or a unique pointer that can be successfully passed to free() shall be
returned." The confusion stems from the fact that POSIX has misleadingly
reworded the specification of free to refer to "changing the size of an
object", a concept which ISO C intentionally avoids. In the ISO C language, a
successful realloc _always_ frees the original object, and returns a pointer to
a new object with the same contents (up to the minimum of the old and new
size).
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.