History log of /freebsd-10-stable/sys/sys/_null.h
Revision Date Author Comments
(<<< Hide modified files)
(Show modified files >>>)
# 256281 10-Oct-2013 gjb

Copy head (r256279) to stable/10 as part of the 10.0-RELEASE cycle.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

# 228918 27-Dec-2011 theraven

Define NULL to nullptr in C++11 mode (not strictly required, but it makes
migrating code to C++11 easier).

Approved by: dim (mentor)


# 192002 11-May-2009 jhb

*sigh*, while the kernel built, userland C did not. Revert the previous
commit and fix it correctly by removing the _KERNEL check entirely. Now
the kernel always sees the same value of NULL as userland meaning that it
sees __null, 0, or 0L when compiled as C++, and '(void *)0' when compiled
as C.


# 191996 11-May-2009 jhb

Always use __null to define NULL for GCC 4+. Use '0' rather than
'(void *)0' for NULL for C++ compilers compiling kernel code. Together this
makes it easier to build kernel modules using C++.

Reviewed by: imp
MFC after: 3 days


# 187895 29-Jan-2009 rdivacky

Define NULL to be __null in a case of gnu c++. This makes sentinel attribute
work ok in C++. Note that we enable this only for gcc 4.x for any value
of x. The __null was introduced in gcc 4.1 (in fact it was commited
12 days after release of gcc 4.0) and as we have never released any version
of FreeBSD with gcc 4.0 nor ports support gcc 4.0.x this is a safe check.

Using __GNUC_PREREQ__ would require us to include cdefs.h in params.h so
we just check __GNUC__.

Approved by: kib (mentor)
Tested by: exp build of ports (done by pav)
Tested by: make universe (done by me)


# 139825 07-Jan-2005 imp

/* -> /*- for license, minor formatting changes


# 126643 05-Mar-2004 markm

Make NULL a (void*)0 whereever possible, and fix the warnings(-Werror)
that this provokes. "Wherever possible" means "In the kernel OR NOT
C++" (implying C).

There are places where (void *) pointers are not valid, such as for
function pointers, but in the special case of (void *)0, agreement
settles on it being OK.

Most of the fixes were NULL where an integer zero was needed; many
of the fixes were NULL where ascii <nul> ('\0') was needed, and a
few were just "other".

Tested on: i386 sparc64


# 123855 26-Dec-2003 obrien

GC the AMD64 special handling.


# 123741 23-Dec-2003 peter

Add a reminder note about removing the amd64 test here once the gcc33 port
has been updated.


# 123739 23-Dec-2003 peter

Don peril sensitive sunglasses and set NULL to an actual pointer type,
but *only* for the kernel. We can do this because the kernel is not a
standard C application environment. This would have stopped the recent
mtx_* arg NULL/MTX_DEF mixups from going unnoticed for so long.


# 123544 15-Dec-2003 peter

amd64 doesn't define __LP64__ in the compiler, but it definately needs
this definition. It fixes gnome for starters. I haven't tried *emacs yet.
Like IA64, amd64 uses registers for the first few arguments and then
the stack for the rest. This means the 64 bit promotion of the NULL (0)
value is lost and its just pushed on as an 'int' in a varargs call.
When the consumer walks the list and expects to pull off void * pointers
via va_arg, then all hell breaks loose.

Marcel: thanks a million for finding this!


# 123257 07-Dec-2003 marcel

Change the definition of NULL on ia64 (for LP64 compilations) from
an int constant to a long constant. This change improves consistency
in the following two ways:
1. The first 8 arguments are always passed in registers on ia64, which
by virtue of the generated code implicitly widens ints to longs and
allows the use of an 32-bit integral type for 64-bit arguments.
Subsequent arguments are passed onto the memory stack, which does
not exhibit the same behaviour and consequently do not allow this.
In practice this means that variadic functions taking pointers
and given NULL (without cast) work as long as the NULL is passed
in one of the first 8 arguments. A SIGSEGV is more likely the
result if such would be done for stack-based arguments. This is
due to the fact that the upper 4 bytes remain undefined.
2. All 64-bit platforms that FreeBSD supports, with the obvious
exception of ia64, allow 32-bit integral types (specifically NULL)
when 64-bit pointers are expected in variadic functions by way of
how the compiler generates code. As such, code that works correctly
(whether rightfully so or not) on any platform other than ia64, may
fail on ia64.

To more easily allow tweaking of the definition of NULL, this commit
removes the 12 definitions in the various headers and puts it in a
new header that can be included whenever NULL is to be made visible.

This commit fixes GNOME, emacs, xemacs and a whole bunch of ports
that I don't particularly care about at this time...