NULL is not a built-in constant in the C or C++ languages. In fact, in C++ it's more or less obsolete, just use a plain literal 0 instead, the compiler will do the right thing depending on the context.

In newer C++ (C++11 and higher), use nullptr (as pointed out in a comment, thanks).

Otherwise, add

#include <stddef.h>

to get the NULL definition.

Both stdio.h and stdlib.h are, in fact, required to define NULL, all the way back to the original ANSI C standard in 1989¹ (unfortunately this is a .txt file, so I can't link to a specific section; search for 4.9 INPUT/OUTPUT <stdio.h> and/or 4.10 GENERAL UTILITIES <stdlib.h>, and then scroll down a little). If either of the minimized test programs

#include <stdio.h>
void *p = NULL;

or

#include <stdlib.h>
void *p = NULL;

fails to compile to an object file, then your C implementation is buggy. (If the above test programs do not fail to compile, you're gonna need to do some delta-minimization on your actual program, and probably then track down your wiseacre cow-orker who thought it would be funny to put #undef NULL in an application header file.)

NULL is also required to be defined in several other standard headers, but its true home, as you may guess from the cross-references to section 4.1.5 to explain what NULL is supposed to be defined to, is stddef.h. A C implementation that fails to define NULL in stddef.h is egregiously buggy. Also, stddef.h is one of the very few headers that is required to be provided by a "freestanding implementation"; if you are working in an embedded environment, it's possible that they thought they could get away with leaving NULL out of stdio.h or stdlib.h, but they have no excuse whatsoever for leaving it out of stddef.h.

In the alternative, just use 0 for the null pointer constant. That's perfectly fine style as long as all your functions have prototypes. (You have to cast it to pass it correctly to a function that takes a variable number of arguments, e.g. to execl, but you have to cast NULL to pass it correctly to a function that takes a variable number of arguments, so it comes out in the wash.)

¹ Footnote for historians: yes, the linked document really is the ANSI C standard, not the ISO standard with nigh-identical wording (but very different section numbering) that came out a year later. I am not aware of any copy of the 1990 edition of the ISO C standard that is available online at no charge.

The arithmetic itself is not undefined here. Look up how NULL is defined.

Edit: I stand corrected (see below)

In C and C++, pointers are inherently unsafe, that is, when you dereference a pointer, it is your own responsibility to make sure it points somewhere valid; this is part of what "manual memory management" is about (as opposed to the automatic memory management schemes implemented in languages like Java, PHP, or the .NET runtime, which won't allow you to create invalid references without considerable effort).

A common solution that catches many errors is to set all pointers that don't point to anything as NULL (or, in correct C++, 0), and checking for that before accessing the pointer. Specifically, it is common practice to initialize all pointers to NULL (unless you already have something to point them at when you declare them), and set them to NULL when you delete or free() them (unless they go out of scope immediately after that). Example (in C, but also valid C++):

void fill_foo(int* foo) {
    *foo = 23; // this will crash and burn if foo is NULL
}

A better version:

void fill_foo(int* foo) {
    if (!foo) { // this is the NULL check
        printf("This is wrong\n");
        return;
    }
    *foo = 23;
}

Without the null check, passing a NULL pointer into this function will cause a segfault, and there is nothing you can do - the OS will simply kill your process and maybe core-dump or pop up a crash report dialog. With the null check in place, you can perform proper error handling and recover gracefully - correct the problem yourself, abort the current operation, write a log entry, notify the user, whatever is appropriate.