On Sun, 9 Feb 2025 at 02:56, David Laight <david.laight.linux@xxxxxxxxx> wrote:
>
> Code can then be changed:
> - if (!user_read_access_begin(from, sizeof(*from)))
> + if (!masked_user_read_access_begin(&from, sizeof(*from)))
> return -EFAULT;
I really dislike the use of "pass pointer to simple variable you are
going to change" interfaces which is why I didn't do it this way.
It's actually one of my least favorite parts of C - and one of the
things that Rust got right - because the whole "error separate from
return value" is such an important thing for graceful error handling.
And it's also why we use error pointers in the kernel: because I
really *hated* all the cases where people were returning separate
errors and results. The kernel error pointer thing may seem obvious
and natural to people now, but it was a fairly big change at the time.
I'd actually much prefer the "goto efault" model that
"unsafe_get/put_user()" uses than passing in the other return value
with a pointer.
I wish we had a good error handling model.
Not the async crap that is exceptions with try/catch (or
setjmp/longjmp - the horror). Just nice synchronous error handling
that doesn't require the whole "hide return value as a in-out
argument".
I know people think 'goto' and labels are bad. But I seriously think
they are better and more legible constructs than the 'return value in
arguments'.
Yes, you can make spaghetti code with goto and labels. But 'return
value in arguments' is worse, because it makes the *data flow* harder
to see.
Linus
