It could, for other reasons, never underflow. C expects that you know what you're doing, and C expected you did a bounds check. But I agree. Cases like this should have a lint warn on them, saying -- "Wake up programmer!"
Fundamentally this problem cannot be solved at the compile-time level because, well, code is dealing with the values which are only known during code execution runtime. So I don't think compiler can do much here other than providing you with a hint that you may rewrite your expression but only to reduce the risk of a potential error, e.g. `if (len + 2 + size > PAGE_SIZE)` still still remains feasible to unsigned integer overflow and to handle the problem fully one must either:
A dynamic_assert() function would be a more general way to check a predicate at runtime. It can be compiled out for release builds and report failures to a centralized log for cases where the assertion is ignored.
Yeah, I mean that's just a normal `assert()` from <assert.h> and it doesn't solve the problem because nobody runs debug builds in production neither it is possible in a reasonably complex software predict in what ways your users are going to be using it and therefore cause bugs you'd never have imagined that could happen.
But speaking of asserts, there could be a runtime assert but which is also _kept_ in release builds. On detection of invariant not being valid, it would just crash the program. That approach works for some fields in engineering but not so much in others however it could be considered as an alternative.
Warned about what exactly? Literally any operation on two unsigned integers can either underflow or overflow and any of those would still be correct and expected behavior.
It's not obvious what the warning would be, unless you want a warning attached to every single arithmetic operation? The compiler can't know what `size` will be in this case.
