This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug malloc/14981] mtrace realloc


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]