From owner-svn-src-head@freebsd.org Thu Mar 16 05:10:46 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D0C43D0DCFC; Thu, 16 Mar 2017 05:10:46 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 64EA115BE; Thu, 16 Mar 2017 05:10:46 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-wm0-f48.google.com with SMTP id n11so102762816wma.1; Wed, 15 Mar 2017 22:10:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=m38EyLZTxBOyKZvJE0VQYw8LF9gcPglQrFgvsoOO+dE=; b=RhvbcxMLf4shK6RaHvX5VpZ+IjtpQoF8L2z+31muDmjPA2gu0NDZ6LHP3/rUWyXJrE VKJ/aavtxV6qpDUxr69JzVC9Zf8/AIf8wzk02TjYT6f4ERjtchy1GjTTEgH9GOm3eV4o pt+FM5uuMV48n2ci3pPiraLklo4sgJBJcECL8RVoEo58GhotE0eT9g4ljdXkHW0Q0e9N ES/cZK306khYaHrRQpYxE8w2Bg/0y0yFOKEQLG/GuDlm8BNLMtXOzltQa3SHO4wN5JgG XYYzJ4B3o4xQYw077NIoAo35vsq7l4+BUaez2BXuAcpAdwXXl/iCDhiLaRK3RaGIkX1k FpFA== X-Gm-Message-State: AFeK/H1cHEv+ZQdk/vegU5DZuX+wh5Sx1x9iR0hlZyFB05syPA4FP0VnYa4q/QI97rvUwg== X-Received: by 10.28.4.10 with SMTP id 10mr4636985wme.124.1489641043313; Wed, 15 Mar 2017 22:10:43 -0700 (PDT) Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com. [74.125.82.44]) by smtp.gmail.com with ESMTPSA id 53sm4700640wrt.52.2017.03.15.22.10.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Mar 2017 22:10:43 -0700 (PDT) Received: by mail-wm0-f44.google.com with SMTP id n11so102762683wma.1; Wed, 15 Mar 2017 22:10:43 -0700 (PDT) X-Received: by 10.28.154.14 with SMTP id c14mr22123664wme.75.1489641043048; Wed, 15 Mar 2017 22:10:43 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.80.169.4 with HTTP; Wed, 15 Mar 2017 22:10:42 -0700 (PDT) In-Reply-To: References: <201703160231.v2G2VgxK082641@repo.freebsd.org> <58A53702-FFF6-45E7-ACCD-9B776530064E@gmail.com> From: Conrad Meyer Date: Wed, 15 Mar 2017 22:10:42 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r315360 - head/lib/libkvm To: Warner Losh Cc: src-committers , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 05:10:46 -0000 I don't have much to add. Warner is totally correct here. It is a (good) style cleanup with no functional change. Let's leave it alone. Thanks, Conrad On Wed, Mar 15, 2017 at 9:53 PM, Warner Losh wrote: > On Wed, Mar 15, 2017 at 10:44 PM, Ngie Cooper (yaneurabeya) > wrote: >> >>> On Mar 15, 2017, at 21:32, Warner Losh wrote: >>> >>> On Wed, Mar 15, 2017 at 8:31 PM, Ngie Cooper wrote: >>>> Author: ngie >>>> Date: Thu Mar 16 02:31:42 2017 >>>> New Revision: 315360 >>>> URL: https://svnweb.freebsd.org/changeset/base/315360 >>>> >>>> Log: >>>> Return NULL instead of 0 on failure in _kvm_open, kvm_open{,2,files} >>>> >>>> This is being done for the following reasons: >>>> - kvm_open(3), etc says they will return NULL. >>>> - NULL by definition is (void*)0 per POSIX, but can be redefined, >>>> depending on the compiler, etc. >>> >>> No, it can't. The C language requires all integral expressions that >>> evaluate to zero to convert to the NULL pointer. This is independent >>> of the internal representation of the NULL pointer. >>> >>> So this change is an NOP for all compilers. It's a good STYLE change. >> >> Someone made an argument a few weeks ago about NULL being definable as a non-zero value on some esoteric architectures or OSes. > > No. That's confused. NULL must always be 0. A conversion between 0 and > a pointer always must give a null-pointer. Always. You can't defined > NULL to -1 ever. Even if that happens to be the binary representation > of a NULL pointer, it must be 0. > >> I agree though, this is largely stylistic/pedantic for a good cause. If someone set NULL to something non-zero in value, they would be looking for pain :). > > You can never set NULL to non-zero integral value (possibly with a > cast). You can have the internal representation have non-zero bits, > but the compiler must hide that. > > This does mean that M_ZERO and calloc() won't set pointers to null > pointers on such architectures, but this 0 that you replaced is > completely safe. > > I can provide references to the appropriate standards. I made the same > point when someone made that (incorrect) argument. >