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. > > 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)... Cheers, Alex -- <http://www.alejandro-colomar.es/> GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5
OpenPGP_signature
Description: OpenPGP digital signature
