public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Martin Uecker <uecker@tugraz.at>
To: Alex Colomar <alx.manpages@gmail.com>, GCC <gcc@gcc.gnu.org>,
	Jonathan Wakely <jwakely.gcc@gmail.com>
Cc: "Iker Pedrosa" <ipedrosa@redhat.com>,
	"Florian Weimer" <fweimer@redhat.com>,
	"Paul Eggert" <eggert@cs.ucla.edu>,
	"Michael Kerrisk" <mtk.manpages@gmail.com>,
	"Jₑₙₛ Gustedt" <jens.gustedt@inria.fr>,
	"David Malcolm" <dmalcolm@redhat.com>,
	"Sam James" <sam@gentoo.org>, "Serge Hallyn" <serge@hallyn.com>
Subject: Re: Missed warning (-Wuse-after-free)
Date: Thu, 23 Feb 2023 20:57:14 +0100	[thread overview]
Message-ID: <aa90656815723f21987b73c84b9236d7c34f8ceb.camel@tugraz.at> (raw)
In-Reply-To: <b18a74df-d18e-dc82-b001-5ec65e7c6b26@gmail.com>

Am Donnerstag, dem 23.02.2023 um 20:23 +0100 schrieb Alex Colomar:
> Hi Martin,
> 
> On 2/17/23 14:48, Martin Uecker wrote:
> > > This new wording doesn't even allow one to use memcmp(3);
> > > just reading the pointer value, however you do it, is UB.
> > 
> > memcmp would not use the pointer value but work
> > on the representation bytes and is still allowed.
> 
> Hmm, interesting.  It's rather unspecified behavior. Still 
> unpredictable: (memcmp(&p, &p, sizeof(p) == 0) might evaluate to true or 
> false randomly; the compiler may compile out the call to memcmp(3), 
> since it knows it won't produce any observable behavior.
> 
> <https://software.codidact.com/posts/287905>

No, I think several things get mixed up here.

The representation of a pointer that becomes invalid
does not change.  

So (0 === memcmp(&p, &p, sizeof(p)) always
evaluates to true.

Also in general, an unspecified value is simply unspecified
but does not change anymore.

Reading an uninitialized value of automatic storage whose
address was not taken is undefined behavior, so everything
is possible afterwards.

An uninitialized variable whose address was taken has a
representation which can represent an unspecified value
or a no-value (trap) representation. Reading the 
representation itself is always ok and gives consistent
results. Reading the variable can be undefined behavior
iff it is a trap representation, otherwise you get
the unspecified value which is stored there.

At least this is my reading of the C standard. Compilers
are not full conformant.


Martin








  reply	other threads:[~2023-02-23 19:57 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-16 14:35 Alejandro Colomar
2023-02-16 15:15 ` David Malcolm
2023-02-17  1:04   ` Alejandro Colomar
2023-02-17  1:05     ` Alejandro Colomar
2023-02-17  1:56       ` Sam James
2023-02-17  8:12     ` Martin Uecker
2023-02-17 11:35       ` Alejandro Colomar
2023-02-17 13:34         ` Andreas Schwab
2023-02-17 13:48         ` Martin Uecker
2023-02-23 19:23           ` Alex Colomar
2023-02-23 19:57             ` Martin Uecker [this message]
2023-02-24  0:02               ` Alex Colomar
2023-02-24  1:21                 ` Serge E. Hallyn
2023-02-24  1:42                   ` Alex Colomar
2023-02-24  3:01                     ` Peter Lafreniere
2023-02-24  8:52                       ` Martin Uecker
2023-02-24  8:43                     ` Martin Uecker
2023-02-24 16:10                     ` Serge E. Hallyn
2023-02-24  8:36                   ` Martin Uecker
2023-02-24 16:01                     ` Serge E. Hallyn
2023-02-24 16:37                       ` Martin Uecker
2023-02-17  3:48   ` Siddhesh Poyarekar
2023-02-17 11:22     ` Alejandro Colomar
2023-02-17 13:38       ` Siddhesh Poyarekar
2023-02-17 14:01         ` Mark Wielaard
2023-02-17 14:06           ` Siddhesh Poyarekar
2023-02-17 21:20         ` [PATCH] Make -Wuse-after-free=3 the default one in -Wall Alejandro Colomar
2023-02-17 21:39           ` Siddhesh Poyarekar
2023-02-17 21:41             ` Siddhesh Poyarekar
2023-02-17 22:58             ` Alejandro Colomar
2023-02-17 23:03               ` Siddhesh Poyarekar
2023-02-17 11:24     ` Missed warning (-Wuse-after-free) Jonathan Wakely
2023-02-17 11:43       ` Alejandro Colomar
2023-02-17 12:04         ` Jonathan Wakely
2023-02-17 12:53       ` Siddhesh Poyarekar
2023-02-17 14:10         ` Jonathan Wakely
2023-02-17 13:44     ` David Malcolm
2023-02-17 14:01       ` Siddhesh Poyarekar
2023-02-17  8:49 ` Yann Droneaud

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=aa90656815723f21987b73c84b9236d7c34f8ceb.camel@tugraz.at \
    --to=uecker@tugraz.at \
    --cc=alx.manpages@gmail.com \
    --cc=dmalcolm@redhat.com \
    --cc=eggert@cs.ucla.edu \
    --cc=fweimer@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=ipedrosa@redhat.com \
    --cc=jens.gustedt@inria.fr \
    --cc=jwakely.gcc@gmail.com \
    --cc=mtk.manpages@gmail.com \
    --cc=sam@gentoo.org \
    --cc=serge@hallyn.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 read-only IMAP folder(s) and NNTP newsgroup(s).