From: Jeff Law <jeffreyalaw@gmail.com>
To: Jason Merrill <jason@redhat.com>, Martin Sebor <msebor@gmail.com>,
gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH v2 1/2] add -Wuse-after-free
Date: Wed, 19 Jan 2022 15:53:19 -0700 [thread overview]
Message-ID: <082e24c8-aa59-93be-c3ad-26a01a5b73f8@gmail.com> (raw)
In-Reply-To: <9aa3967f-bdb2-f4b4-eb6c-3ceaa93ee0db@redhat.com>
On 1/11/2022 3:40 PM, Jason Merrill wrote:
> On 11/30/21 17:32, Martin Sebor via Gcc-patches wrote:
>> Attached is a revised patch with the following changes based
>> on your comments:
>>
>> 1) Set and use statement uids to determine which statement
>> precedes which in the same basic block.
>> 2) Avoid testing flag_isolate_erroneous_paths_dereference.
>> 3) Use post-dominance to decide whether to use the "maybe"
>> phrasing vs a definite form.
>>
>> David raised (and in our offline discussion today reiterated)
>> an objection to the default setting of the option being
>> the strictest. I have not changed that in this revision.
>> See my rationale for this choice in my reply below:
>> https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583176.html
>
> In the latest C2x draft I see in the list of undefined behavior
>
> "The value of a pointer that refers to space deallocated by a call to
> the free or realloc function is used (7.22.3)."
>
> So the case that would be technically undefined would be comparing the
> reallocated pointer to the old pointer which has been deallocated.
>
> The C++ draft is more nuanced: it says, "When the end of the duration
> of a region of storage is reached, the values of all pointers
> representing the address of any part of that region of storage become
> invalid pointer values (6.8.3). Indirection through an invalid
> pointer value and passing an invalid pointer value to a deallocation
> function have undefined behavior. Any other use of an invalid pointer
> value has implementation-defined behavior."
>
> So the case above is implementation-defined in C++, not undefined.
>
> Let's put =2 in -Wall for now.
>
> With that change, this and the -Wdangling-pointer patch are OK on
> Friday afternoon if there are no other comments before then.
THanks for picking this up. I've been busier than expected the last
several weeks.
jeff
next prev parent reply other threads:[~2022-01-19 22:53 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-01 22:15 [PATCH 0/2] provide simple detection of indeterminate pointers Martin Sebor
2021-11-01 22:17 ` [PATCH 1/2] add -Wuse-after-free Martin Sebor
2021-11-02 5:32 ` Eric Gallager
2021-11-02 17:09 ` Martin Sebor
2021-11-02 22:29 ` David Malcolm
2021-11-03 0:22 ` Martin Sebor
2021-11-23 1:32 ` Jeff Law
2021-11-23 21:16 ` Martin Sebor
2021-11-30 22:32 ` [PATCH v2 " Martin Sebor
2021-12-07 0:50 ` PING " Martin Sebor
2021-12-13 16:48 ` PING 2 " Martin Sebor
2022-01-04 18:01 ` PING 3 " Martin Sebor
2022-01-10 21:58 ` PING 4 " Martin Sebor
2022-01-11 22:40 ` Jason Merrill
2022-01-16 0:00 ` Martin Sebor
2022-03-26 20:35 ` Remove mysterious '-# Defining these options here in addition to common.opt is necessary' command-line option (was: [PATCH v2 1/2] add -Wuse-after-free) Thomas Schwinge
2022-03-29 9:24 ` options: Remove 'gcc/c-family/c.opt:Wuse-after-free' option definition record " Thomas Schwinge
2022-03-29 15:15 ` Martin Sebor
2022-03-29 18:00 ` Joseph Myers
2022-01-19 22:53 ` Jeff Law [this message]
2021-11-01 22:18 ` [PATCH 2/2] add -Wdangling-pointer [PR #63272] Martin Sebor
2021-11-02 7:40 ` Eric Gallager
2021-11-02 18:38 ` Martin Sebor
2021-11-30 22:55 ` [PATCH v2 " Martin Sebor
2021-12-07 0:51 ` PING " Martin Sebor
2021-12-13 16:50 ` PING 2 " Martin Sebor
2022-01-04 18:02 ` PING 3 " Martin Sebor
2022-01-10 21:51 ` PING 4 " Martin Sebor
2022-01-17 13:46 ` Stephan Bergmann
2022-01-17 19:14 ` Martin Sebor
2022-01-19 14:03 ` Stephan Bergmann
2021-11-08 22:41 ` PING [PATCH 0/2] provide simple detection of indeterminate pointers Martin Sebor
2021-11-15 16:47 ` PING 2 " Martin Sebor
2021-11-22 16:41 ` PING 3 " Martin Sebor
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=082e24c8-aa59-93be-c3ad-26a01a5b73f8@gmail.com \
--to=jeffreyalaw@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jason@redhat.com \
--cc=msebor@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).