fix and expand what we say about ZST#163
Conversation
|
r? @Centril |
Centril
left a comment
Centril
left a comment
There was a problem hiding this comment.
This looks good but I have one question.
| Safe code need not worry about ZSTs, but *unsafe* code must be careful about the | ||
| consequence of types with no size. In particular, pointer offsets are no-ops, | ||
| and standard allocators may return `null` when a zero-sized allocation is | ||
| requested, which is indistinguishable from the out of memory result. |
There was a problem hiding this comment.
Can you say a bit about why the bit about "indistinguishable from the OOM result" is being nixed?
There was a problem hiding this comment.
I think it's plain wrong. OOM is well-defined and we call the OOM handler; asking the allocator for a zero-sized allocation is UB.
There was a problem hiding this comment.
clarification for historians: in C(++?) it's "only" implementation-defined to pass 0 to malloc: https://en.cppreference.com/w/c/memory/malloc
Since all the major allocators target this API, they all have this semantic. I'm guessing you're saying that the Rust interface makes a stricter claim? (which is fine by me, since the implementation-defined-ness might as well be UB in practice).
There was a problem hiding this comment.
This is my understanding of the Rust docs, yes. I do not know the motivation for why we say UB where C++ says impl-defined.
There was a problem hiding this comment.
C and C++ don't support ZSTs so the behavior of malloc(0) isn't really relevant there as long as nothing breaks if that ever happens, which doesn't happen often in C, and probably almost never in C++ (new T[0] doesn't call malloc(0) since the array needs a unique address and has non-zero size even though it has zero elements..).
In Rust, code that deals with ZSTs often ends up doing completely different things for the zero-sized and non-zero-sized cases. For the zero-sized case the answer is almost never malloc(0) because of, e.g., alignment requirements.
So the reason GlobalAlloc does not support zero-size allocations is probably that there just weren't any compelling use cases for doing so; I can't at least think of any.
4 participants
No description provided.