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

On Tue, Jun 14, 2022 at 1:20 PM Alexander Potapenko <> wrote:
> What about the cases where these uninitialized values are never used
> in the callee?

I assume that what happens is that when things are inlined, the
compiler then sees that there is no actual uninitialized value, and
that's ok.

But if things aren't inlined, I really hope all compilers already warn
about "look, I'm calling this function with an uninitialized

IOW, compilers can - and should - obviously take more information into
account when they can see it.

So no, don't warn for things you can actually see are not used.

IOW, you shouldn't warn because of any _syntactic_ issue of it being
an argument to a function. We often use inlining as an actually
semantically meaningful thing, and the compiler should *not* warn for
some theoretical "if this was not inlined, the argument would be used
and be uninitialized" case.

For an example of this kind of "not really used" thing, I could
imagine that some configuration might need a "cookie" model to pair up
actions, and you have a

        void *cookie;

        start(arg, &cookie);

kind of situation.

But then I could imagine that other configurations don't actually need
or use that "end()" thing at all, and would leave "cookie"
uninitialized, because the only valid use would be an inline function
that is empty, and purely there for those *other* configurations.

Again, if the compiler inlines 'end()', and sees that 'cookie' is not
actually used, then no complaint is needed - or valid.

But if 'cookie()' is an actual real function call, and you don't see
the use of it, then it had better warn.



  reply	other threads:[~2022-06-14 20:44 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
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 [this message]
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).