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'm somewhat responsible for this being UB, so I feel compelled to defend it (my preferred outcome was "implementation-defined", not that that's much better). In our defense: the reality on the ground was that you can't write a portable program that does realloc(p, 0) and (1/3)

Replying to

gets a sane result, regardless of what the standard says or could have said. So the committee chose to acknowledge that fact. Making this "anything goes" lets each implementation maintain its current behavior, and also allows new ones (e.g. the next jemalloc release will (2/3)

Replying to

allow free/malloc(0)/abort semantics, set per-process). The switch from free to malloc(0) was out of a desire to mitigate the security footgun of the free semantics, I believe (though that was before my time). (3/3)

Replying to

BTW. What worries me more about jemalloc is that with MADV_FREE on Linux allocated memory is not stable. It is sometimes claimed (but IMHO not true) that this is allowed by the standard.

Replying to

> The malloc function allocates space for an object whose size is specified by size and whose value is indeterminate. > indeterminate value > either an unspecified value or a trap representation

6:16 AM · Jun 20, 2021Twitter Web App

Replying to

> trap representation > an object representation that need not represent a value of the object type There's not really an object representation yet until you actually put something into the memory. I don't think other stuff it says about trap representations elsewhere applies.