musl/include/stddef.h

#ifndef _STDDEF_H
#define _STDDEF_H

#define NULL 0L

#define __NEED_ptrdiff_t
#define __NEED_size_t
#define __NEED_wchar_t

#include <bits/alltypes.h>

#if __GNUC__ > 3
#define offsetof(type, member) __builtin_offsetof(type, member)
#else
#define offsetof(type, member) ((size_t)( (char *)&(((type *)0)->member) - (char *)0 ))
#endif

#endif
initial check-in, version 0.5.0 2011-02-12 00:22:29 -05:00			`#ifndef _STDDEF_H`
			`#define _STDDEF_H`

use a common definition of NULL as 0L for C and C++ the historical mess of having different definitions for C and C++ comes from the historical C definition as (void )0 and the fact that (void )0 can't be used in C++ because it does not convert to other pointer types implicitly. however, using plain 0 in C++ exposed bugs in C++ programs that call variadic functions with NULL as an argument and (wrongly; this is UB) expect it to arrive as a null pointer. on 64-bit machines, the high bits end up containing junk. glibc dodges the issue by using a GCC extension __null to define NULL; this is observably non-conforming because a conforming application could observe the definition of NULL via stringizing and see that it is neither an integer constant expression with value zero nor such an expression cast to void. switching to 0L eliminates the issue and provides compatibility with broken applications, since on all musl targets, long and pointers have the same size, representation, and argument-passing convention. we could maintain separate C and C++ definitions of NULL (i.e. just use 0L on C++ and use (void )0 on C) but after careful analysis, it seems extremely difficult for a C program to even determine whether NULL has integer or pointer type, much less depend in subtle, unintentional ways, on whether it does. C89 seems to have no way to make the distinction. on C99, the fact that (int)(void )0 is not an integer constant expression, along with subtle VLA/sizeof semantics, can be used to make the distinction, but many compilers are non-conforming and give the wrong result to this test anyway. on C11, _Generic can trivially make the distinction, but it seems unlikely that code targetting C11 would be so backwards in caring which definition of NULL an implementation uses. as such, the simplest path of using the same definition for NULL in both C and C++ was chosen. the #undef directive was also removed so that the compiler can catch and give a warning or error on redefinition if buggy programs have defined their own versions of NULL prior to inclusion of standard headers. 2013-01-18 20:35:26 -05:00			`#define NULL 0L`
initial check-in, version 0.5.0 2011-02-12 00:22:29 -05:00
			`#define __NEED_ptrdiff_t`
			`#define __NEED_size_t`
			`#define __NEED_wchar_t`

			`#include <bits/alltypes.h>`

use __builtin_offsetof to implement offsetof when possible apparently recent gcc versions have intentionally broken the traditional definition by treating it as a non-constant expression. the traditional definition may also be problematic for c++ programs. 2012-12-05 00:00:42 -05:00			`#if __GNUC__ > 3`
			`#define offsetof(type, member) __builtin_offsetof(type, member)`
			`#else`
initial check-in, version 0.5.0 2011-02-12 00:22:29 -05:00			`#define offsetof(type, member) ((size_t)( (char )&(((type )0)->member) - (char *)0 ))`
use __builtin_offsetof to implement offsetof when possible apparently recent gcc versions have intentionally broken the traditional definition by treating it as a non-constant expression. the traditional definition may also be problematic for c++ programs. 2012-12-05 00:00:42 -05:00			`#endif`
initial check-in, version 0.5.0 2011-02-12 00:22:29 -05:00
			`#endif`