public inbox for linux-man@vger.kernel.org
 help / color / mirror / Atom feed
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

  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