Conversation

Replying to

this is funny but the actual situation is also funny: all real C and C++ applications are written in a non-standardized, undocumented programming language that closely resembles standard C and C++ but has less undefined behavior

139

Replying to

and

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.

Replying to

and

do you have a list of examples? I think this is rarer! or I hope so

Replying to

and

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.

Replying to

and

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.

Replying to

and

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...

Replying to

and

I thought it was defined to free p!

Replying to

and

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.

Replying to

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.

Replying to

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.

Replying to

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.

5:22 AM · Jun 20, 2021Twitter Web App

Replying to

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.