svn commit: r315360 - head/lib/libkvm

[Ngie Cooper (yaneurabeya)]

> On Mar 15, 2017, at 21:53, Warner Losh <imp at bsdimp.com> wrote:
> 
> On Wed, Mar 15, 2017 at 10:44 PM, Ngie Cooper (yaneurabeya)
> <yaneurabeya at gmail.com> wrote:
>> 
>>> On Mar 15, 2017, at 21:32, Warner Losh <imp at bsdimp.com> wrote:
>>> 
>>> On Wed, Mar 15, 2017 at 8:31 PM, Ngie Cooper <ngie at freebsd.org> 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.

	No worries — I’ll take your word :).
Thanks :)!
-Ngie

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20170315/d6362058/attachment.sig>