Skip to content

fix and expand what we say about ZST #163

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Sep 14, 2019
Merged

fix and expand what we say about ZST #163

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 7 additions & 2 deletions src/exotic-sizes.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -111,10 +111,15 @@ support values.

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.
Copy link
Contributor

@Centril Centril Sep 14, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you say a bit about why the bit about "indistinguishable from the OOM result" is being nixed?

Copy link
Member Author

@RalfJung RalfJung Sep 14, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@Gankra Gankra Oct 4, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

@RalfJung RalfJung Oct 9, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Cc @pnkfelix @sfackler @alexcrichton @gnzlbg

Copy link
Contributor

@gnzlbg gnzlbg Oct 10, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

and allocators typically [require a non-zero size][alloc].

Note that references to ZSTs (including empty slices), just like all other
references, must be non-null and suitably aligned. Dereferencing a null or
unaligned pointer to a ZST is [undefined behavior][ub], just like for any other
type.

[alloc]: https://doc.rust-lang.org/std/alloc/trait.GlobalAlloc.html#tymethod.alloc
[ub]: what-unsafe-does.html



Expand Down