NULL != 0

Environmets:

  • compiler: x86_64-linux-gnu 7.4.0, x86_64-linux-gnu 4.8.5
  • assembly: AT&T
  • code base: glibc 2.23.90

All content is written based on GNU C.

As most people know, NULL is not zero in GNU C.

NULL != 0

So what is NULL? Can easily check it by using sample code.

Check with sample code

-> sample source code: null.c

#include <stddef.h>

int main(void) {
	char *value = NULL;

	return 0;
}

-> preprocess only

$ gcc -E null.c

-> result

# 1 "null.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 31 "<command-line>"
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 32 "<command-line>" 2
# 1 "null.c"
# 1 "/usr/lib/gcc/x86_64-linux-gnu/7/include/stddef.h" 1 3 4
.....

# 3 "null.c"
int main(void) {
 char *value = 
# 4 "null.c" 3 4
	((void *)0) /* 0 == ((void *)0) */
...
}

As we can see from the results of pre-process, NULL was replace by ((void *)0).

NULL == ((void *)0)

What happens if include stdio.h instead of stddef.h?

-> include stdio.h instead of stddef.h

#include <stdio.h>

int main(void) {
	char *value = NULL;

	return 0;
}

-> preprocess only

$ gcc -E null.c

-> result

# 4 "null.c"
int main(void) {
 char *value = 
# 5 "null.c" 3 4
	((void *)0)
...
}

The results are the same. This is because NULL is not defined in stdio.h, and just include stddef.h. If NULL is defined in stdio.h, it is redefined by stddef.h.

-> stddef.h is also included by stdio.h

# 1 "null.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 31 "<command-line>"
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 32 "<command-line>" 2
# 1 "null.c"

# 1 "/usr/include/stdio.h" 1 3 4
...
# 1 "/usr/lib/gcc/x86_64-linux-gnu/7/include/stddef.h" 1 3 4
...

-> content of stdio.h

#define __need_size_t
#define __need_NULL
#include <stddef.h>
...

Looking at stddef.h in gcc, NULL is defined as follows.

-> NULL definition in stddef.h

/* A null pointer constant.  */

#if defined (_STDDEF_H) || defined (__need_NULL)
#undef NULL		/* in case <stdio.h> has defined it. */
#ifdef __GNUG__
#define NULL __null
#else   /* G++ */
#ifndef __cplusplus
#define NULL ((void *)0)
#else   /* C++ */
#define NULL 0
#endif  /* C++ */
#endif  /* G++ */
#endif	/* NULL not defined and <stddef.h> or need NULL.  */
#undef	__need_NULL

Note that in GNU C++ compiler1 NULL is defined as __null, and in C++2 defined as 0.

-> check with GNU C++

$ g++ -E null.c

-> result with GNU C++<

# 4 "null.c"
int main(void) {
 char *value = 
# 5 "null.c" 3 4
	__null
...

Then,
Does the problem occur when use 0 instead of NULL or vice versa?
The most significant difference between 0 and NULL is that 0 is int and NULL is void *
. In other words, on a 64-bit machine, the sizes of 0 and NULL will be different.

-> sizeof NULL in 64-bit

#include <stdio.h>

int main(void) {
	printf("sizeof(0): %lu, sizeof(NULL): %lu\n", sizeof(0), sizeof(NULL));

	return 0;
}

-> size of result

sizeof(0): 4, sizeof(NULL): 8

Therefore, putting a 0 in the expectation of NULL makes it possible to pop an un-intended value of 4-bytes. The most easily conceivable situation is va_arg (val, *).

-> problem examples when put 0 not NULL

#include <stdio.h>
#include <stdarg.h>

int expect(const char *fmt, ...) {
	va_list ap;
	char *val;

	va_start(ap, fmt);

	while (val = va_arg(ap, char *))
		printf("value: %s\n", val);

	va_end(ap);

	return 0;
}

int main(void) {
  /* because of x86-64bit calling convention,
        passed many arguments for reproduction. */
	expect("aaa", "bbb", "ccc", "ddd", "fff", "ggg", "hhh", "iii", 0);

	return 0;
}

va_arg expects a char* pointer with a va argument, so it will try to pop 8-bytes on the stack. But if put 0 in place of NULL, 4-byte stack overflow will occur.

-> compile with gcc-4

$ gcc-4.8 -o null null.c

-> result

value: bbb
value: ccc
value: ddd
value: fff
value: ggg
value: hhh
value: iii
Segmentation fault (core dumped)

-> change to

//expect("aaa", "bbb", "ccc", "ddd", "fff", "ggg", "hhh", "iii", 0);
expect("aaa", "bbb", "ccc", "ddd", "fff", "ggg", "hhh", "iii", NULL);

-> result

value: bbb
value: ccc
value: ddd
value: fff
value: ggg
value: hhh
value: iii

For reference, In gcc-7, That issues can not be reproduced. looked at the code compiled with gcc-7, compiled to use pushq when passing arguments instead of push. The compiler seems to be smarter.

...
7d9:	6a 00                	pushq  $0x0
7db:	48 8d 05 f5 00 00 00 	lea    0xf5(%rip),%rax        # 8d7 
...

The functions of the execl family are guided by the that should pass NULL instead of 0 like this.


man execl
The const char *arg and subsequent ellipses in the execl(), execlp(), and execle() functions can be thought of as arg0, arg1, ..., argn.

Together they describe a list of one or more pointers to null-terminated strings that represent the argument list available to the executed program.

The first argument, by convention, should point to the filename associated with the file being executed.
The list of arguments must be terminated by a `null pointer`, and, since these are variadic functions, this pointer must be `cast (char *) NULL`.

The execl implementation of glibc shows why. The execl function expects NULL to counter argc.

-> glibc/posix/execl.c

/* Execute PATH with all arguments after PATH until
   a NULL pointer and environment from `environ'.  */
int
execl (const char *path, const char *arg, ...)
{
  ptrdiff_t argc;
  va_list ap;
  va_start (ap, arg);
  for (argc = 1; va_arg (ap, const char *); argc++)
    {
      if (argc == INT_MAX)
	{
	  va_end (ap);
	  errno = E2BIG;
	  return -1;
	}
    }
  va_end (ap);
....
jooojub.

  1. GNU C++ = (GNUG __= GNUC__&&__cplusplus) 

  2. C++ = (__cplusplus) 

gcc builtin: choose_expr

Requires: * compiler: gcc 3.1 laterLet's take a look at `__builtin_choose_expr` that one of the gcc builtins.This only include in C not C...… Continue reading

gcc builtin: alloca

Published on August 04, 2019

gcc release notes link

Published on July 03, 2019