Messages in this thread | | | Date | Thu, 9 May 2024 20:28:54 +0100 | From | Al Viro <> | Subject | Re: [RFC] Mitigating unexpected arithmetic overflow |
| |
On Thu, May 09, 2024 at 12:15:40PM -0700, Linus Torvalds wrote: > On Thu, 9 May 2024 at 11:48, Al Viro <viro@zeniv.linux.org.uk> wrote: > > > > FWIW, the thing that somewhat worries me about having a helper along > > the lines of combine_to_u64(low, high) is that > > foo->splat = combine_to_u64(something, something_else); > > would be inviting hard-to-catch brainos - > > foo->splat = combine_to_u64(something_else, something); > > Yeah, we'd have to be very clear about naming and ordering. So it > would probably have to be something like > > result = combine_to_u64_hi_lo(high, low); > > to be easy to use. > > The good news is that if you *do* get it wrong despite clear naming, > the resulting value will be so obviously wrong that it's generally a > "Duh!" thing if you do any testing what-so-ever. > > Of course, I say that as somebody who always points out that I haven't > tested my own patches at all, and they are "something like this, > perhaps?". > > But having "hi_lo" kind of naming would hopefully make it really > obvious even when just looking at the source code.
Or something like result = to_high32(high) | to_low32(low); perhaps? ;-)
Re amusing things found by grepping: unsafe_get_user(lo, &__c->sig[1], label); \ unsafe_get_user(hi, &__c->sig[0], label); \ __s->sig[0] = hi | (((long)lo) << 32); \ (compat.h, be64 unsafe_get_compat_sigset())
It is correct, actually, but here 'hi' is 'signals in range 0..31' and 'lo' - 'signals in range 32..63'. Introduced in fb05121fd6a2 "signal: Add unsafe_get_compat_sigset()", looks like nobody had read it carefully enough for a WTF moment - at least no replies along the lines of 'might be a good idea to use less confusing names' anywhere on lore...
| |