Messages in this thread | | | From | Linus Torvalds <> | Date | Tue, 14 Jun 2022 10:24:14 -0700 | Subject | Re: [PATCH] [RFC] Initialization of unused function parameters |
| |
On Tue, Jun 14, 2022 at 10:11 AM Nick Desaulniers <ndesaulniers@google.com> wrote: > > Maybe a new function parameter attribute would be nice?
Right, exactly something like this seems reasonable.
> #define __must_init __attribute__((must_init)) > int init (int * __must_init x) { > // ^ warning: function parameter x marked '__attribute__((must_init))' > not unconditionally initialized > if (stars_dont_align) { > return -42; > } > *x = 42; > return 0; > } > void foo (void) { int x; init(&x); /* use of x without fear */ }
Yeah. So for this pattern of uninitialized pass-by-reference arguments, we'd get the warning in the callee if it's __must_init, and in the caller if it's not.
Now, I suspect that we have a lot of cases where the initializing function returns an error, and we currently don't initialize the pass-by-ref argument in that case.
In a perfect world, we'd have some way to annotate that case too, but I suspect it gets too complicated both for users and for the compiler.
Error handling in C is ugly, but it's also why we in the kernel have that ERR_PTR() model that solves the "return *both* an error *and* a pointer" case. Which is one of the most common cases we have for this situation.
I suspect that the simple "__must_init" model would work well enough for us in practice. Yes, it might make us then initialize things "unnecessarily" in error cases, but that doesn't sound too onerous.
And I think the "__must_init" model makes conceptual sense, in ways that the "caller has to initialize things even if it is literally asking another function to initialize the value" model does *not* make sense.
But hey, I didn't look at just how painful it would really be. This is all "I _think_ that would work really well for the kernel" without any actual data to back it up with.
Linus
| |