Hacker News Reader

Comment by arcticbull | Hacker News Reader

Its undefined because it's not guaranteed to happen, that's the whole point, and that's what makes it undesirable. Rust has it right here: don't allow undefined behavior and make the programmer specify the behavior they want.

If they want wrapping overflow, fine. If they don't, great. Tell the compiler don't make it guess/assume/optimize/hope. What this article is arguing for IMO is not the concept of behavior that happens to sometimes work and sometimes not depending on the target machine (because thats crazy) but the functionality itself, which is valuable, and should be explicit and defined. The issue is the last-generation languages like C/C++ don't give you mechanisms to express what you want so you're left hoping the compiler figures out what you meant. That's not a world I want to live in anymore, we can do better.

UB is bad, period. Define what you want, make the compiler do it.

View on HN

Some UB in C is largely regarded as a bad idea, such as signed overflow.

One reason for that is that it's easy to get rid of it, and guess what, we have a bunch of compiler flags just for that.

That absolutely does not mean that "UB is bad, period".

In fact you praise Rust but only safe Rust has no UB.

Actually, if they do end up putting more and more knowledge about the type system invariants in the optimizer, the rules for UB in unsafe code are going to be more complicated than C (think type-based aliasing on steroids).

Don't get me wrong, it's good design to nicely package these in unsafe code, but if your language can craft pointers and load/store from them, your spec will have to have UB (or boundcheck all loads and stores).

> the rules for UB in unsafe code are going to be more complicated than C

This is one of the biggest issues I have with Rust, personally. The interaction between safe and unsafe Rust is not well defined, making it largely impossible to write 'correct' unsafe Rust that isn't broken in some weird situation, or won't ever get broken in later versions of the compiler. And since the Rust compiler has even more information then the C compiler does, it can theoretically make much crazier optimizations then it is doing right now that could break your code down the line. Like you mentioned, if it goes down that route it'll be like the strict-aliasing situation in C but times 10.

> The interaction between safe and unsafe Rust is not well defined

Not contesting the claim, but what in the interaction specifically is not well defined?

The interaction is well defined in the sense of “unsafe leta you do these things” but specifically, the rules about what invariants unsafe is required to uphold are not super well defined. The overall shape is there, but we’re not at an ISO standard level of definition. It’s an active area of work and research.

I wonder if it would help if there were different rules for un-safe Rust and safe Rust?

Or from a more pragmatic point of view, if one could compile un-safe Rust similarly to "optimisations off" in C compilers. No aggressive optimisation, only straight forward translation. While Rust code marked safe could be compiled with the most insane optimisations, and still be ... safe.

If not, I think people concerned about such things, might opt to write the unsafe parts on C (a known quantity) and the safe parts in Rust.

A crate that I wrote, encoding_rs uses unsafe for performance purposes (probably a bit more than absolutely necessary). I'd be very unhappy if unsafe compiled to slower code. The unsafe bits intermingle with safe Rust to such a degree that having to write them in C would make me very unhappy.

For the curious, the performance uses of unsafe in encoding_rs are roughly in these categories:

- Omitting Unicode correctness checks (i.e. asserting that output is correct without having the standard library re-check; Unicode correctness is part of the core competence of the crate).

- Viewing buffers of u8 or u16 as buffers of usize.

- Viewing buffers of u8 or u16 as SIMD register-sized units.

- Omitting bound checks where the compiler fails to elide them and it matters for performance, especially where the performance difference matters for competitiveness with C++.

- Reinterpreting SIMD registers in a different lane configuration. (Exposes endianness but otherwise actually safe.)

- Calling intrinsics that don't really have anything unsafe about them except that Rust makes intrinsics categorically unsafe instead of deciding on a case by case basis if they need to be unsafe.

Of these, viewing buffers as buffers of ALU or SIMD register-sized units are the only cases that come near strict aliasing and could be trouble if the compiler felt eligible to reorder writes of (in the C sense) incompatible types relative to each other on the assumption that buffers of different types are disjoint.

Today I learned that Rust the language, if not the current implementation, could conceivably treat (some) intrinsics as safe.

That won’t work, because safe rust optimizes around rules unsafe is expected to uphold. Even a “straightforward translation” of the unsafe could still easily break invariants safe code expects.

All this stuff is why we’re working so hard on formalizing unsafe! Your parent is right that it’s a bit fuzzy right now, but in the future, we hope that it’ll be way nicer than other unsafe languages. There’s some tooling ideas...

That's interesting to hear, both things.

> Some UB in C is largely regarded as a bad idea, such as signed overflow.

I don't see why it's so bad. I've never really seen a legitimate use for signed overflow, and if it happens, the code is likely buggy anyway.

"I don't know how to properly check overflows so I'm just going to look and see if the number has wrapped" isn't really a good excuse, even if a few people fall for that trap. If anything, I'd rather see a simple, standard way for checking arithmetic introduced.

It sounds like you are under the impression that UB simply means you can't trust signed integers to wrap. Unfortunately, it is worse than that; under surprisingly normal-looking conditions, it is not unheard of that the compiler optimises an interation check away and replaces it with constant true or false, depending on what makes the underlying internal represenation neater.

That's way beyond "can't do X"; it's "the meaning of your program suddenly ceases to exist".

Though note that Rust still has things that are definitely undefined behavior (my favorite: "Transmuting an & to &mut is always UB; No you can't do it; No you're not special" https://doc.rust-lang.org/beta/nomicon/transmutes.html ), it's just that someone has to break out the `unsafe` keyword to get it to happen, and that an error as a result of undefined behavior can always be traced back to an `unsafe` block's invariants being violated somehow.

Definitely, but at least when you see unsafe {} you know all bets are off instead of having to assume all bets are off all the time. I do see what you mean though. The transmute thing is pretty funny imo.

Since any Rust function may use unsafe code, you don't know whether bets are off for any particular function call.

Any public API using `unsafe` code that can't enforce its own unsafe invariants should (and in practice does) get marked as `unsafe` itself in order to force callers to use `unsafe` when calling that function. Of course it's something that, by definition, the compiler cannot enforce on its own and hence requires social norms and social pressure to enforce, and it's therefore fortunate that the Rust community takes it very seriously.

Any Python function may use ctypes, any Haskell function may use unsafePerformIO, ..., so all bets are off all the time.

I don't think that's a particularly useful point, as is.

Not that this "makes the point", necessarily, but GHC Haskell does have the whole Safe/Unsafe Haskell module inference/guarantee, so it may be a bit easier to avoid unexpectedly unsafe behavior entirely.

I have no idea whether any equivalent exists for Rust.

There's not a module-level Safe/Trustworthy/Unsafe division, but as steveklabnik1 says, any potentially-dangerous code has to be placed into an `unsafe` block.

One can also forbid the use of any `unsafe` blocks for a crate/module (with the #[forbid(unsafe_code)] attribute), but this is slightly different to the {-# LANGUAGE Safe #-} pragma in that it does consider imports at all. However, since "unsafety" is modeled in the language in Rust, and is granular, people are encouraged to have every module be "Trustworthy" (in Safe Haskell terms): if an individual function could cause undefined behaviour if misused, it should be marked "unsafe", and a "Safe" module (i.e. one using the forbid above) won't be able to use it.

Rust requires you to to explicitly mark individual blocks of code as unsafe, and you can only do unsafe operations inside of them.

Yeah, in theory. In practice, if someone writes code that is throwing away compiler checks for no reason, you simply don't use it.

But very many pieces of code, even such pedestrian things as data structures require unsafe code.

So the attitude of "only unsafe programs have UB by the Rust spec" effectively means "all programs have UB by the Rust spec"

Rust has it right here: don't allow undefined behavior and make the programmer specify the behavior they want.

If they want wrapping overflow, fine. If they don't, great.

What if I know overflow can't happen (e.g. I have an integer counting from 1 to 10)? How do I say "it doesn't matter how you handle overflow; just do whatever is fastest"?

The parent spoke a bit too broadly. Here’s the rules:

* overflow is a “program error”, not UB

* compilers must either check for overflow and panic, or two’s compliment wrap

* when debug_assertions are on, implementations are required to panic on overflow

This means release mode wraps today, but if it’s cheap enough someday, we could make it panic.

If you want specific semantics on overflow, then you should use the various wrappers and/or methods that let you do them directly, rather than relying on any of the above. But you don’t have to specify; by default, the above is the semantics.

What if rust got "unchecked" (unsafe) versions of arithmetic operations that have C arithmetic semantics. Kind of the opposite of "checked_add".

It’s possible! Nobody has ever proposed it...

In a language with a sufficiently advanced type system you can use Peano numbers to specify a type specifying an integer between 0 and 10. These type systems usually are smart enough to have optimized internal representation of said types.

You can do that in rust, there’s even a package for it. It will destroy your compile times though.

In the future we’ll have const generics that let you express it directly without that shenanigans.

I would love to have something that would translate a more human readable version that looks like a constraint or range that internally translates to the same functionality of the peano solution. If that's what you're saying Rust intends to have then I'm very excited and continue to be impressed by the progress there.

https://github.com/rust-lang/rfcs/blob/master/text/2000-cons... is the current accepted design; we plan to go further in the future, but wanted something minimal at first. This is likely to land in nightly by the end of the year and be stable sometime early next year.

Doesn't Ada have this ability where you define numeric types with a range?

Yes, like so

  type jump_by_tenth is delta 0.1 range 1.0 .. 99.0;

Yes but afaik it translates to runtime checks.

It cannot be done in compile-time in general case. Rice's theorem forbids. Every non-trivial property of a program (like whether result of this function lies in this range for all inputs in that range) is undecidable.

ETA: I'm not completely correct. Ada could have used something akin to 2-complement overflow handling, that is forcing every operation on a range to have a result in the same range, but it introduces runtime overhead too.

Reply on news.ycombinator.com