It's mostly that, but it happens the other way around to some extent too.
Compilers sometimes decide they should be able to do something and the standard is overly permissive. Then, eventually, maybe the standard gets aligned to what compilers actually felt like doing.
Conversation
do you have a list of examples? I think this is rarer! or I hope so
3
I have some examples. I'd need to think about it to actually list some of them out.
Happens with the standard library pretty commonly too, even with the most basic APIs like malloc/realloc/free.
It's often the kind of stuff they deal with via defect reports.
1
4
The malloc stuff is what I've had to deal with myself. They've gone back and forth about whether certain things are allowed and how they're defined, like realloc with size 0, aligned_alloc with an alignment that's not a multiple of the size and several other things for those.
1
4
Does realloc(p, 0) do the equivalent of malloc(0) and then frees p if successful? Does it simply free p? Is it undefined? Who even knows anymore, because they changed it too many times (literally at least 3 times) and while I think it's undefined now it's very commonly used...
3
3
That's what glibc does but it's in violation of POSIX and also the C standard before they basically gave up and said you shouldn't do it anymore. The proper way to handle it is matching malloc(0) rather than making a realloc-specific special case that's actively dangerous.
1
2
The various *BSD malloc implementation match malloc(0) so that's what Android does and therefore is what LLVM ended up doing IIRC.
glibc has the weird special case of realloc(p, 0) meaning free(p) unless p is NULL and then it means malloc(0) like it would with a normal approach.
2
1
It's very common for programs to trigger this by not handling 0 size as a special case and I wouldn't be surprised if they often ended up with a double-free with glibc malloc. It's better to leak memory if something expects it to free, which is non-portable GNU behavior.
1
1
Even if your goal is glibc compatibility, the malloc implementation should really always treat it as malloc(0).
Also, even though the C standard implies you can return NULL for malloc(0), you can't really do that, and it's dangerous since stuff dereferences with large offsets.
2
Best way to handle malloc(0) is returning a unique pointer to PROT_NONE memory so that accessing it will fault, which retains compatibility and also deals with programs ending up with 0 due to screwing up a calculation. Sometimes end up with 0 in overflow situations, etc.
Is it necessary to return a different pointer each time?
1
Yes, it still has to be a pointer to an allocation with a unique address and it probably also still has to be aligned for strict compatibility / standards compliance so you actually have to waste 16 bytes of virtual memory, not that it has any real cost (not very common anyway).
1
Show replies