svn commit: r336835 - head/lib/libc/gen

[Konstantin Belousov]

On Sat, Jul 28, 2018 at 01:16:45PM -0700, Conrad Meyer wrote:
> On Sat, Jul 28, 2018 at 1:06 PM, Konstantin Belousov
> <kostikbel at gmail.com> wrote:
> > On Sat, Jul 28, 2018 at 07:08:00PM +0000, Conrad Meyer wrote:
> >>   For unclear reasons, POSIX' definition of these routines spells NULL as
> >>   "(char *)0."  This is needlessly unclear.  One guess might be that POSIX
> >>   targets more exotic computer architectures than FreeBSD does.  Fortunately,
> >>   there is no such problem on any reasonable platform for FreeBSD to support.
> >>   Spell NULL as NULL.
> >
> > The reasons are quite clear.
> 
> Unclear here refers to the lack of documentation, not the absense of a
> possible explanation.
> 
> > Practically NULL has to be defined as '0'
> > or '0L' at best, for C and esp. C++ rules of the pointers automatic
> > casts to work. This means that NULL cannot be used in vararg lists where
> > the pointer is expected.
> 
> This is not true on FreeBSD.  NULL is (void*)0 in all C code, and the
> special nullptr value in C++.  Yes, this is a stronger definition than
> the C standard guarantees.  This is because the C standard permits
> much more exotic architectures than FreeBSD actually runs on.
Our existing practice is to not provide an advise in the man pages
for the userspace code which would harm the portability or the standard
conformance.

> 
> > In other words, the (char *)0 part of the pre-commit text was correct,
> > while after-commit use of NULL only works on machines where pointers
> > have the same representation as ints or longs.
> 
> I believe this encompasses all architectures FreeBSD supports ??? even
> ignoring our sys/_null.h definition of NULL as (void *)0 or nullptr.
I am not so sure about CheriBSD, for instance.