From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31810 invoked by alias); 15 Jul 2005 14:22:31 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 31786 invoked by uid 48); 15 Jul 2005 14:22:24 -0000 Date: Fri, 15 Jul 2005 14:25:00 -0000 Message-ID: <20050715142224.31783.qmail@sourceware.org> From: "falk at debian dot org" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20050714131031.22485.mattias@virtutech.se> References: <20050714131031.22485.mattias@virtutech.se> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug c/22485] pointer +- integer is never NULL X-Bugzilla-Reason: CC X-SW-Source: 2005-07/txt/msg01899.txt.bz2 List-Id: ------- 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" writes: > | Sorry, I cannot follow you. I'd find it massively unsurprising if > | reinterpret_cast(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(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