public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jonathan Wakely <jwakely.gcc@gmail.com>
To: Siddhesh Poyarekar <siddhesh@gotplt.org>
Cc: David Malcolm <dmalcolm@redhat.com>,
	Alejandro Colomar <alx.manpages@gmail.com>, GCC <gcc@gcc.gnu.org>,
	 Iker Pedrosa <ipedrosa@redhat.com>
Subject: Re: Missed warning (-Wuse-after-free)
Date: Fri, 17 Feb 2023 11:24:48 +0000	[thread overview]
Message-ID: <CAH6eHdSSX1_PSiicNqDe3HdP32uS5E-0ZUhL23u-qcD1r_FzWw@mail.gmail.com> (raw)
In-Reply-To: <d2b243e9-a9a9-bc58-5364-4cca938a9590@gotplt.org>

[-- Attachment #1: Type: text/plain, Size: 1906 bytes --]

On Fri, 17 Feb 2023, 03:49 Siddhesh Poyarekar, <siddhesh@gotplt.org> wrote:

> On 2023-02-16 10:15, David Malcolm via Gcc wrote:
> > I'm not convinced that it's useful to the end-user to warn about the
> > "use of q itself" case.
>
> FWIW, -Wuse-after-free=3 already should do this:
>
> At level 3, the warning also diagnoses uses of indeterminate pointers in
> equality expressions.  All uses of indeterminate pointers are undefined
> but equality tests sometimes appear after
> calls to "realloc" as an attempt to determine whether the call resulted
> in relocating the object to a different address.  They are diagnosed at
> a separate level to aid legacy code gradually
> transition to safe alternatives.  For example, the equality test in the
> function below is diagnosed at this level:
>
> Jakub and I had discussed this in the context of _FORTIFY_SOURCE=3
> (which is anal about this and can break things) and we got pr#105217,
> but that is also a best-effort thing, not really a guarantee.
>
> IMO the analyzer should go that extra mile and warn for the use of q
> itself and maybe deprecate -Wuse-after-free=3 in its favour.
>


Please be aware that in C++ it's implementation-defined, not undefined.

That means that an implementation without trap representations for pointers
can choose to make it behave just like using (uintptr_t)p.

https://cplusplus.github.io/CWG/issues/1438.html
https://cplusplus.github.io/CWG/issues/623.html
https://cplusplus.github.io/CWG/issues/616.html
https://cplusplus.github.io/CWG/issues/312.html

We could still warn in C++ (because the code isn't portable) but I would
strongly suggest we don't influence C++ codegen based on deallocated
pointers being undefined. I don't think gcc supports any targets with
trapping pointers, and there are quite enough sources of UB already. We
don't need to create traps for users where there are no traps for pointers
:-)

  parent reply	other threads:[~2023-02-17 11:25 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
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     ` Jonathan Wakely [this message]
2023-02-17 11:43       ` Missed warning (-Wuse-after-free) 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=CAH6eHdSSX1_PSiicNqDe3HdP32uS5E-0ZUhL23u-qcD1r_FzWw@mail.gmail.com \
    --to=jwakely.gcc@gmail.com \
    --cc=alx.manpages@gmail.com \
    --cc=dmalcolm@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=ipedrosa@redhat.com \
    --cc=siddhesh@gotplt.org \
    /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).