On Tue, Mar 31, 2026 at 01:11:22PM -0700, Linus Torvalds wrote:
> On Tue, 31 Mar 2026 at 13:03, Kees Cook <[email protected]> wrote:
> >
> > Mark Rutland had strong reservations about function-level annotations,
> > but I wonder if the combination of new type _and_ function-level
> > annotation could get us something near what would be palatable:
>
> Yes, if we had some way to specify the label, that actually looks
> really nice to me.
>
> So with _this_ kind of interface, all my reservations about it go away.
>
> And as long as the compiler actually requires that label to exist when
> trapping arithmetic is done, I don't think people will use it without
> having fixups.
>
> > Or we could make the label a global part of the language itself so it
> > wouldn't need to be a function annotation, but rather a _required_
> > element of any function that uses a trapping type?
>
> Yes, I'd be ok with that too, because I think in practice you
> typically only ever have one, and I guess you could use local labels -
> or multiple functions - if you really needed to have different
> targets.
Yeah, as you mentioned earlier, I'd agree that nesting is rarely
useful. The only thing I'd want to be careful about is ordering/scope. I
*think* it would just operate as a "goto" and things like the cleanup.h
handlers wouldn't be involved: they operate when a scope is crossed
like before. And I think the overflow result wouldn't be represented
anywhere. i.e. the wrapped/truncated value wouldn't be stored:
int func()
{
...
u8 __ob_trap product = 5;
...
product = a * b; // if store is truncated, goto __overflow
...
return product;
__overflow:
pr_info("%u\n", product); // shows "5"
return -1;
}
(Isn't this just an implicit "try"?)
-Kees
--
Kees Cook
