From owner-svn-src-head@freebsd.org Thu Mar 16 04:53:48 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 7B694D0D708 for ; Thu, 16 Mar 2017 04:53:48 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 431CF1D6B for ; Thu, 16 Mar 2017 04:53:48 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x229.google.com with SMTP id m27so1312833iti.1 for ; Wed, 15 Mar 2017 21:53:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=DZgDUiyaE1JZ8UvvZlSB9MQVvhGjJ4LjuGYPFoakIx8=; b=BTCa7rVke+RgKWDdvHynA4KVtRnWomM242tCKMqF3ah6OroFmKer5wh04ykXycUiYS 92mOGi2PB7Vivq4BUzAYVXJJcH8E1reRS17F2Bf1gp7HG/0cWGFr2pRMqWcUmLSyQUVW WeHI41weZWPMtqt5VRh9V7YwJ1V8UYiOkOOKgMTTJJfSRzl4O+VSvU1kOWFQOUzcFVIk LmKmxoArnouSaVwZUWlYjAZnZcaq1V86NKEH/mGy3c89IIrHDYIFNEZOA+dwMottd+Fl 4YM9WPhb1o4qaVYFH+dlA711k8eibhIqSM+sM+fRUbXJL42b3YH+lJehTqqRCqyF2sCD hXfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=DZgDUiyaE1JZ8UvvZlSB9MQVvhGjJ4LjuGYPFoakIx8=; b=RxvKrlt8zn33SSONqwzHrf9XOglE4c7DWKaBcJs6BweWwLGpSTDYG1Ds/vI4ECrwcO sk5GyCK9X7SjEG1Jr18z8qrR8BBoTfkvzqq5YX9RfqPA/+MKwUyJ75k3RYQcHv4B/jQ+ 9Nk3Ai4G9aO+M8gtcElJ75obltJkk9szb8fZIbNjCXRAAeyj1zSv/rom8pm6gxWTJAJ7 AhtPoaJWZk/zuhwPxUZa7ZJhwboKaLSI2AJHD/3eBIi8xzoJ2qMYz3ijn1C3SjnzzLPC fKfOPAOvbgwcvU4OSotkdpuB/YhS3un9z6ZAC5Bq0PQgGrABV6+ytqj9ae8u5aXPrjmk 9W9g== X-Gm-Message-State: AFeK/H25P5qnOm2Cs3Ry8kfTU04mlfr7gyxxBx/n9KqxzTaTy6X08ff1pbhhE9rXSIEUkok6HPg8Am6w4VMZVQ== X-Received: by 10.36.147.71 with SMTP id y68mr8197697itd.85.1489640027587; Wed, 15 Mar 2017 21:53:47 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.134.129 with HTTP; Wed, 15 Mar 2017 21:53:47 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <58A53702-FFF6-45E7-ACCD-9B776530064E@gmail.com> References: <201703160231.v2G2VgxK082641@repo.freebsd.org> <58A53702-FFF6-45E7-ACCD-9B776530064E@gmail.com> From: Warner Losh Date: Wed, 15 Mar 2017 22:53:47 -0600 X-Google-Sender-Auth: 2EdLVEecw7Wp3YklOT5VFirH7xM Message-ID: Subject: Re: svn commit: r315360 - head/lib/libkvm To: "Ngie Cooper (yaneurabeya)" Cc: Ngie Cooper , 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 04:53:48 -0000 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.