C++ Core Guidelines
C++ Core Guidelines
Posted Apr 19, 2021 18:36 UTC (Mon) by Cyberax (✭ supporter ✭, #52523)In reply to: C++ Core Guidelines by mss
Parent article: Rust in the Linux kernel (Google security blog)
The transformation writer needs to supply the bounds. It's not possible all the time, but it is possible in a surprising number of times. Newly introduced const generics can help with that.
> That's entirely valid code if one can guarantee that it will always get a valid input value.
> I understand that making this guarantee might be hard, but it's a trade-off.
The tradeoff is just not worth it for the overwhelming majority of code. But if you are super-certain that it's OK, you can slap an "unsafe{}" block and do whatever you want.
Posted Apr 19, 2021 18:41 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
"Whatever" is not valid (because you still need to uphold Rust's invariants even in `unsafe` blocks[1]) and I feel that such characterizations mislead those who are not familiar with Rust about what it actually means. In this case, `get_unchecked` (an unsafe method on Vec and slices that can be called from within an `unsafe` block) would be what is wanted.
[1] For example, `bool` must be a 0 or 1 representation. Even unsafe cannot store the integer value of `2` into such a location viewed through a `bool` lens because there could be code that does `== 1` for truth comparison in one place and `== 0` in another which means that the `bool` is neither which is no good.
Posted Apr 20, 2021 9:17 UTC (Tue)
by farnz (subscriber, #17727)
[Link]
It's "whatever" in the same sense as C or C++. You can do whatever you like, but the compiler does not have to understand it the way you wanted it to, just as a C compiler is not compelled to interpret x = ++x + x++ + x - x-- + --x the way you want it to.
C++ Core Guidelines
C++ Core Guidelines