Re: Missed warning (-Wuse-after-free)

[Jonathan Wakely <jwakely.gcc@gmail.com>]

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

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

> On 2023-02-17 06:24, Jonathan Wakely wrote:
> > 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/1438.html>
> > https://cplusplus.github.io/CWG/issues/623.html
> > <https://cplusplus.github.io/CWG/issues/623.html>
> > https://cplusplus.github.io/CWG/issues/616.html
> > <https://cplusplus.github.io/CWG/issues/616.html>
> > https://cplusplus.github.io/CWG/issues/312.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 :-)
>
> The codegen problem is a pointer provenance issue and AFAICT,
> -Wuse-after-free=3 is also framed in that context and not as a problem
> with simply taking the numeric value of the pointer to, e.g. log it
> somewhere.
>
> More concretely, something like this is what causes problems:
>
> Foo *old = malloc (sz);
> ...
> Foo *new = realloc (old, newsz);
>
> if (new != old)
>    {
>      old = new;
>      /* Adjust references.  */
>    }
>
> /* Otherwise continue using old unchanged */
> ...
>
> The problem is the assumption that the old pointer continues to be valid
> because it has the same numeric value as the new one.  This is not an
> uncommon code pattern in C, what about C++?
>

Nobody uses realloc in C++. It's only safe for trivial types, because
anything with user-defined construction/assignment/destruction can't be
copied to a new location if the memory is reallocated.





> On a fat pointer-like scheme such as the Arm Morello cpu, this won't
> work at all because even though old and new have the same numeric
> values, old will have been invalidated.
>
> Sid
>