Stream: t-lang/wg-unsafe-code-guidelines

Topic: question comex


gnzlbg (Apr 12 2019 at 11:38, on Zulip):

@comex i think you might be mixing things up

gnzlbg (Apr 12 2019 at 11:39, on Zulip):

the point about array length has nothing to do with the rest of your comment

gnzlbg (Apr 12 2019 at 11:40, on Zulip):

Rust already supports allocations that are larger than isize::MAX, e.g., on a 32-bit system you can allocate isize::MAX as usize / 4 * 3 bytes of memory using the global allocator, and construct a slice from_raw_parts that points to that region of allocated memory

gnzlbg (Apr 12 2019 at 11:41, on Zulip):

That works fine

gnzlbg (Apr 12 2019 at 11:42, on Zulip):

The only thing that can trigger UB in anything you mention is using ptr.add or ptr.offset such that a new pointer is computed that's more than isize::MAX bytes away from the source

gnzlbg (Apr 12 2019 at 11:43, on Zulip):

that can happen only for some combinations of (T, offset)

gnzlbg (Apr 12 2019 at 11:43, on Zulip):

e.g. [(); usize::MAX] works just fine, and using ptr.offset/add with usize::MAX/isize::MAX works just fine too

gnzlbg (Apr 12 2019 at 11:45, on Zulip):

IIUC, you question is that code that assumes that a slice can only point to allocations with less than isize::MAX bytes might have undefined behavior on a different implementation, and its therefore not portable.

gnzlbg (Apr 12 2019 at 11:45, on Zulip):

But that code is not portable today, in Rust, because that can already happen (e.g. the 32-bit example above)

gnzlbg (Apr 12 2019 at 11:46, on Zulip):

Or maybe your question was that code assumes that slice.len is always smaller than isize::MAX, but that also does not hold in Rust today

rkruppe (Apr 12 2019 at 11:47, on Zulip):

Rust already supports allocations that are larger than isize::MAX, e.g., on a 32-bit system you can allocate isize::MAX as usize / 4 * 3 bytes of memory using the global allocator, and construct a slice from_raw_parts that points to that region of allocated memory

While it's true that ZSTs enables arrays/slides/etc. with length larger than isize::MAX that don't correspond to an allocation larger than isize::MAX, for allocations that are larger than isize::MAX we have no support story and essentially 0% of Rust code supports such large allocations. Your particular example here (slice::from_raw_parts) is wrong: that function explicitly states that calling it for slices larger than isize::MAX bytes is UB, and it has to, because slicing and indexing uses offset internally.

gnzlbg (Apr 12 2019 at 11:49, on Zulip):

@rkruppe indeed, that's required for safe indexing

gnzlbg (Apr 12 2019 at 11:50, on Zulip):

the question is then whether users can rely on that being the case

gnzlbg (Apr 12 2019 at 11:50, on Zulip):

that's a pre-condition on slice::from_raw_parts, but does the slice type guarantee users that it holds ?
AFAICT a new Rust version could remove the pre-condition in a backwards compatible way

rkruppe (Apr 12 2019 at 11:51, on Zulip):

Yes, that's an interesting question, but let's not get the background knowledge wrong while discussing it :p

gnzlbg (Apr 12 2019 at 11:52, on Zulip):

so what's the answer to @comex question ?

rkruppe (Apr 12 2019 at 11:52, on Zulip):

I do not think we have any precedent that would allow us to answer definitely, so I gesture at the "own-rfc-worthy" label that's already on that issue

gnzlbg (Apr 12 2019 at 11:53, on Zulip):

I think the text they quote does imply what they think it implies

gnzlbg (Apr 12 2019 at 11:54, on Zulip):

They claim the text implies that a Rust implementation could support slices larger than isize::MAX

gnzlbg (Apr 12 2019 at 11:54, on Zulip):

And AFAICT, that's the case, that could happen

gnzlbg (Apr 12 2019 at 11:54, on Zulip):

guaranteeing that it cannot happen would require an RFC

gnzlbg (Apr 12 2019 at 11:55, on Zulip):

that does not have much to do with their question about the portability distiction between ptr.add and ptr.offset

gnzlbg (Apr 12 2019 at 11:58, on Zulip):

ah, yes it does, from a portability pov to such implementations, their implementation usingptr.add works, while the one using ptr.offset is broken.

rkruppe (Apr 12 2019 at 11:58, on Zulip):

tbqh it seems we're all in agreement about what we want to document and comex's concern is just that this isn't expressed right/clearly enough in the current UCG? no need to language-lawyer about wording that we can just go and make less in need of lawyering

gnzlbg (Apr 12 2019 at 11:59, on Zulip):

i think @comex concern is that we should deprecate ptr.offset, which is IMO the right thing to do if we want to allow future Rust implementations to support slice larger than isize::MAX

rkruppe (Apr 12 2019 at 12:00, on Zulip):

We should only do that deprecation if we actively decide that is a future we want. But that is way outside the scope of the current discussion.

rkruppe (Apr 12 2019 at 12:01, on Zulip):

Right now we just don't decide either way about that, so we have no basis to deprecate, it's just another action item to attach to when we eventually address that question.

rkruppe (Apr 12 2019 at 12:02, on Zulip):

So to be clear, I think the question "is <example using add> portable and <example using offset> nonportable" is currently answered not by yes or no, but "pending further decisions". which you can read as "no" if you want to be careful with the code you write, but it's no basis for going and deprecating stuff

gnzlbg (Apr 12 2019 at 12:07, on Zulip):

@rkruppe agree - in many other issues, we leave stuff out because we actively want to support some use cases, but that's not the case here. Here, we leave the limits out because going either way (supporting slices larger than isize::MAX or fixing the maximum slice size) would require an RFC. This is just an unspecified part of the language.

gnzlbg (Apr 12 2019 at 12:09, on Zulip):

Maybe we should just use unspecified instead of implementation-defined. Implementation-defined sounds like we encourage every implementation to do whatever they want.

gnzlbg (Apr 12 2019 at 12:10, on Zulip):

Leaving this as implementation-defined would also require an RFC.

rkruppe (Apr 12 2019 at 12:20, on Zulip):

yeah

Last update: Nov 19 2019 at 18:05UTC