This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug manual/1997] opern_memstream() buffer should be freed
- From: "decimal at us dot ibm dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: 12 Dec 2005 19:52:39 -0000
- Subject: [Bug manual/1997] opern_memstream() buffer should be freed
- References: <20051208155151.1997.michael.kerrisk@gmx.net>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From decimal at us dot ibm dot com 2005-12-12 19:52 -------
I took a look in the linux man pages and in the glibc manual and I found that
while the man page for strdup(3) does say
The strdup() function returns a pointer to a new string which is a
duplicate of the string s. Memory for the new string is obtained with
malloc(3), and can be freed with free(3).
the glibc manual info entry for strdup() says
This function copies the null-terminated string s into a newly allocated string.
The string is allocated using malloc; see Unconstrained Allocation. If malloc
cannot allocate space for the new string, strdup returns a null pointer.
Otherwise it returns a pointer to the new string.
The section on Unconstrained Allocation includes a section "Freeing after
Malloc" which discusses free().
The current section in the glibc manual on open_memstream() says
This function opens a stream for writing to a buffer. The buffer is allocated
dynamically (as with malloc; see Unconstrained Allocation) and grown as necessary.
So is it really necessary to explicitly mention free() next to every function
which uses malloc()? I'm asking to see if anyone else has a strong opinion.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=1997
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.