[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <o2zomxu44jyabsfedqvluw3ynuzbp2xuyykesejb2nzjyiktqc@jvzmiwibv3ln>
Date: Fri, 27 Jun 2025 03:51:26 +0200
From: Alejandro Colomar <alx@...nel.org>
To: Mark Harris <mark.hsj@...il.com>
Cc: libc-alpha@...rceware.org, bug-gnulib@....org, musl@...ts.openwall.com,
наб <nabijaczleweli@...ijaczleweli.xyz>, Douglas McIlroy <douglas.mcilroy@...tmouth.edu>,
Paul Eggert <eggert@...ucla.edu>, Robert Seacord <rcseacord@...il.com>,
Elliott Hughes <enh@...gle.com>, Bruno Haible <bruno@...sp.org>,
JeanHeyd Meneide <phdofthehouse@...il.com>, Rich Felker <dalias@...c.org>,
Adhemerval Zanella Netto <adhemerval.zanella@...aro.org>, Joseph Myers <josmyers@...hat.com>,
Florian Weimer <fweimer@...hat.com>, Laurent Bercot <ska-dietlibc@...rnet.org>,
Andreas Schwab <schwab@...e.de>, Thorsten Glaser <tg@...bsd.de>, Eric Blake <eblake@...hat.com>,
Vincent Lefevre <vincent@...c17.net>, Collin Funk <collin.funk1@...il.com>,
Wilco Dijkstra <Wilco.Dijkstra@....com>, DJ Delorie <dj@...hat.com>,
Cristian Rodríguez <cristian@...riguez.im>, Siddhesh Poyarekar <siddhesh@...plt.org>,
Sam James <sam@...too.org>, Mark Wielaard <mark@...mp.org>,
"Maciej W. Rozycki" <macro@...hat.com>, Martin Uecker <ma.uecker@...il.com>,
Christopher Bazley <chris.bazley.wg14@...il.com>, eskil@...ession.se,
Daniel Krügler <daniel.kruegler@...glemail.com>, Kees Cook <keescook@...omium.org>,
Valdis Klētnieks <valdis.kletnieks@...edu>
Subject: Re: alx-0029r5 - Restore the traditional realloc(3) specification
Hi Mark,
On Thu, Jun 26, 2025 at 05:44:49PM -0700, Mark Harris wrote:
> > Rationale
> > The specification of realloc(3) has been problematic since the
> > very first standards, even before ISO C. The wording has
> > changed significantly, trying to forcedly permit implementations
> > to return a null pointer when the requested size is zero. This
> > originated from the intent of banning zero-sized objects from
> > the language in C89, but that never worked well in
> > retrospective, as we can see from the fallout.
>
> I support the outcome that you are trying to achieve, however I think
> the proposal could use a better explanation upfront as to what problem
> this is attempting to solve. Calling a well-established function like
> realloc "problematic" without explaining what is problematic about it
> isn't helpful.
If you go a few paragraphs below, you'll find that there have been RCE
vulnerabilities because people don't know how to use it correctly.
I've personally fixed many bugs in old calls to realloc(3) in projects
like shadow utils.
> This states that the wording has changed
> significantly, but if that was the problem then a proposal to change
> the wording again is clearly not addressing that.
The problem was in trying to come up with a wording that accepted all
existing implementations, which isn't easy or even useful.
My proposal is not to attempt to reword the same thing, but rather
prohibit the weird implementations so that we remain with something
simple that can be worded without mistakes.
> Also I'm pretty sure that this did not originate from the intent of
> banning zero-sized objects from the language. If there was an actual
> effort to ban the possibility of zero-sized objects then it would have
> been easier for them to simply define malloc(0) and realloc(p, 0) to
> always be an error.
They probably weren't brave enough to break the BSDs. But I know there
was intention in the committee of removing zero-sized objects.
> It seems far more likely that the committee was
> just trying to document the current behavior that programmers could
> rely on, without unnecessarily making current implementations
> nonconforming.
>
> >
> > None of the specifications have been good, and C23 finally gave
> > up and made it undefined behavior.
> >
> > The problem is not only theoretical. Programmers don't know how
> > to use realloc(3) correctly, and have written weird code in
> > their attempts. This has resulted in a lot of non-sensical code
> > in configure scripts[1], and even bugs in actual programs[2].
> >
> > [1] <https://codesearch.debian.net/search?q=%5Cbrealloc%5B+%5Ct%5D*%5B%28%5D%5B%5E%2C%5D*%2C%5B+%5Ct%5D0%5B%29%5D&literal=0>
>
> It's not clear what you are claiming is nonsensical here or why. You
> think that configure checks are in general nonsensical, or what is it
> about these checks in particular that is nonsensical?
I'm claiming that people write code that doesn't do what they think it
does, just because they know realloc(3) is broken and try to workaround
it. Without going too far, here's the code I've seen in FreeBSD's
implementation of reallocf(3):
$ grepc -htfd reallocf .
void *
reallocf(void *ptr, size_t size)
{
void *nptr;
nptr = realloc(ptr, size);
/*
* When the System V compatibility option (malloc "V" flag) is
* in effect, realloc(ptr, 0) frees the memory and returns NULL.
* So, to avoid double free, call free() only when size != 0.
* realloc(ptr, 0) can't fail when ptr != NULL.
*/
if (!nptr && ptr && size != 0)
free(ptr);
return (nptr);
}
The last sentence in the comment is false, and this code has a memory
leak. I'll leave it as an exercise to the reader to figure out why.
(Of course, I've already reported the bug, just a few days ago.)
> > [2] <https://lore.kernel.org/lkml/20220213182443.4037039-1-keescook@chromium.org/>
> >
> > In some cases, this non-sensical code has resulted in RCEs[3].
> >
> > [3] <https://awakened1712.github.io/hacking/hacking-whatsapp-gif-rce/>
>
> This is using reallocarray(), which comes from OpenBSD, and is not in
> ISO C at all. In OpenBSD it already had the desired behavior for size
> 0; an implementation of the OpenBSD reallocarray() that does not
> correctly match its behavior is just buggy. POSIX picked it up after
> Glibc and Bionic already created an implementation that did not match
> the OpenBSD behavior.
As you say, reallocarray(3) was later picked by glibc, where it was
implemented consistent with the realloc(3) in glibc, so both APIs have
inherently the same portability issues, and the only difference is in
the prevention of overflow in the multiplication.
Are you claiming that glibc has a buggy implementation of
reallocarray(3)?
alx@...ian:~/tmp$ cat ra.c
#include <stdio.h>
#include <stdlib.h>
int
main(void)
{
printf("%p\n", reallocarray(malloc(1), 0, 42));
perror("realloc");
}
alx@...ian:~/tmp$ gcc ra.c
alx@...ian:~/tmp$ ./a.out
(nil)
realloc: Success
I certainly agree with you; glibc is buggy; please fix it. On the other
hand, that has no effect on the matter:
People are confused about how to properly use realloc(3), and people
(correctly) assume reallocarray(3) ain't different, and thus they remain
confused about it too.
> > However, this doesn't need to be like that. The traditional
> > implementation of realloc(3), present in Unix V7, inherited by
> > the BSDs, and currently available in range of systems, including
> > musl libc, doesn't have any issues. glibc --which uses an
> > independent implemention rather than a Unix derivative-- also
> > had this behavior originally; it changed to the current behavior
> > in 1999 (glibc 2.1.1), only for compatibility with C89, even
> > though ironically C99 was released soon after and removed the
> > text that glibc was trying to comply to, and introduced some new
> > text that was very confusing, and one of its interpretations
> > would make the new glibc behavior non-conforming.
>
> s/in range/in a range/
> s/implemention/implementation/
> s/comply to/comply with/
Thanks!
> Assuming that you are referring to Seventh Edition Unix from 1979, it
> would be better to spell it out or write V7 Unix, to distinguish it
> from UNIX V7 (https://unix.org/unixv7.html) which refers to Issue 7 of
> the standard commonly known as POSIX.
Agree.
> Your claim that this 1979 implementation of realloc()[1] "doesn't have
> any issues" is grossly incongruent with reality. This realloc(p, n)
> first calls free(p), then malloc(n), and finally copies the data if
> the pointer has changed; at the time this was safe because there was
> no multithreading and free() and malloc() did not modify the contents
> of the memory block, however if realloc() failed it returned NULL with
> p freed (but you could still read the data from the freed block at
> least until the next allocation).
Hmm, yeah, I was aware of that, but my wording doesn't reflect it. I
should rephrase as "didn't have any issues regarding the handling of
zero-sized objects".
> Also this implementation of
> realloc() did not accept p == NULL; that would crash. However, a
> documented bonus feature not found in modern realloc() was that p
> could be "a block freed since the last call of malloc, realloc or
> calloc".[2]
That's an issue of free(3) in reality. If we say that the specification
of realloc(3) was to free(3) and malloc(3), then it's not realloc(3)'s
problem to say whether NULL is acceptable or not.
> [1] https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/libc/gen/malloc.c
> [2] https://man.cat-v.org/unix_7th/3/malloc
>
> Is this really the "traditional realloc(3) specification" that the
> title of this proposal is suggesting be restored? I suggest being
> more specific as to what you actually want.
Regarding zero-sized objects, yes. I guess what I want is the BSD
specification, which is the traditional one, but with the unrelated bugs
fixed, and a better free(3) that accepts NULL, which results in a
realloc(3) that accepts NULL. See the proposed wording, which just
defers to the specification of free(3).
> > Code written for platforms returning a null pointer can be
> > migrated to platforms returning non-null, without significant
> > issues.
> >
> > There are two kinds of code that call realloc(p,0). One
> > hard-codes the 0, and is used as a replacement of free(p). This
> > code ignores the return value, since it's unimportant. This
> > code currently produces a leak of 0 bytes plus associated
> > metadata on platforms such as musl libc, where it returns a
> > non-null pointer. However, assuming that there are programs
> > written with the knowledge that they won't ever be run on such
> > platforms, we should take care of that, and make sure they don't
> > leak. A way of accomplishing this would be to recommend
> > implementations to issue a diagnostic when realloc(3) is called
> > with a hardcoded zero. This is only an informal recommendation
> > made by this proposal, as this is a matter of QoI, and the
> > standard shouldn't say anything about it. This would prevent
> > this class of minor leaks.
>
> It used to be a common thing for a C library or function to allow
> overriding the allocator that it uses internally with your own custom
> allocator. Rather than having to specify multiple function pointers
> for your own custom malloc, free, realloc, etc. sometimes it would
> just take one function pointer for your custom realloc, with the
> default being libc realloc. The library would allocate memory using
> (*customalloc)(NULL, n), free it using (*customalloc)(p, 0), and
> realloc using (*customalloc)(p, n). This simplified the interface for
> overriding the allocator, and if it stored the custom allocator in
> each object then it only had to store one function pointer. The point
> is that I would expect calls to realloc that intend to only free
> memory are more likely to be indirect calls than direct calls that are
> easily diagnosed at compile time or with a simple search; for a direct
> call it is easier to just call free. That said, I haven't seen this
> kind of interface for years.
Good. For the few cases that may exist today, I guess they'll have
minor leaks of 0 bytes. I can live with that.
> Both Glibc and Bionic already annotate realloc with
> __attribute__((__warn_unused_result__)), so that should already warn
> about direct calls to realloc(p, 0) that don't use the result
> (indicating that the caller was likely intending to only free the
> memory and not get another block in return). I would consider that
> existing warning to be better than warning on any realloc(p, 0),
> because it avoids false positives when the caller is already handling
> any pointer that may be returned.
This is not enough. There are programs that call
p = realloc(p, 0);
as a compact spelling of
free(p);
p = NULL;
In such code, the attribute wouldn't trigger a diagnostic. Not that I
care much though. As I said, such a minor leak shouldn't be important.
But I mention that for completeness. Also, GCC maintainers seem in
favour of the diagnostic, even if just because C23 made it UB and thus
a diagnostic is needed, regardless of the outcome of this proposal.
> > Moreover, in glibc, realloc(p,0) may return non-null, in the
> > case where p is NULL, so code must already take that into
> > account, and thus code that simply takes realloc(p,0) as a
> > synonym of free(p) is already leaky, as free(NULL) is a no-op,
> > but realloc(NULL,0) allocates 0 bytes.
> >
> > The other kind of code is in algorithms that realloc(3) an
> > arbitrary size, which might eventually be zero. This gets more
> > complex.
> >
> > Here's the code that should be written for AIX or glibc:
> >
> > errno = 0;
> > new = realloc(old, size);
> > if (new == NULL) {
> > if (errno == ENOMEM)
> > free(old);
> > goto fail;
> > }
> > ...
> > free(new);
>
> That is ridiculous; I've never seen anyone else check errno to
> determine whether realloc has failed. It is far easier to just ensure
> that size is non-zero. Yes it would be even easier if you didn't need
> to ensure that, which is why I support your proposal, but it doesn't
> have anything to do with errno.
I had to take into account the most unreasonable cases, to make sure no
issues are possible. Of course, one can call realloc(p,n?:1) --which
I do--, or even not call it in the first place. But in those cases,
we don't even care about it. It's not my problem. I only need to care
about those calling it with a size that might be zero.
Some people were irrationally claiming that my proposal would result in
double-free and use-after-free bugs, so I had to take every possible
code people could write around realloc(3) and consider what would
happen if we changed the behavior.
And also, remember that FreeBSD wrote this:
$ grepc -htfd reallocf .
void *
reallocf(void *ptr, size_t size)
{
void *nptr;
nptr = realloc(ptr, size);
/*
* When the System V compatibility option (malloc "V" flag) is
* in effect, realloc(ptr, 0) frees the memory and returns NULL.
* So, to avoid double free, call free() only when size != 0.
* realloc(ptr, 0) can't fail when ptr != NULL.
*/
if (!nptr && ptr && size != 0)
free(ptr);
return (nptr);
}
It doesn't check errno, but it does try to recover post-morten from a
terrible situation. Indeed, it should have checked errno to prevent the
leak. Or it could have done realloc(p,n?:1) and call it a day.
[...]
> > Failing to check for ENOMEM in these platforms before freeing
> > the old pointer would result in a double-free. If the program
> > decides to continue using the old pointer instead of freeing it,
> > it would result in a use-after-free.
> >
> > In the platforms where realloc(p,0) returns non-null, such as
> > the BSDs or musl libc, it is simpler to handle it:
> >
> > new = realloc(old, size);
> > if (new == NULL) { // errno is ENOMEM
> > free(old);
> > goto fail;
> > }
> > ...
> > free(new);
> >
> > Whenever the result is a null pointer, these platforms are
> > reporting an ENOMEM error, and thus it is superfluous to check
> > errno there.
> >
> > Most code is written in this way, even if run on platforms
> > returning a null pointer. This is because most programmers are
> > just unaware of this problem. Part of the reason is also that
> > returning a non-null pointer with zero bytes is the natural
> > extension of the behavior, which is what programmers intuitively
> > expect from libc; that is, if realloc(p,3) allocates 3 bytes,
> > r(p,2) allocates two bytes, and r(p,1) allocates one byte, it is
> > natural by induction to expect that r(p,0) will allocate zero
> > bytes. Most algorithms naturally extend to 0 just fine, and
> > special casing 0 is artificial.
> >
> > If the realloc(3) specification were changed to require that
> > realloc(p,0) returns non-null on success, and that realloc(p,0)
> > only fails when out-of-memory (and assuming the implementations
> > will continue setting errno to ENOMEM), then code written for
> > AIX or glibc would continue working just fine, since the errno
> > check would be redundant with the null check. Simply, the
> > conditional (errno == ENOMEM) would always be true when
> > (new == NULL).
> >
> > Then, there are non-POSIX platforms that don't set ENOMEM. In
> > those platforms, code might do this:
> >
> > new = realloc(old, size);
> > if (new == NULL) {
> > if (size != 0)
> > free(old);
> > goto fail;
> > }
> > ...
> > free(new);
> >
> > That code would continue working with this proposal, except for
> > a very rare corner case, in which it would leak. In the normal
> > case, (size != 0) would never be true under (new == NULL),
>
> This is backwards.
> s/never // ?
Nope. It is correct. Maybe I should append to the sentence to clarify:
In the normal case, (size != 0) would never be true under
(new == NULL) after this proposed change.
> > because a reallocation of 0 bytes would almost always succeed,
> > and thus not return a null pointer under this proposal.
> > However, in some cases, the system might not find space even for
> > the small metadata needed for a 0-byte allocation. In such
> > case, the (size != 0) conditional would prevent deallocating
> > 'old', and thus cause a memory leak. This case is exceptional
> > enough that it shouldn't stop us from fixing realloc(3).
> > Anyway, on an out-of-memory case, the program is likely to
> > terminate rather soon, so the issue is even less likely to have
> > an impact on any existing programs. Also, LLVM's address
> > sanitizer will soon able to catch such a leak:
> > <https://github.com/llvm/llvm-project/issues/113065>
> >
> > This proposal makes handling of realloc(3) as straightforward as
> > one would expect, with only two states: success or error. There
> > are no in-between states.
> >
> > The resulting wording in the standard is also much simpler, as
> > it doesn't need to define so many special cases.
> >
> > For consistency, all the other allocation functions are updated
> > to both return a null pointer on error, and use consistent
> > wording.
> >
> > Why not go the other way around?
> > Some people keep asking why not go the other way around: why not
> > force the BSDs and musl to return a null pointer if size is 0.
> > This would result in double-free and use-after-free bugs, which
> > can result in RCE vulnerabilities (remote code execution), which
> > is clearly unacceptable.
> >
> > Consider this code, which is the usual code for calling
> > realloc(3) in such systems:
> >
> > new = realloc(old, size);
> > if (new == NULL) {
> > free(old);
> > goto fail;
> > }
> > ...
> > free(new);
> >
> > If realoc(p,0) would return a null pointer and free the old
>
> s/realoc/realloc/
Thanks!
> > block, then the third line would be a double-free bug.
> >
> > Prior art
> > gnulib
> > gnulib provides the realloc-posix module, which aims to wrap the
> > system realloc(3) and reallocarray(3) functions so that they
> > behave in a POSIX-complying manner.
> >
> > It previously behaved like glibc. After I reported that it was
> > non-conforming to POSIX, we discussed the best way forward,
> > which we agreed was the same direction that this paper is
> > proposing now for C2y. The implementation was changed in
> >
> > gnulib.git d884e6fc4a60 (2024-11-04; "realloc-posix: realloc (..., 0) now returns nonnull")
> >
> > There have been no regression reports since then, as we
> > expected.
> >
> > Unix V7, BSD
>
> s/Unix V7/Seventh Edition Unix/
Thanks!
> > The proposed behavior is the one endorsed by Doug McIlroy, the
> > author of the original implementation of realloc(3) in Unix V7,
> > and also present in the BSDs.
> >
> > glibc <= 2.1
> > glibc was implemented originally to return non-null. It was
> > only in 1999, and purely to comply with the standards --with no
> > requests by users to do so--, that the glibc maintainers decided
> > to switch to the current behavior.
> >
> > Design decisions
> > This change needs two changes, which can be applied all at once,
> > or in separate steps.
> >
> > The first step would make realloc(p,s) be consistent with
> > free(p) and malloc(s), including when p is a null pointer, when
> > s is zero, and also when both corner cases happen at the same
> > time. This change would already turn the implementations where
> > malloc(0) returns non-null into the end goal we have. This
> > would require changes to (at least) the following
> > implementations: glibc, Bionic, Windows.
> >
> > The second step would be to require that malloc(0) returns a
> > non-null pointer. This would require changes to (at least) the
> > following implementations: AIX.
>
> I appreciate that you no longer claim that these are the ONLY
> implementations that would require changes.
As far as libc is concerned, and especially for the first change, I'm
quite sure those are the only three. I'm purposefully not considering
interposed implementations, though; only libc. But yeah, this is
probably easier to state without wording mistakes.
> >
> > This proposal has merged all steps into a single proposal.
> >
> > Future directions
> > This proposal, by specifying realloc(3) as-if by calling
> > free(3) and malloc(3), makes redundant several mentions of
> > realloc(3) next to either free(3) or malloc(3) in the standard.
> > We could remove them in this proposal, or clean up that in a
> > separate (mostly editorial) proposal. Let's keep it for a
> > future proposal for now.
> >
> > Caveats
> > n?n:1
> > Code written today should be careful, in case it can run on
> > older systems that are not fixed to comply with this stricter
> > specification. Thus, code written today should call realloc(3)
> > similar to this:
> >
> > realloc(p, n?n:1);
> >
> > When all existing implementations are fixed to comply with this
> > stricter specification, that workaround can be removed.
> >
> > ENOMEM
> > Existing implementations that set errno to ENOMEM must continue
> > doing so when the input pointer is not freed. If they didn't,
> > code that is currently portable to all POSIX systems
> >
> > errno = 0;
> > new = realloc(old, size);
> > if (new == NULL) {
> > if (errno == ENOMEM)
> > free(old);
> > goto fail;
> > }
> > ...
> > free(new);
> >
> > would leak on error.
> >
> > Since it is currently impossible to write code today that is
> > portable to arbitrary C17 systems, this is not an issue in
> > ISO C.
>
> Current code that calls realloc in a manner that is portable to
> arbitrary C17 or C23 systems will already ensure that the size
> argument is non-zero (for example, using the n?n:1 method above).
> Such code is very possible and requires no changes.
Again, I'm only concerned about code that calls realloc(p,n) where n
might be zero. If it can't be zero, it's not my problem. It is not
possible to call realloc(p,0) in a manner that is portable to C17
without leaking (or worse, DF or UAF).
As you've seen above, FreeBSD does this. At least, they are only
concerned about POSIX, so they could have written it without a leak.
However, they wrote it in the C17-portable manner, which resulted in
a leak. Why? Because both standards have been confusing people about
realloc(3) for a long time.
> > - New code written for C2y will only need to check for
> > NULL to detect errors.
> >
> > - Code written for specific C17 and older platforms
> > that don't set errno will continue to work for those
> > specific platforms.
> >
> > - Code written for POSIX.1-2024 and older platforms
> > will continue working on POSIX C2y platforms,
> > assuming that POSIX will continue mandating ENOMEM.
> >
> > - Code written for POSIX.1-2024 and older will not be
> > able to be run on non-POSIX C2y platforms, but that
> > could be expected.
>
> I don't see how this is relevant to this proposal.
I want to be comprehensive. The C Committee is also concerned about
POSIX, since they have attepted to coordinated changes to realloc(3) in
the past, even if it didn't work well. In fact, this time it better is
well coordinated, or we rather not do it at all.
> > The only important thing is that platforms that did set ENOMEM
> > should continue setting it, to avoid introducing leaks.
> >
> > Proposed wording
> > Based on N3550.
> >
> > 7.25.4.1 Memory management functions :: General
> > @@ p1
> > ...
> > If the size of the space requested is zero,
> > -the behavior is implementation-defined:
> > -either
> > -a null pointer is returned to indicate the error,
> > -or
> > the behavior is as if the size were some nonzero value,
> > except that the returned pointer shall not be used
> > to access an object.
> >
> > 7.25.4.2 The aligned_alloc function
> > @@ Returns, p3
> > The <b>aligned_alloc</b> function returns
> > -either
> > -a null pointer
> > -or
> > -a pointer to the allocated space.
> > +a pointer to the allocated space
> > +on success.
> > +If
> > +the space cannot be allocated,
> > +a null pointer is returned.
> >
> > 7.25.4.3 The calloc function
> > @@ Returns, p3
> > The <b>calloc</b> function returns
> > -either
> > a pointer to the allocated space
> > +on success.
> > -or a null pointer
> > -if
> > +If
> > the space cannot be allocated
> > or if the product <tt>nmemb * size</tt>
> > -would wraparound <b>size_t</b>.
> > +would wraparound <b>size_t</b>,
> > +a null pointer is returned.
> >
> > 7.25.4.7 The malloc function
> > @@ Returns, p3
> > The <b>malloc</b> function returns
> > -either
> > -a null pointer
> > -or
> > -a pointer to the allocated space.
> > +a pointer to the allocated space
> > +on success.
> > +If
> > +the space cannot be allocated,
> > +a null pointer is returned.
> >
> > 7.25.4.8 The realloc function
> > @@ Description, p2
> > The <b>realloc</b> function
> > deallocates the old object pointed to by <tt>ptr</tt>
> > +as if by a call to <b>free</b>,
> > and returns a pointer to a new object
> > -that has the size specified by <tt>size</tt>.
> > +that has the size specified by <tt>size</tt>
> > +as if by a call to <b>malloc</b>.
> > The contents of the new object
> > shall be the same as that of the old object prior to deallocation,
> > up to the lesser of the new and old sizes.
> > Any bytes in the new object
> > beyond the size of the old object
> > have unspecified values.
> >
> > @@ p3
> > If <tt>ptr</tt> is a null pointer,
> > the <b>realloc</b> function behaves
> > like the <b>malloc</b> function for the specified size.
> > Otherwise,
> > if <tt>ptr</tt> does not match a pointer
> > earlier returned by a memory management function,
> > or
> > if the space has been deallocated
> > by a call to the <b>free</b> or <b>realloc</b> function,
> > ## We can probably remove all of the above, because of the
> > ## behavior now being defined as-if by calls to malloc(3) and
> > ## free(3). But let's do that editorially in a separate change.
> > -or
> > -if the size is zero,
> > ## We're defining the behavior.
> > the behavior is undefined.
> > If
> > -memory for the new object is not allocated,
> > +the space cannot be allocated,
> > ## Editorial; for consistency with the wording of the other functions.
> > the old object is not deallocated
> > and its value is unchanged.
> > +XXX)
> >
> > @@ New footnote XXX
> > +XXX)
> > +While atypical,
> > +<b>realloc</b> may fail
> > +or return a different pointer
> > +for a call that shrinks the block of memory.
> >
> > @@ Returns, p4
> > The <b>realloc</b> function returns
> > a pointer to the new object
> > (which can have the same value
> > -as a pointer to the old object),
> > +as a pointer to the old object)
> > +on success.
> > -or
> > +If
> > +space cannot be allocated,
> > a null pointer
> > -if the new object has not been allocated.
> > +is returned.
> >
>
> The actual changes seem quite reasonable, for those that make it this far.
Thanks!
Have a lovely day!
Alex
--
<https://www.alejandro-colomar.es/>
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
