linux-toolchains.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Alexander Potapenko <glider@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Evgenii Stepanov <eugenis@google.com>,
	Kees Cook <keescook@chromium.org>, Marco Elver <elver@google.com>,
	Nathan Chancellor <nathan@kernel.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Vitaly Buka <vitalybuka@google.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-toolchains <linux-toolchains@vger.kernel.org>
Subject: Re: [PATCH] [RFC] Initialization of unused function parameters
Date: Wed, 15 Jun 2022 11:46:55 -0500	[thread overview]
Message-ID: <20220615164655.GC25951@gate.crashing.org> (raw)
In-Reply-To: <CAG_fn=UPyoySbzbLQnJkgbfcSkyCD11M=e+W4-T_WoQCXEPFGA@mail.gmail.com>

Hi!

On Wed, Jun 15, 2022 at 10:30:17AM +0200, Alexander Potapenko wrote:
> On Tue, Jun 14, 2022 at 11:45 PM Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
> > Since C11, lvalue conversion of an automatic variable that does not have
> > its address taken is explicitly undefined behaviour (6.3.2.1/2).  So in
> > function "p", both where "c" and where "size" are passed causes UB (so
> > that executing "p" always causes UB btw).
> 
> Thanks for this reference to the standard. I've received another one
> off-list, which lets the variables be address-taken:
> 
> 6.2.4/6: "If an initialization is specified for the object, it is
> performed each time the declaration or compound literal is reached in
> the execution of the block; otherwise, the value becomes indeterminate
> each time the declaration is reached."
> 3.19.2/1: "indeterminate value: either an unspecified value or a trap
> representation"
> 6.2.6.1/5: "Certain object representations need not represent a value
> of the object type. If the stored value of an object has such a
> representation and is read by an lvalue expression that does not have
> character type, the behavior is undefined. If such a representation is
> produced by a side effect that modifies all or any part of the object
> by an lvalue expression that does not have character type, the
> behavior is undefined. [Footnote: Thus, an automatic variable can be
> initialized to a trap representation without causing undefined
> behavior, but the value of the variable cannot be used until a proper
> value is stored in it.] Such a representation is called a trap
> representation."

That only affects types that have trap representations though, which
importantly explicitly does not include unsigned types without padding
bits, and unsigned char always.

Some people (on the standards committee) think all uninitialised uses
should be UB.  And some think not.  But since C11 we have this new
explicit UB for automatic variables that don't have their address taken.

(The background of that is the Itanium NaT (not-a-thing) bit in its
registers; without this new clause compilers for Itanium needed to
initialise many things that they now do not, with some readings of the
standard anyway :-) )

> > GCC does not warn, it has already optimised the code to what you expect
> > by the time this warning is done.  If you use -fno-inline it does warn
> > for both "c" and "size" (via -Wmaybe-uninitialized).
> >
> > But it is still UB!  All bets are off, no compiler can do any correct
> > translation of your program, since there *is none*.
> 
> Then it makes sense for us to report non-trivial cases where
> uninitialized values are actually passed to functions.

Yes, and IMO it makes sense to report this to compilers as well, if they
do not yet warn for some simple cases.

Cheers,


Segher

      reply	other threads:[~2022-06-15 16:54 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
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 [this message]

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20220615164655.GC25951@gate.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=elver@google.com \
    --cc=eugenis@google.com \
    --cc=glider@google.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-toolchains@vger.kernel.org \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=vitalybuka@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).