It's not that simple.
The C language definition people have codified rules to make C as fast as FORTRAN and Pascal, but without VAR declarations and strict type checking.. And the C compiler people have implemented the standardised shortcuts to make C as fast as FORTRAN and Pascal.
You can't make assumptions like "a+1 > a" or
hlen + sizeof(struct frag_hdr) < hlen + sizeof(struct frag_hdr) + 8
Hence the "magical built-in compiler support", for magical built-ins like overflow_usub.
Now I'm not commenting on the specific code: probably there is other information that means the expression is safe in that line, using those veriables, at that point. But thst's the way of madness, and how unreliable code gets written.
And personally, I think it would be a bit unfair to blaime the coders for writing obscure compiler-specific code, when the language specification and compiler writers have devised a language where it is not safe to write clear simple code.
There is a small amount of push back: one suggestion is that it would be nice if C compiler developers could offer the option to turn off "unsafe optimisations", based on some simple studies of where their C compiler break expectations. Obviously, this would come up against the old C/unix expectation that it's the users responsibility to be excelent and avoid bugs, not the computers (and that anybody who needs help to avoid language warts is a looser anyway), so I've not seen that's it got much support.