Better handling of integer wraparound in the kernel

* 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).