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

[Martin Uecker <uecker@tugraz.at>]

Am Freitag, dem 17.02.2023 um 12:35 +0100 schrieb Alejandro Colomar:
> Hi Martin,
> 
> On 2/17/23 09:12, Martin Uecker wrote:
> > 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.
> 
> What if the comparison is performed as uintptr_t?

According to the standard, it is allowed to convert a valid
pointer to uintptr_t and then compare it after the object
is freed.  Unfortunately, many compilers will miscompile
such comparisons.  This does not only affect C/C++ but
also happens in "safe" Rust:
https://godbolt.org/z/e53b5a53q

But conversion to uintptr_t after the object is freed
is undefined behavior.


> You wouldn't have trap representations, would you?
> Or we could even go to memcmp(3) to compare as char,
> if paranoic enough :)

We renamed "trap representations" to 
"non-value representation" in C2X because people tend
to misunderstand this term.  It does not necessarily
imply a trap. It simply means that the object
representation does not correspond to a valid value
of the type.

A pointer that is not NULL but also does not
point to an object would have a trap representation
(now: "non-value representation").

A boolean that stores a representation that does
not correspond to true or false is also a non-value 
representation.  In such cases already a load 
(lvalue conversion) of such a value causes
undefined behavior.

Existing (correct) compiler optimizations can break
code which does comparisons of pointers to dead
objects.  So it is not really safe to use such
pointers even if the architecture does not trap
on load of such pointers.

For pointers, there is also the subtle issue that the
representation might be the same in memory as a new
valid pointer to a new object, but it is still
considered a trap representation due to provenance.

> > 
> > 
> > > Now C23 will better clarify that reading such a pointer value (not
> > > ever dereferencing) is Undefined Behavior.
> > 
> > We did not change this for C23.
> 
> C11:
> 
> The value of a pointer becomes indeterminate when
> the object it points to (or just past)
> reaches the end of its lifetime.
> <https://port70.net/%7Ensz/c/c11/n1570.html#6.2.4p2>
> 
> C2x (N3054 is the latest I know):
> 
> If a pointer value is used in an evaluation after
> the object the pointer points to (or just past)
> reaches the end of its lifetime,
> the behavior is undefined.
> <https://www.open-std.org/JTC1/SC22/WG14/www/docs/n3054.pdf#subsection.6.2.4>
> 
> 
> 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.


Martin


> > 
> > 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.
> 
> Agree; making this defined behavior doesn't seem a good idea.
> 
> Cheers,
> 
> Alex
> 
> > 
> > 
> > Martin
>