|
|
Subscribe / Log in / New account

Unsafety can be subtle

Unsafety can be subtle

Posted Sep 19, 2024 14:20 UTC (Thu) by khim (subscriber, #9252)
In reply to: Unsafety can be subtle by apoelstra
Parent article: A discussion of Rust safety documentation

> Though having said that, `get_unchecked` is a very old method and one of the classic "here's a case where you'd need to use unsafe" methods, so I'm skeptical that many users will carefully (or even casually) read the docs.

Note that get_unchecked is, actually, range-check-skipping version of get and it even explicitly tells you: For a safe alternative see get (with clickable link!), which actually then tells you that you may either access one element or range of elements with this method.

Your situation is a bit unusual because you have immediately decided to skip all the range-checking without testing and without verifying that these are the bottlenecks and are worth eliminating (note that if they are easy to eliminate for human then often compiler can easily eliminate them, too, after inlining, which means these checks are not, necessarily, a performance bottlenecks and often where they are performance bottlenecks they are, often, desirable because if compiler couldn't prove that they are not needed then chances are high that it's not actually guaranteed by the structure of your code, either).

That's why you have missed all these explanations (that are there for get, but not for it's range-check-skipping sibling).

That's not how slice is supposed to be used, normally! I guess documentation was just not written with people which would try to remove as many guardrails as possible as early as possible.

Are you even sure in your case use of get_unchecked actually brings measurable performance wins over the use of get?


to post comments

Unsafety can be subtle

Posted Sep 19, 2024 19:09 UTC (Thu) by apoelstra (subscriber, #75205) [Link] (1 responses)

>Your situation is a bit unusual because you have immediately decided to skip all the range-checking without testing and without verifying that these are the bottlenecks and are worth eliminating

This is an incredible inference from example code I posted to illustrate pointer provenance rules and which has never actually been deployed in the form I described.

Unsafety can be subtle

Posted Sep 19, 2024 19:35 UTC (Thu) by khim (subscriber, #9252) [Link]

> This is an incredible inference from example code I posted to illustrate pointer provenance rules and which has never actually been deployed in the form I described.

That's not not inference from the example code, but more of inference from your comments. You are using unsafe function to do some manipulations that usually are done with normal, safe, code in an unsafe way by using function that's sole purpose is to save a tiny amount of execution time by bypassing the usual safety checks. And then you add debug_assert that, essentially, restores error-checking that is normally used by Rust programs unconditionally in debug build. And then complain that function that you used to bypass normal safety checks have poor documentation – while asking for clarifications that are already present in the sibling version of that same function, that's already referred as “safe alternative” there and which is one click away. Which means that, you probably, have never read the documentation for the safe variant: how else would you not notice that this variant already addresses all you concerns?

Forgive me, but I fail to see how one would end up in that situation except if one have apriori decided for oneself that one is not interested in writing normal, safe code and would stick to the removal of Rust-provided guardrails as much as possible.

Note: I'm not even saying that's it's wrong to write code that way. Maybe, for the kernel needs, it's even the best way and you haven't forgotten to erect manual check after you removed the normal Rust-provided provided check there.

But that definitely puts you into a different usage mode: normally it's expected that Rust developer would stick to normal, “safe” interface as much as possible and would only remove guardrails where that's truly justified.

Going down that “normal” road it's almost impossible to miss detailed specification that explains what get function works, how is it supposed to be used, there are examples with a single argument and a range, etc.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds