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 <i...@bsdimp.com> wrote: > On Wed, Mar 15, 2017 at 10:44 PM, Ngie Cooper (yaneurabeya) > <yaneurab...@gmail.com> wrote: >> >>> On Mar 15, 2017, at 21:32, Warner Losh <i...@bsdimp.com> wrote: >>> >>> On Wed, Mar 15, 2017 at 8:31 PM, Ngie Cooper <n...@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. > _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
