On Sat, Nov 12 2022, Jeff King wrote: > On Sat, Nov 12, 2022 at 11:42:09AM +0100, René Scharfe wrote: > >> > E.g. we have plenty of code that assumes ASCII, instead of catering to >> > EBCDIC, and assuming NULL is (void *)0, not (void *)123456 or whatever. >> >> NULL is defined as "0" or "(void *)0" by C99 6.3.2.3 Pointers paragraph >> 3 and 7.17 Common definitions <stddef.h> paragraph 3. > > I think he is alluding to the fact that while the standard requires that > a "0" constant refers to a NULL pointer, the representation does not > have to be all-bits-zero. So: > > char *foo = 0; > > is fine, but: > > char *foo; > memset(foo, 0, sizeof(&foo)); Yes, to elaborate: the "null pointer constant" referred to in 6.3.2.3 deliberately leaves room for the representation being unequal to the "all zero bits". And as you point out the former example is portable, but not the latter. > is not. And we absolutely do the latter in our code base anyway, because > it's convenient and unlikely to be a problem on practical platforms. And > I think it has always been our attitude in this community to let > engineering practicality trump strict adherence to the standard. But > "practicality" there should be measuring the tradeoff of how useful > something is versus how likely it is to bite us. All I've been trying to get across in this sub-thread is that there's an interesting empirical question here: Are we in fact targeting an architecture where J.5.7 isn't implemented, or likely to have one sneak up on us? I don't think so, and timing-wise deciding to be paranoid about this particular thing would leave that question unanswered, when all we have to do is wait a bit (some of the slower platforms tend to be a few releases behind). The argument for the change[1] (further articulated upthread) hasn't answered the "do we target such an arch?", but seems to just fall back to general standards paranoia. Which isn't an invalid argument in itself. But doesn't really address why we'd be worried about *this* particular thing, but not e.g. those sort of memsets, assuming ASCII ordering for 'A'..'z' etc. > In the case under discussion, my gut feeling agrees with you, though. > I'm skeptical that equivalence of object and function pointers is all > that useful in practice. And your mention of CHERI seems like a > plausible way it could bite us. I think the post-image of [1] looks nicer when reviewed stand-alone, so I'm not against the change per-se, I actually like it. And I don't have a use-case for using that feature further, in a way that isn't easy to do differently. But e.g. now we're having a parallel discussion about using some 3rd party bitmap library. We might e.g. want to incorporate some 3rd party JIT or whatever in the future. If we run into this question again it would be nice to have it answered already. And if we didn't have this J.5.7 reliance in that code already I don't think it would be worth the effort to introduce one as a test balloon. I'm only saying this in the context that we already have one. 1. https://lore.kernel.org/git/c64e4fa5-62c2-2a93-a4ef-bd84407ea570@xxxxxx/
