Chris, Ping! Did you have anything further to add? Cheers, Michael On Tue, Feb 26, 2008 at 4:12 PM, Michael Kerrisk<mtk.manpages@xxxxxxxxxxxxxx> wrote:>> Chris ク Heath wrote:> > On Fri, 2008-02-22 at 11:15 +0100, Michael Kerrisk wrote:> >> On Thu, Feb 21, 2008 at 7:59 AM, Mike Frysinger <vapier@xxxxxxxxxx> 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.> >> > Hmmm. The phrase> >> > if size is equal to> > zero, and ptr is not NULL, then the call is equivalent to> > free(ptr).> >> > seems to contradict the following sentence, found under RETURN VALUES:> >> > If size was equal to 0, either NULL> > or a pointer suitable to be passed to free() is returned.> >> > If realloc(ptr, 0) can return a non-NULL pointer, then it isn't> > equivalent to free(ptr).> >> > So which one is correct? My tests with glibc 2.6 indicate that> > realloc(ptr, 0) always returns NULL, so it IS equivalent to free(ptr).> > However, I don't know if that is guaranteed to always be the case.>> Chris,>> The text under RETURN VALUE is quite close to the POSIX.1 spec for> realloc(), which says this:>> If size is 0, either a null pointer or a> unique pointer that can be successfully passed to free()> shall be returned.>> After Mike's last suggestion, the body of the Linux man page says this:>> If ptr is NULL, then the> call is equivalent to malloc(size), for all values of> size; if size is equal to zero, and ptr is not NULL, then> the call is equivalent to free(ptr).>> So:>> a) If ptr is NULL, and size is zero, then realloc() is equivalent to> malloc(0), which does the following (as already documented in the Linux> malloc.3 man page):>> If size is 0, then malloc() returns either NULL, or a unique> pointer value that can later be successfully passed to free().>> That seems entirely consistent with the text under RETURN VALUE for the> Linux malloc.3 man page.>> b) If ptr is not NULL, and size is zero, then the standard isn't (AFAICS)> explicit about whether "a null pointer or a unique pointer that can be> successfully passed to free()" shall be returned, but the former certainly> seems more reasonable, and is what you observed for glibc.>>> 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>>> -- Michael KerriskMaintainer of the Linux man-pages projecthttp://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��.n��������+%����;��w��{.n�����{��f��)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
