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. > Now C23 will better clarify that reading such a pointer value (not > ever dereferencing) is Undefined Behavior. We did not change this for C23. 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. Martin > There was a discussion in linux-man@ some years ago, which now I > realize it > didn't end up being applied (I thought we had applied a patch, but it > seems we > didn't). I'll check if we still need such a patch (and I guess we > do, since > we're having this conversation). > > Using the pointer is _wrong_. And by wrong, I mean that it's > Undefined Behavior. > I think that alone is enough to issue a warning. Especially, since > the compiler > already has that information; otherwise, it couldn't have warned > about line 67 > of my example program. I could understand if due to optimizations > the compiler > lost that information, so it couldn't warn, but in this case, there's > no excuse. > > The benefit for users? They'll realize that the code they wrote is > bad. Not even > suspicious, as some warnings warn about suspicious code. This case > is > uncontroversially wrong. That code has no valid reason to be written > that way, > under ISO C. > > Cheers, > > Alex > > > > > Dave > > -- > <http://www.alejandro-colomar.es/> > GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5
