On Fri, 17 Feb 2023, 11:43 Alejandro Colomar, <alx.manpa...@gmail.com> wrote:
> Hi Jonathan, > > On 2/17/23 12: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. > > (uintptr_t)p is defined (I believe) for C <= C17. However, as noted in my > last email, even that is UB for C2x. Of course, UB means that the compiler > might make it defined, but as Martin suggested, that's might have its own > issues. > Yes, I just meant in C++, and C++ has no such rules. > > > > 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 > > :-) > > I would warn in C++ too, as some of that code might be in interfaces that > should be compatible with C. Maybe not include it in -Wextra in C++ (but > include it in C's -Wextra)... > I agree with warning in C++, just not optimizing based on the assumption that any use of an invalid pointer implies unreachable code (as in your original example).
