On Tue, Feb 06, 2024 at 09:42:26AM +0100, Rasmus Villemoes wrote: > On 06/02/2024 00.21, Kees Cook wrote: > > > > > > On February 5, 2024 11:17:12 PM GMT, Eric Biggers <[email protected]> > > wrote: > >> On Mon, Feb 05, 2024 at 02:44:14PM -0800, Kees Cook wrote: > >>> On Mon, Feb 05, 2024 at 12:21:45PM -0800, Eric Biggers wrote: > >>>> On Mon, Feb 05, 2024 at 01:12:30AM -0800, Kees Cook wrote: > >>>>> Subject: Re: [PATCH v3 2/3] overflow: Introduce add_wrap(), sub_wrap(), > >>>>> and mul_wrap() > >>>> > >>>> Maybe these should be called wrapping_add, wrapping_sub, and > >>>> wrapping_mul? > >>>> Those names are more grammatically correct, and Rust chose those names > >>>> too. > >>> > >>> Sure, that works for me. What bout the inc_wrap() and dec_wrap() names? > >>> I assume wrapping_inc() and wrapping_dec() ? > >>> > >> > >> Yes, though I'm not sure those should exist at all. Maybe a += b should > >> just > >> become a = wrapping_add(a, b), instead of wrapping_inc(a, b)? > >> wrapping_inc(a, b) isn't as self-explanatory. Likewise for wrapping_dec. > > > > It was to avoid repeating type information, as it would go from: > > > > var_a += var_b; > > > > to: > > > > var_a = wrapping_add(typeof(var_a), var_a, var_b); > > > > Which repeats "var_a" 3 times. :| > > Yeah, I think that's a reasonable rationale. I'm fine with the > wrapping_* naming, and then the _inc and _dec helpers should follow.
Sounds good. > However, I now wonder if those should really also return the new value. > Yes, that corresponds to the value of the expression (a += b), but > nobody would ever write c = (a += b) or otherwise make use of that > value, and the naming doesn't immediately imply whether one should think > of ++a or a++. They were designed to return the new value, and the selftests validate that. I've updated the kern-doc to reflect this. -- Kees Cook
