archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <>
To: Nick Desaulniers <>
Cc: Alexander Potapenko <>,
	Evgenii Stepanov <>,
	Kees Cook <>, Marco Elver <>,
	Nathan Chancellor <>,
	Thomas Gleixner <>,
	Vitaly Buka <>,
	Linux Kernel Mailing List <>,
	linux-toolchains <>
Subject: Re: [PATCH] [RFC] Initialization of unused function parameters
Date: Tue, 14 Jun 2022 10:24:14 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Tue, Jun 14, 2022 at 10:11 AM Nick Desaulniers
<> 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

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

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.


  reply	other threads:[~2022-06-14 17:24 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-14 14:48 [PATCH] [RFC] Initialization of unused function parameters Alexander Potapenko
2022-06-14 16:48 ` Linus Torvalds
2022-06-14 17:11   ` Nick Desaulniers
2022-06-14 17:24     ` Linus Torvalds [this message]
2022-06-14 18:08       ` Nick Desaulniers
2022-06-14 22:27         ` Peter Zijlstra
2022-06-14 18:07   ` Alexander Potapenko
2022-06-14 18:30     ` Linus Torvalds
2022-06-14 20:19       ` Alexander Potapenko
2022-06-14 20:43         ` Linus Torvalds
2022-06-14 21:40         ` Segher Boessenkool
2022-06-14 22:08           ` Evgenii Stepanov
2022-06-15  8:30           ` Alexander Potapenko
2022-06-15 16:46             ` Segher Boessenkool

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).