------- Additional Comments From falk at debian dot org 2005-07-15 14:22 ------- (In reply to comment #13) > Subject: Re: pointer +- integer is never NULL > > "falk at debian dot org" <[EMAIL PROTECTED]> writes: > | Sorry, I cannot follow you. I'd find it massively unsurprising if > | reinterpret_cast<int*>(0) produces a null pointer, and if I then get > | undefined behavior for doing something with it that is undefined for a > | null pointer. > > But, if I used reinterpret_cast to turn an integer value 0 into a > pointer, there is no reason why the compiler would assume that I do not > know the underlying machine and what I'm doing with the pointer.
The note merely requires the result of the mapping to be unsurprising; it does not say anything about further operations of this result. Therefore, it is completely irrelevant here. > | As it seems, arguing with different levels of surprisingness seems to > | be somewhat subjective, so I don't think this leads us anywhere. > > I'm not actually arguing on different level of surprisingness. I'm > just looking at reinterpret_cast and its implication. I don't see you bringing any argument here exept one based on a side note about surprisingness, which IMHO doesn't even apply here. So I am still convinced that nullpointer+0 is clearly undefined. > | This is a more relevant point. I don't think this optimization would > | break offsetof-like macros, since they'd use null pointer *constants*, > ^^^^^^^^^^^ > > For the offsetof *macro*, yes > But that is not the case for codes that uses > reinterpret_cat<int*>(expr), where expr is an integer expression with > value 0. Scanning a region of memory starting from zero, is not > exactly the kind of thing never done in practice. Can you give a complete example where this optimization would fail, that you would consider reasonable and realistic? > | which we could easily avoid to tag as non-null. > > so you would have to pretend that a null pointer constant is not null? > That is even more bizarre arithmetic. I have no trouble doing bizarre arithmetic when the user gives invalid input. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22485
