Hacker News Reader

Comment by steveklabnik | Hacker News Reader

I think this person is trolling. However, for the purposes of discussion, two things here:

So, in Rust, overflow panics in debug builds, but does wrap around in release builds. So, it is possible this bug would have been caught in testing, but if it wasn't, it still would have slipped into production.

However, that being said, Rust does not do implicit casting between numeric types. So it's very likely that this code would not have compiled in the first place, though I haven't examined it super closely. At that time, the person would have had to cast it, and so the end result would have been roughly the same.

View on HN

AFAIK, Rust can panic on overflow even in release builds if you want it to, at a somewhat heavy performance cost (which is why this is not enabled by default in release builds). In this case, it would convert the issue from "some packets are unexpectedly being discarded" into an immediate crash within the kernel.

Yes, there is a flag to change the default behavior. I am not sure how many folks actually use this flag.

If you want flags, gcc has -Wall -Wextra -Werror which seems like it would have caught this bug. (Of course, if you weren't using -Wall -Wextra from the beginning you'll have a lot of catching up to do before you can build with -Werror.)

Yep, there's tons of details here, which is why I think the original poster was simply trolling.

How heavy is the performance cost really? On x86, wouldn't a JO to a higher address take care of it? It would be a never-taken branch with perfect predictability.

At what cost to code size?

That would be the thing: two bytes in the hot path. But it wouldn't need to be universally applied to every place the + operator appears. Couldn't it just be wrapped around sensitive computations, or generated for the x > y + z idiom? It would be cheaper or at least as cheap as the machine code generated for the manual overflow check (if int_max - z > y ...)

http://www.cs.utah.edu/~regehr/papers/overflow12.pdf

> For undefined behavior checking using precondition checks, slowdown relative to the baseline ranged from −0.5%–191%. In other words, from a tiny accidental speedup to a 3X increase in runtime.

Very interesting, thank you. I question the application of this result to kernel performance, though. Specint has hot arithmetic and UDP packet handling pretty much does not.

In this case, it'd probably be fine. In general I can see it interfering with loop vectorization and bloating code size, so it might not be low-cost in general.

Reply on news.ycombinator.com