Hacker News Reader

Comment by cesarb | Hacker News Reader

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.

View on HN

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.

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.

Reply on news.ycombinator.com