Code being safe or unsafe is a pretty objective metric of quality, methinks.

I agree. Can you explain how this particular code is "safe" or "unsafe"? Again: I'm curious as to how much of what Linus says is taken at face value on HN.

I'm even more interested now, because the fulcrum of Linus's argument isn't safety.

You are committing a logical fallacy. I'm not "the voice of HN", nor am I a representative sample of "what HN thinks".

This is just my opinion.

Using a builtin operation ("addition and comparison of integers") is always safer than using a function that may or may not work the same everywhere. I.e. a nonstandard function.

Also, the proposed code has more levels of indirection, therefore places a higher cognitive load on the reader. These things tend to result in bugs down the road.

And it is also true that "an overflow could still happen", which is mentioned in Linus' critique.

All of these are objective ways to measure how "safe" the code is.

No, that's not what Linus is saying. It's close to the opposite of what he's saying (overflow_usub wraps a builtin). You obviously can't simply use the builtin addition and subtraction of unsigned integers in safe code, because in modern C, integers wrap.

Returning to the thread: why are you so comfortable extrapolating from Linus's rant to "this code would ruin the Linux kernel"? You don't grok the code he's talking about.

Is it because "if Linus is arguing against this code with this much ferocity, the code must be really bad?" Because if that's it, you're starting to see the issue some people have with the tone he uses.

In the discussion Linus is providing his suggested code, which is literally "just a builtin addition", but your opinion is that "He says that you can't use builtin addition".

OK, sure.

That is not in fact what Linus is saying. At this point you might want to take my word for it.