Am Donnerstag, dem 23.02.2023 um 20:23 +0100 schrieb Alex Colomar: > Hi Martin, > > On 2/17/23 14:48, Martin Uecker wrote: > > > 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. > > Hmm, interesting. It's rather unspecified behavior. Still > unpredictable: (memcmp(&p, &p, sizeof(p) == 0) might evaluate to true or > false randomly; the compiler may compile out the call to memcmp(3), > since it knows it won't produce any observable behavior. > > <https://software.codidact.com/posts/287905>
No, I think several things get mixed up here. The representation of a pointer that becomes invalid does not change. So (0 === memcmp(&p, &p, sizeof(p)) always evaluates to true. Also in general, an unspecified value is simply unspecified but does not change anymore. Reading an uninitialized value of automatic storage whose address was not taken is undefined behavior, so everything is possible afterwards. An uninitialized variable whose address was taken has a representation which can represent an unspecified value or a no-value (trap) representation. Reading the representation itself is always ok and gives consistent results. Reading the variable can be undefined behavior iff it is a trap representation, otherwise you get the unspecified value which is stored there. At least this is my reading of the C standard. Compilers are not full conformant. Martin
