> Noncompliant, since `malloc(0)` is specified to return a unique pointer if it's not `NULL`.

I know I've seen that somewhere, but may I ask what standard you're referring to?

Pointers are frequently used as keys for map-like data structures. This introduces collisions that the programmer can't check for, whereas NULL is very often special-cased.

C89: https://port70.net/%7Ensz/c/c89/c89-draft.html

If the size of the space requested is zero, the behavior is implementation-defined; the value returned shall be either a null pointer or a unique pointer.

Presumably the ANSI C standard or one of the later editions? They also cover the standard library as well as the language. (Presumably the bit about "Each such allocation shall yield a pointer to an object disjoint from any other object." if the random C99 draft I found via google is accurate to the final standard - I suppose you might question if this special use is technically an allocation of course).

Of course, microcontrollers and the like can have somewhat eccentric implementations of languages of thing and perhaps aren't strictly compliant, and frankly even standard compliant stuff like "int can be 16 bits" might surprise some code that doesn't expect it.

(you duped your comment under the other subthread)

From C89, §7.10.3 "Memory management functions":

> If the size of the space requested is > zero, the behavior is implementation-defined; the value returned shall be either a null pointer or a > unique pointer.

The wording is different for C99 and POSIX, but I went back as far as possible (despite the poor source material; unlike later standards C89 is only accessible in scans and bad OCR, and also has catastrophic numbering differences). K&R C specifies nothing (it's often quite useless; people didn't actually write against K&R C but against the common subset of extensions of platforms they cared about), but its example implementation adds a block header without checking for 0 so it ends up doing the "unique non-NULL pointer" thing.

> At the end of main, if the count wasn't balanced, then you knew you had a mismatch between malloc()/free().

A mismatch between malloc(0) and free(-1).

You’d know nothing about calls to malloc with non-zero sizes.

You can copy from a zero sized pointer with memcpy, but not NULL.

> allocating a few bytes that weren't asked for.

FWIW the alignment guarantees of `malloc()` mean it often will have to allocate more than you ask for (before C23 anyway). You can't 'legally' use this space, but `malloc()` also can't repurpose it for other allocations because it's not suitably aligned.

That said I still agree it's a hack compared to just using `malloc(1)` for this purpose, it's well-defined and functionally equivalent if you're looking for a unique address. The fact that you don't know what `malloc(0)` is going to do makes it pretty useless anyway.

The only requirement which seems reasonable to me, is that the address be unique. Since the allocation size is zero, it should never be accessed for read or write, but the address itself may need to be used for comparisons.

If you’re pointing to a zero sized data it shouldn’t matter what it’s pointing to. Even outside valid address space. Because you shouldn’t be reading or writing more than 0 bytes anyway.

> or allocating a few bytes that weren't asked for.

You are always allocating bytes you weren't asked for: the allocation metadata and some extra bytes to satisfy the alignment requirement. If you absolutely don't want to allocate memory, you probably shouldn't have called malloc() in the first place :)