From: Michael Kerrisk <mtk.manpages-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
To: Mike Frysinger <vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>
Cc: "Michael Kerrisk"
<mtk.manpages-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>,
"Lasse Kärkkäinen"
<tronic-ze05kZMmeybHOG6cAo2yLw@public.gmane.org>,
linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: Error in man page: realloc(ptr, 0) is not equivalent to free(ptr)
Date: Tue, 26 Feb 2008 16:12:32 +0100 [thread overview]
Message-ID: <47C42C60.20004@gmail.com> (raw)
In-Reply-To: <200802230138.11461.vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>
Mike Frysinger wrote:
> On Friday 22 February 2008, Michael Kerrisk wrote:
>> On Thu, Feb 21, 2008 at 7:59 AM, Mike Frysinger <vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org> wrote:
>>> On Thursday 21 February 2008, Lasse Kärkkäinen wrote:
>>> > The man page says that realloc(ptr, 0) is equivalent to free, even
>>> > though it isn't. The text on the man page says
>>> >
>>> > ---
>>> > realloc() changes the size of the memory block pointed to by ptr to
>>> > size bytes. The contents will be unchanged to the minimum of the old
>>> > and new sizes; newly allocated memory will be uninitialized. If
>>> > ptr is NULL, the call is equivalent to malloc(size); if size is
>>> > equal to zero, the call is equivalent to free(ptr). Unless ptr is
>>> > NULL, it must have been returned by an earlier call to malloc(),
>>> > calloc() or realloc(). If the area pointed to was moved, a free(ptr)
>>> > is done. [...]
>>> > realloc() returns a pointer to the newly allocated memory, which is
>>> > suitably aligned for any kind of variable and may be different from
>>> > ptr, or NULL if the request fails. If size was equal to 0, either
>>> > NULL or a pointer suitable to be passed to free() is returned. If
>>> > realloc() fails the original block is left untouched; it is not freed
>>> > or moved.
>>>
>>> i would just word it to say that when realloc() is given a size of 0, it
>>> is implementation defined as to the behavior, but it tends to match the
>>> behavior of malloc(0) (which too is implementation defined). POSIX and
>>> C99 allow both cases to return either a NULL pointer or a "unique"
>>> pointer. glibc will return a unique pointer (which cannot actually be
>>> used to store anything), but uClibc may return NULL.
>>> -mike
>> Lasse, thanks for raising this; Mike, thanks for your input.
>>
>> For man-pages-2.79, I propose to amend the description of realloc() to be:
>>
>> realloc() changes the size of the memory block pointed to
>> by ptr to size bytes. The contents will be unchanged to
>> the minimum of the old and new sizes; newly allocated
>> memory will be uninitialized. If ptr is NULL, then the
>> call is equivalent to malloc(size); if size is equal to
>> zero, and ptr is not NULL, then the call is equivalent to
>> free(ptr). Unless ptr is NULL, it must have been
>> returned by an earlier call to malloc(), calloc() or
>> realloc(). If the area pointed to was moved, a free(ptr)
>> is done.
>
> a quick read and it leaves me wondering "what if i call realloc(NULL, 0) ?".
> if i re-read it a few times, i can work out that the documentation, by not
> saying anything about size in the first statement, implies that malloc(size)
> is for all values of size. but perhaps that should be made explicit ?
>
> ... If ptr is NULL, then the call is equivalent to malloc(size) for all values
> of size; ...
Yes, good idea. I've made that change.
> otherwise, it looks good to me, thanks
Thanks for checking it over.
Cheers,
Michael
--
Michael Kerrisk
Maintainer of the Linux man-pages project
http://www.kernel.org/doc/man-pages/
Want to report a man-pages bug? Look here:
http://www.kernel.org/doc/man-pages/reporting_bugs.html
next prev parent reply other threads:[~2008-02-26 15:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-21 6:26 Error in man page: realloc(ptr, 0) is not equivalent to free(ptr) Lasse Kärkkäinen
[not found] ` <47BD19AF.4000101-ze05kZMmeybHOG6cAo2yLw@public.gmane.org>
2008-02-21 6:59 ` Mike Frysinger
[not found] ` <200802210159.03465.vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>
2008-02-22 10:15 ` Michael Kerrisk
[not found] ` <cfd18e0f0802220215l6e61ab90h4a2d9b2e3e2a194d-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-02-23 6:38 ` Mike Frysinger
[not found] ` <200802230138.11461.vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>
2008-02-26 15:12 ` Michael Kerrisk [this message]
2008-02-23 8:10 ` Chris "ク" Heath
[not found] ` <1203754246.3021.104.camel-DBi1IKlRe8YXiSwHZUBl+UgmxNRb6L7S@public.gmane.org>
2008-02-23 8:41 ` Mike Frysinger
2008-02-26 15:12 ` Michael Kerrisk
[not found] ` <47C42C68.405-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2008-03-02 13:01 ` Michael Kerrisk
[not found] ` <cfd18e0f0803020501y4e803b6dk5479db1f1f36b37-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-03-02 23:53 ` Chris "ク" Heath
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47C42C60.20004@gmail.com \
--to=mtk.manpages-gm/ye1e23mwn+bqq9rbeug@public.gmane.org \
--cc=linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=tronic-ze05kZMmeybHOG6cAo2yLw@public.gmane.org \
--cc=vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox