Received: by 10.223.176.5 with SMTP id f5csp757818wra; Wed, 7 Feb 2018 07:05:59 -0800 (PST) X-Google-Smtp-Source: AH8x225+uQsn0OPpu38R98vZsiPQl0macg8YcrbFVQjjHYrQ198s0xX3Z3f94JcbeiQHcK7gl5V4 X-Received: by 10.101.100.208 with SMTP id t16mr5156908pgv.19.1518015959634; Wed, 07 Feb 2018 07:05:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518015959; cv=none; d=google.com; s=arc-20160816; b=AtZ5CWekt4BilkRqq9WxcQIOKCOVcNCa9is+yB4GpxMWVP985Iyur5N0mcC3aUUQz7 1/yyTtya7tnJIc8eeHKe3Zv4o84zLt8dPgRy2PU2sL3xAPxZaVeOqkVxbuwqYBUceSE+ fPb1QDzvu3t3Fm7L+G5LbN3oFtwVkdUQ+IICVmq9Y00tI8B2fYs+F+nbTTMVTV6T/2bd apvMuROaoQe3RyQj407/e3I8s9PYaDHDd5AcZz6CDp2C16oMwtDmTvyEdSH7ZzpdE+zK XsCg/cRB812xxs6kaQ8cxxlBzKLMaY6lNYrBMO5D112NMNGrK9v2uGshX3gn8cCoPbri JMdg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=STwChZDSJbfx6rfKo7LGUam0ZyeMZwfNg9WImNNXz/Q=; b=lOT334t2qo9DQH/PYFW+GfYaxRH6ZnmfI9JqIi3+zXxKRaFrkMSsIyDz+ivYboldRu sdYNhu1StEAmojUnxJxhPYMTDPx8XZGqby1fc/x7LQY/xFAZB8p7Q4IxbRg0PZORxu6l 0doZGjInI5DW8v6Zc8TyRGqgr8myb26qww1lOYiL5OmjwSFVwuuOc5wtkPG3ItDFttfR YKqhDiSIP8mwb8Ewc+ziH6i9T/yoXjgJW2autD52YS6HGIQr+7RflK4ybrwNs4tdYd0v RTFQPMmrjS8dPgWrp+58ITxsBJ0QLQz0g6KsOOsa7tPOOZ+95QfOpzPBOUjuXmZnHeYi tmFw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z3-v6si1172924plb.117.2018.02.07.07.05.45; Wed, 07 Feb 2018 07:05:59 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754420AbeBGPDf (ORCPT + 99 others); Wed, 7 Feb 2018 10:03:35 -0500 Received: from mx2.suse.de ([195.135.220.15]:52157 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754138AbeBGPDe (ORCPT ); Wed, 7 Feb 2018 10:03:34 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 6C2E1ACC3; Wed, 7 Feb 2018 15:03:32 +0000 (UTC) Date: Wed, 7 Feb 2018 16:03:28 +0100 From: Petr Mladek To: Adam Borowski Cc: Kees Cook , "Tobin C. Harding" , Sergey Senozhatsky , Steven Rostedt , LKML , Andrew Morton , Joe Perches , "Roberts, William C" , Linus Torvalds , David Laight , Randy Dunlap , Geert Uytterhoeven Subject: Re: [PATCH] vsprintf: avoid misleading "(null)" for %px Message-ID: <20180207150328.nuk7f76nutq2trcg@pathway.suse.cz> References: <20180204174521.21383-1-kilobyte@angband.pl> <20180205094438.pfd7ffymlvklpxe7@pathway.suse.cz> <20180205201555.GQ29988@eros> <20180205205817.72dy7e7xzjcnwmhs@angband.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180205205817.72dy7e7xzjcnwmhs@angband.pl> User-Agent: NeoMutt/20170421 (1.8.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 2018-02-05 21:58:17, Adam Borowski wrote: > On Tue, Feb 06, 2018 at 07:32:32AM +1100, Kees Cook wrote: > > On Tue, Feb 6, 2018 at 7:15 AM, Tobin C. Harding wrote: > > > On Tue, Feb 06, 2018 at 05:57:17AM +1100, Kees Cook wrote: > > >> On Mon, Feb 5, 2018 at 8:44 PM, Petr Mladek wrote: > > >> > On Sun 2018-02-04 18:45:21, Adam Borowski wrote: > > >> >> Like %pK already does, print "00000000" instead. > > >> >> > > >> >> This confused people -- the convention is that "(null)" means you tried to > > >> >> dereference a null pointer as opposed to printing the address. > > > > > > Leaving aside what is converting to %px. If we consider that using %px > > > is meant to convey to us that we _really_ want the address, in hex hence > > > the 'x', then it is not surprising that we will get "00000000"'s for a > > > null pointer, right? Yes it is different to before but since we are > > > changing the specifier does this not imply that there may be some > > > change? > > > > I personally prefer 0000s, but if we're going to change this, we need > > to be aware of the difference. > > It's easy to paint this bikeshed any color you guys want to: there's an "if" > already. My preference is also 0000; NULL would be good, too -- I just > don't want (null) as that has a special meaning in usual userspace > implementations; (null) also fits well most other modes of %p as they show > some object the argument points to. Confusion = wasted debugging time. > Let's recap: > > Currently: > not-null null > %pponies object's description (null) > %px address (null) > %pK hash hash > > I'd propose: > not-null null > %pponies object's description (null) > %px address 00000000 > %pK hash 00000000 It makes sense to me[*], so Reviewed-by: Petr Mladek It seems that all people agree with this change. But there was also some confusion. I am going to give it few more days before I push it to Linus. It means waiting for 4.16-rc3 because I will be without reliable internet next week. Anyone, feel free to push it faster. [*] I made some archaeology: The "(null)" string was added by the commit d97106ab53f812910 ("Make %p print '(null)' for NULL pointers"). It was a generic solution to prevent eventual crashes, see https://lkml.kernel.org/r/1230979341-23029-1-git-send-email-xyzzy@speakeasy.org From this point, printing 00000000 for %px looks perfectly fine because it does not crash. In fact, it would have made perfect sense to print 00000000 for pure %p because it did not crash. But nobody has cared about the eventual confusion yet. I am not sure if it makes sense to change the pure %p handling now. Note that printing "(null)" has the advantage that we get this string instead of the hash ;-) Best Regards, Petr