Better handling of integer wraparound in the kernel

Correct. Thanks for pointing that out!

> But don't actually do that. Just use the intrinsic.

Agreed.

* carrying_add(): A helper method for implementing bignum addition. There's also borrowing_sub() for subtraction. Probably not useful for general-purpose addition.
* checked_add(): Returns an Option<T> which is None if overflow would happen. Nicely compatible with the question mark operator, match, if let, etc. constructs.
* overflowing_add(): Returns the result of wrapping_add() as well as a bool indicating whether we overflowed.
* saturating_add(): Returns (the Rust equivalent of) INT_MAX when we overflow.
* unchecked_add(): Overflow is undefined behavior. Can only be called in an unsafe block (or unsafe function).
* wrapping_add(): Wraps around using two's complement (signed) or modular arithmetic (unsigned).

You could, hypothetically, have a menagerie of different symbols for all of these different use cases, but it's going to look like Perl or APL very quickly. You could, I suppose, pick one of them as the "best" overflow mode and just give that a symbol, but I guarantee you it won't be unchecked_add() as your comment seems to suggest (they are never adding a binary operator that can only be used in unsafe blocks). The more flexible option is picking which mode you "usually" want to use, and using the Wrapping<T> etc. types for that.

One thing that does bother me is the fact that overflowing_add() returns a tuple instead of some kind of ADT wrapper. That would force you to explicitly destructure it and handle both the wrapping and non-wrapping cases. With a tuple, you can forget to check the bool in some code paths. It's not really a disaster because you probably won't have overly elaborate code surrounding the callsite, but it's still an opportunity for things to go wrong.

> What's the point of Rust if it doesn't prevent one of the most common sources of vulnerabilities?

The main reason overflows lead to vulnerabilities is by breaking bounds checks. Since bounds checks are still applied by the compiler in a safe after whatever math you did, there's not really any way to turn it into a memory vulnerability. Unless you're manually writing bound checks in unsafe Rust, which is honestly pretty rare.

This is fine if the program is running on the user's computer. If it is not, then a crash will affect everyone whose requests are being processed by that machine, and in the case of cascade failure, fallout will be wider still. There may be situations where failing rather than producing wrong data is preferred, but it is the responsibility of the programmer to understand that requirement and use checked_add etc. instead of regular arithmetic operators. This is no different to any other functional requirement of a software system - if you write the code wrong, it will not work.

> Overlooking unexpected overflows might result in serious incidents like Cloudbleed [1].

Security is hard. I'm not going to solve the general problem of malicious inputs in an LWN comment, but in general, defensive programming is necessary (not sufficient) to deal with problems of this nature. Most languages do not provide integers that always crash on overflow, so handling overflow correctly is something that serious programmers will find themselves having to deal with on a regular basis regardless. Rust provides the necessary methods for doing this front and center, which is more than you can say for most languages (C is only standardizing the equivalent functions in C23!). If you want stronger guarantees than that, I would suggest rewriting the parser (and perhaps a small part of the parser-adjacent application logic) in wuffs.

Besides, if you allow malicious inputs to cause a crash, you make yourself far more vulnerable to denial of service attacks, which are also a security concern (albeit a less serious one).

I suspect that's almost never the real motivation. Early versions of C didn't even have unsigned types - the only types were int and char, and later float and double, so the only one suitable for a loop counter was int. The `int i; for (i=0; i<n; i++) ...` idiom appears to have already been established back then (https://www.bell-labs.com/usr/dmr/www/cman.pdf), and was widely used in the K&R book (after unsigned had been added to the language). K&R seems to use int as the default for pretty much everything, and only uses unsigned where it really needs all 16/32 bits (e.g. hash values) - and you'd almost never need all those bits for a loop counter because you wouldn't have enough RAM for such a huge array.

Also, `int` is much shorter and easier to type than `unsigned`. So I think people have continued using int for 50+ years because it's idiomatic and easy and there's been little motivation to change, not because they really care about modern compiler micro-optimisations.

Meanwhile in C++ it's idiomatic to use `for (size_t i = 0; ...)` (which is unsigned). As far as I can tell, that's largely because of STL: its designer preferred size_t as it means the library doesn't have to worry about being passed negative values for array sizes etc (C++ is much more interested in type-system-enforced correctness than C is), and it can always represent the largest possible object in memory (which by that time was approaching the 32-bit limit). STL was widely used, so everyone else used size_t for consistency, and to avoid implicit type conversions that could trigger overflows or compiler warnings.

In C++ it's also idiomatic to use `++i` instead of `i++` in loops, because `i` might be an STL iterator that has to do more work to return a copy of the old value in post-increment (at least in old compilers that optimise poorly), and there's no downside to preferring pre-increment, so pre-increment was widely recommended for performance. But I've never heard anybody make a general recommentation of using ssize_t instead of size_t to let the compiler optimise non-overflowing bounds checks - nobody cares about performance _that_ much, except when they've got a specific benchmark to profile and optimise.

A fun interview question is to ask the candidate to write a program which prints out every number between 0 and UINT_MAX inclusive, using only 32 bit arithmetic.

The object, of course, is not to see whether they can, but what mistakes they make along the way, and how they handle Socratic questions about the flaws. Some candidates are quite overconfident that they know what they're doing.

I've seen some very innovative correct answers over the years too. And that's also cool because you can discuss the pitfalls and advantages of their approach over a more conventional approach.