From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757046Ab2DMWCX (ORCPT ); Fri, 13 Apr 2012 18:02:23 -0400 Received: from mail.windriver.com ([147.11.1.11]:52495 "EHLO mail.windriver.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753426Ab2DMWCW (ORCPT ); Fri, 13 Apr 2012 18:02:22 -0400 Date: Fri, 13 Apr 2012 17:01:51 -0500 From: Peter Seebach To: Linus Torvalds CC: Lubos Lunak , Andrew Morton , , Arnd Bergmann Subject: Re: [PATCH][RESEND] do not redefine userspace's NULL #define Message-ID: <20120413170151.20c7230e@wrlaptop> In-Reply-To: References: <201204132124.21294.l.lunak@suse.cz> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.24.4; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 13 Apr 2012 12:39:20 -0700 Linus Torvalds wrote: > And quite frankly, kernel-external definitions of NULL have > traditionally been pure sh*t (ie plain "0" without the cast to a > pointer), so I'm not entirely convinced about this patch. I was going to dispute this, and point out that I'm pretty sure the C++ standard specifically requires the plain-integer 0/0L definition. Then I realized this did not actually contradict your description. Maybe the thing to do would be to ensure that NULL goes to __null, then define that to be ((void *) 0) if the compiler doesn't provide it? The magic behavior of __null seems like it'd be preferable where it is available. -s -- Listen, get this. Nobody with a good compiler needs to be justified.