public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Martin Uecker <uecker@tugraz.at>
To: Alejandro Colomar <alx.manpages@gmail.com>,
	David Malcolm <dmalcolm@redhat.com>, GCC <gcc@gcc.gnu.org>
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>
Subject: Re: Missed warning (-Wuse-after-free)
Date: Fri, 17 Feb 2023 09:12:45 +0100	[thread overview]
Message-ID: <2148ef80dee2a034ee531d662fc8709d26159ec5.camel@tugraz.at> (raw)
In-Reply-To: <23d3a3ff-adad-ac2e-92a6-4e19f4093143@gmail.com>

Am Freitag, dem 17.02.2023 um 02:04 +0100 schrieb Alejandro Colomar


> 
> [...]
> 
> > 
> > I'm not convinced that it's useful to the end-user to warn about
> > the
> > "use of q itself" case.
> 
> I didn't quote the standard because I couldn't find it.  I was
> searching in C11,
> and it seems that it was only implicitly Undefined Behavior, without
> explicit
> spelling (the value of the pointer was indeterminate, according to
> C11).

The value becomes indeterminate according to 6.2.4p2 in C11.
An indeterminate value may be a trap representation 3.19.2
If such a trap representation is read (the pointer, not
just the pointed-to object), the behavior is undefined
according to 6.2.6.1p5. So it is explitely UB and was
already in C99 or even before.


> Now C23 will better clarify that reading such a pointer value (not
> ever dereferencing) is Undefined Behavior.

We did not change this for C23.

Only the terminology regarding trap representation
(now: non-value representation) and indeterminate
values (now: indeterminate representation) was revised.


There are proposal to define bevahior for such
pointers, but I think this would be a mistake.
(although somehow I ended up being a co-author 
of this paper),

The reason is that every use of such a pointer 
risks running into sublte issues related to pointer 
provenance.

So in my opinion it would be very useful to warn about
all uses of invalid pointers, because fixing this is
much easier than understanding and fixing provenance
issues which might arise from incorrect use of such
pointers.


Martin



> There was a discussion in linux-man@ some years ago, which now I
> realize it
> didn't end up being applied (I thought we had applied a patch, but it
> seems we
> didn't).  I'll check if we still need such a patch (and I guess we
> do, since
> we're having this conversation).
> 
> Using the pointer is _wrong_.  And by wrong, I mean that it's
> Undefined Behavior.
> I think that alone is enough to issue a warning.  Especially, since
> the compiler
> already has that information; otherwise, it couldn't have warned
> about line 67
> of my example program.  I could understand if due to optimizations
> the compiler
> lost that information, so it couldn't warn, but in this case, there's
> no excuse.
> 
> The benefit for users?  They'll realize that the code they wrote is
> bad.  Not even
> suspicious, as some warnings warn about suspicious code.  This case
> is
> uncontroversially wrong.  That code has no valid reason to be written
> that way,
> under ISO C.
> 
> Cheers,
> 
> Alex
> 
> > 
> > Dave
> 
> -- 
> <http://www.alejandro-colomar.es/>
> GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5



  parent reply	other threads:[~2023-02-17  8:12 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 [this message]
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
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=2148ef80dee2a034ee531d662fc8709d26159ec5.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=mtk.manpages@gmail.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).