realloc() and the oversize importance of zero-size objects

It might be a solution to return (void *) -1 for allocations of size 0. Free and realloc would be flagged by this that it's no real object but a 0 allocation and could act accordingly.

Option 2 (free the object and return NULL) predates the C99 standard by quite a lot. The glibc implementation might not ...

I remember reading my Microsoft C v5.1 (from 1991-ish?) where it says realloc with a size of 0 frees the memory and returns NULL.

Imho this is a very good way of assuring safety - if you do not use free, but instead always do "ptr = realloc( ptr, 0)", you will never (absent multiple copies of a pointer) have dangling pointers lying around.

Cheers,
Wol

I always considered behaviour 2 to be kind of beautiful, since that allows you to define a heap allocator using just a single call:
malloc(n) is just realloc(NULL,n) and free(p) is just realloc(p,0).

But let's say that you want behaviour 1, couldn't realloc(p, 0) just return a singleton pointer that points to at least one readable and writable word? free could check for this singleton and do nothing. There would be no memory leaks (but a tiny performance penalty).

If I remember correctly there are architectures where loading a NULL pointer into some register is illegal, even if the memory isn't accessed.

The article states: "the C23 standard explicitly defines calling either malloc() or realloc() with a size of zero as undefined behavior."

I thought it was just realloc with size zero that is now undefined behaviour.
At least the last public draft I can find only mentions something about size being zero for realloc, but not for malloc.
https://open-std.org/JTC1/SC22/WG14/www/docs/n3301.pdf
But it isn't very consistent.

7.24.4.1 talks generically about malloc, realloc, aligned_alloc and calloc saying "If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned to indicate an 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.24.4.7 talks about malloc and doesn't mention size zero at all, just saying "The malloc function allocates space for an object whose size is specified by size and whose representation is indeterminate. The malloc function returns either a null pointer or a pointer to the allocated space".

7.24.4.8 talks about realloc and says "If ptr is a null pointer, the realloc function behaves like the malloc function for the specified size. Otherwise, if ptr does not match a pointer earlier returned by a memory management function, or if the space has been deallocated by a call to the free or realloc function, or if the size is zero, the behavior is undefined."

Which seems to me to imply only realloc (p, 0) is undefined behaviour unless p is NULL, then it behaves like malloc(0). But it isn't specified what malloc(0) means.

> Siddhesh Poyarekar pointed out, though, that a zero-byte object still requires the equivalent of two size_t values for tracking, so real memory would be leaked

A special allocator could be used for zero-sized blocks, especially on 64-bit systems where you should be able to make due with 1/128th as much storage as "two size_t values":

You'd set aside a big swath of addresses for all your zero-sized blocks (never mapped) and then track which ones are allocated with a single bit per allocation.

I don't understand why a size of zero should be a special case. Realloc can enlarge or shrink the allocated block, and you can call realloc with a pointer returned by realloc. The size of the (re)allocated block is in most cases the result of a computation. If a size of zero has a different meaning, then you have add a check for it in the caller and handle it differently.

>His opinion, expressed in unambiguous terms, was that realloc() should behave in the same way as malloc() when passed a size of zero; it should, in other words, free the passed-in object and return a pointer to a zero-byte object.

In my opinion, realloc(ptr, 0) should logically behave in the same way as realloc(ptr, 1), except that in the second case there is a single byte left instead of zero bytes.

If malloc can take a size argument of zero, returning an object with a zero sized block that can be realloc'd, why do we have the asymmetry that a realloc(ptr, 0) can't return a zero sized block (that could be realloc'd back to some larger size)?

Using realloc(ptr, 0) as a substitute for free is an ugly hack. We already have the free function.

Option 1 makes sense, in that there needs to be something that defines not only the allocation but any other attributes that might be associated with it. There might be several such metadata structures in some operating systems.

If realloc can only change, but not create or destroy, the metadata, then you've a performance gain. You can have a pool of, say, buffers that get realloced to zero then realloced to the necessary size when needed. You'd expect this to be faster (less work), but also more predictable (since all memory that's free can be allocated, rather than all minus the space needed for housekeeping).

I can imagine that'd be good for HPC and embedded, but you'd also expect such software to use replacement mallocs more suited to such work.

Option 2 makes sense too, because a valid result from malloc and realloc should be usable. It's one thing if there's an error, but if it's successful, the pointer you have should work. You can't validate the case where an operation returns a pointer but the pointer is unusable and there's no exception handling in C.

However, that would break the semantics for malloc, which is a Bad Thing, but if you want to improve memory safety then you've got to have safe behaviour.

Which leads to Option 3, where you return an error saying the operation doesn't make sense.

There's an alternative approach: remove memory allocation from glibc and put it in a library glibc links to.

Don't bother with conventional tunables, since you don't want degraded performance and more opportunities for bugs, simply have a bank of malloc implementations, where glibc's malloc is the default.

People are going to replace the memory allocator if they want different semantics anyway. Moving malloc outside reduces overhead if they're going to do that and there's no new code so no room for new defects.

Precisely because the memory allocator can be replaced already, even dynamically rather than at compile time, there's only limited scope for arguing the behaviour should be decided at compile time. That isn't, after all, how it's done at present.

If you drop the requirement that malloc(0) return a *unique* zero-sized pointer, then you no longer need to *track* the pointer you return. Return (void *)1 or (void *)-1 or a similar never-valid non-NULL pointer, and have free of that pointer successfully do nothing. realloc to size 0 can similarly return that pointer, so things expecting a non-NULL return are satisfied, and things expecting to free memory that way are *also* satisfied.

Years ago, when implementing Lua support in haproxy, we found that their allocator matched exactly our understanding of realloc() based on the man page on Linux (i.e. option 2).

Then some time later, some users noticed memory leaks on Alpine (using musl not glibc). It's when we
discovered that POSIX doesn't mandate to completely free the area. So we had to put an explicit check
and forcefully free when the size is zero, otherwise call realloc(), and put a big fat warning on top if it.
It suddenly became much less elegant but now it works.

The conclusion of this is that changing this behavior *WILL* break existing applications that were never
tested outside glibc. However, having a tunable to test for that for portability purposes would be great.
And maybe 20 years from now the default setting of the tunable could change.

Another feature which would be great would be to easily access a counter of zero-sized objects so that
applications can be instrumented to detect their use of this malloc() feature of unique return pointers,
because it might come with lib dependencies and is hard to detect (due to the slow leak). Even a tunable
causing an abort on zero-sized objects would help locate the rare call points.

> Hanging over this whole discussion is another important detail: the C23 standard explicitly defines calling either malloc() or realloc() with a size of zero as undefined behavior. That is a change from C17, which called it implementation defined. Colomar had mentioned that change in his initial message, but dismissed it, saying "let's ignore that mistake". The glibc project cannot entirely ignore the standards it implements, though.

Perhaps I misunderstood, but to me "... cannot entirely ignore the standards ... " seems to imply that code with "undefined behaviour" must crash and burn in the most random and confusing way possible. That's not so. An implementation is free to define a meaning to some code that is undefined according to the standard – that is still standard compliant since, by definition, the standard does not define what that code should do.

I think the real problem here is that "1. Behave like malloc() and return a pointer to a zero-byte object" has three possible results: it can succeed, returning the same non-null pointer it was originally given (let's call that result 1a); or it can succeed, returning a non-null pointer that is different from the one it was originally given (1b); or it can fail, returning NULL and setting errno to ENOMEM (1c). You might reasonably assume that allocating 0 bytes of memory can't fail, but if the result is required to be a unique pointer - as it is in glibc documentation - then allocating some space for bookkeeping overhead will still be required, and *that* might result in running out of memory.

If it succeeds, a caller can distinguish that from behaviours 2. and 3., because the result is non-null. It can compare the result with the previous pointer to decide whether it's in situation 1a or 1b.

But if it fails, a caller cannot distinguish between 1c, 2 and 3. This is a problem because they have differing side-effects! In situations 1c and 3, errno has been set, and the original pointer is untouched (the caller is still responsible for freeing it later). In situation 2, the value of errno is undefined (so errno cannot be used to distinguish between this and situations 1c and 3), and the original pointer has been freed (the caller must not free it again, that would be UB).

Please do not fix existing problems by changing long established API. This only breaks existing code. Treat it like the kernel does, do not break userspace. Instead, define a new sane API and provide it as an alternative.

Personally, I like two varities:

1) never return a bad value, AKA is do it or die, AKA die early because I can't do anything anyway. OK to scream OUCH!!! if out of memory. Really, if you are out of memory then you are screwed anyway. If you thought you were allocating something other than 0 bytes, it is best to know as soon as possible.

2) return NULL and set errno=EINVAL on size==0. Users problem, not systems. I can keep going or do controlled shutdown as the case may be.

> This is, it seems, a topic about which some people, at least, have strong feelings.

50+ comments here already!

> there are almost certainly programs that rely on the current behavior

Apparently just non-portable programs that have a hard dependency on glibc, so such breakage would be fine because users:
1. either use a stable / LTS GNU/Linux distribution that is not going to perform a major glibc upgrade (this change should obviously not be part of a minor release, only in a major one)
2. or they use a rolling / fast-paced / development one where everything keeps breaking anyway for a gazillion of other reasons.

To be fairer: _how_ it would break in case 2. matters. Discussed above already.

To me this is kind of irrelevant. If you want to write portable code then you have to cope with the fact that malloc(0) and realloc(ptr, 0) don't react the same on all platforms - and just avoid them altogether. To me any C code relying on these kind of specific behaviors (be that of glibc or any other platform) has a strong smell.

Even if the code is used in non-portable programs that are designed for just a single operating system, I still don't like them. There are some implementation-defined behaviors (such as relying on two's complement or 8bit byte sizes) where it can make a lot of sense to rely on those, because not assuming that would make the code a **lot** more complicated for no benefit at all in many cases. (And platforms that that don't use e.g. two's complement are extremely rare nowadays.) But avoiding malloc(0) or realloc(ptr, 0) is just 1-2 more lines of code. And if it's handled explicitly it is 100% clear what the code intends to do. In the absence of explicit handling that's not the case, and then one doesn't immediately know whether the code actually relies on that behavior, or whether there's a bug in there and the author didn't even think about that corner case.

I personally would leave the current behavior as-is, because I don't see any benefit of changing it, because in my opinion nobody should ever write new code that relies on these kinds of specifics. But I also don't really care if they do decide to change that behavior.

realloc(ptr, 0) is related to malloc(0). Experienced app implementors might realize that some uses of malloc(0) are equivalent to (GENSYM) in Lisp: create a new atom that is unique for the remaining duration of the process.

In C language, a tentatve definition such as one of:
void *GENSYSM(void) { return malloc(0); }
void *GENSYSM(void) { return malloc(1); }
void *GENSYSM(void) { return malloc(sizeof(void *)); }
allows taking advantage of simpler management than general malloc(). Allocate sequentially from larger block(s) at known address(es) (such as a page on 16-bit, aligned megabyte on 32-bit, aligned 4GiB on 64-bit), use a bitmap to track, etc. Interposing such a definition, intercepting malloc(0), can be useful in an existing system. Being able to distinguish (by address) a GENSYSM from a general malloc block can have advantages in debugging, user interface, or even logical flow.

In an environment that has inter-operable GENESYM and malloc, then realloc(ptr, 0) can be easy to understand and implement: { free(ptr); return GENSYM(); }

I don't get it. If an API was misused before, I'd rather disallow what could be misinterpreted and ask to use another API.

IMHO the only sane way forward would be to narrow the API of realloc, rejecting zero-size objects.
So realloc(something, 0) should just set errno to EINVAL and return a NULL pointer. This may crash some applications, but that's easier to fix than invoking undefined behavior, making the code "run on my machine".

Full disclosure: I used realloc to resize string buffers, and was expecting for realloc(something, 0) being equivalent to free. Obviously I did not check for errors in that code, so calling realloc to increase the size failing would lead to a memory leak (and probably write to zero address).