Re: [RFC] Mitigating unexpected arithmetic overflow

[Peter Zijlstra <peterz@infradead.org>]

On Wed, May 08, 2024 at 04:47:25PM -0700, Linus Torvalds wrote:

> Now, another thing to do might be to treat assignments (and again,
> implicit casts) to 'size_t' specially. In most compilers (certainly in
> gcc), "size_t" is a special type.
> 
> Now, in the kernel, we don't actually use __builtin_size_t (the kernel
> started out with a very standalone type system, and I think it
> actually predated gcc's __builtin_size_t or maybe I just wasn't aware
> of it). But we certainly _could_ - or we could at least use some
> special marked type for our own 'size_t'.

So I've been arguing that since unsigned (and signed too when -fwrapv)
have well defined wrapping semantics and people rely on them, you cannot
go around and assume that wrapping is bad.

You're arguing much the same.

I've proposed that Kees instead adds a type qualifier to explicitly mark
no-overflow / no-wrap types. That way __buildin_size_t is no longer
magical, and it along with all the other __builtin_*_overflow() muck can
go away. You'd end up with things like:

  typedef nowrap unsigned int __kernel_size_t;


or perhaps:

	nowrap int idx = j * sizeof(foo);

etc. To indeed annotate these baby steps, without making code needlessly
ugly with all these __builtin_*_overflow() wrappers.