Are there any alternative sentinel values for void* besides NULL in C?

Question

I'm working on a C project where I use a void* variable to hold pointer values. I also need to embed some state information within the same variable. For example, I already use NULL to indicate that the pointer does not refer to any valid memory (i.e., a "null state").

My question is: Are there any other values—like a specific number (e.g., (void*)-1)—that are guaranteed to represent an "invalid" or "sentinel" state in a portable way? In other words, besides NULL, are there any standard or recommended values I can store in a void* to indicate that it doesn't point to a valid object?

If not, what is the best practice for embedding extra state information in pointer variables while ensuring portability across different systems?

Any insights or examples would be greatly appreciated.

What did I try? I attempted to call __builtin_return_address(0) to retrieve the current function's return address. My idea was to use that address as a unique state marker in a void* variable—essentially, to represent a specific "state" that is distinct from NULL.

What was I expecting? I expected that since __builtin_return_address(0) returns a concrete address (obtained from the stack during the function call), it could be used as a non-NULL sentinel value. In other words, I thought that because the return address is stored in memory (albeit on the stack), it might serve as a reliable indicator for a special state within the function, separate from a valid pointer or a NULL pointer.

Answer 1

Just use the address of any global.

char ERROR_FOO_OBJ;
#define ERROR_FOO ((void*)&ERROR_FOO_OBJ)

return ERROR_FOO;

if ( p == ERROR_FOO ) ...;

---

Just-beyond-an-object is a valid pointer (although not one that can be dereferenced). So while unlikely, it's possible to have a valid pointer equal to ERROR_FOO. If it makes sense to return a pointer that points just beyond an object, you can protect yourself by using the following instead:

char ERROR_CODE_OBJS[2];
#define ERROR_FOO ((void*)&ERROR_CODE_OBJS[1])

return ERROR_FOO;

if ( p == ERROR_FOO ) ...;

Thanks to Nate Eldredge who raised this issue in the comments.

Answer 2

Trying to collecting possible answers. Several reserved values exist in various standards, and many in practice have constant values (if a new OS violates this rule, it would break a lot of programs, so this is unlikely to happen).

Data pointers:

• 0 NULL (C89; special casting rules - bit pattern might not match)
• -1 MAP_FAILED for mmap (POSIX.1-2001, SVr4, 4.4BSD)
• -1 (specified as a number) for sbrk (4.3BSD, SUSv1; no longer standard)
• -1 RTLD_NEXT for dlsym (POSIX.1-2001)
• 0 RTLD_DEFAULT for dlsym (POSIX.1-2001)
• -1 PTHREAD_CANCELED for pthread_join (POSIX.1-2001)
• -1 FE_DFL_ENV for fesetenv (C99)
• -2 FE_NOMASK_ENV for fesetenv (GNU)
• -1 LC_GLOBAL_LOCALE for uselocale and duplocale (POSIX.1-2008; specified as distinct from NULL)

Code pointers (may be different than data pointers on some platforms):

• 0 NULL (C89; special casting rules - bit pattern might not match)
• -1 SIG_ERR for signal (C99, POSIX.1-2001)
• 0 SIG_DFL for signal (C99, POSIX.1-2001)
• 1 SIG_IGN for signal (C99, POSIX.1-2001)
• 2 SIG_HOLD for sigset (SVr4, POSIX.1-2001; obsolete)

Again: unless otherwise noted, assume the actual numerical values are not standard. I've checked these on Linux but am pretty sure most have the same values on most other platforms.

Various non-system software often specifies a greater range of fake pointers, usually well within "page" size (but how big that is is highly system-dependent; 128 is probably safe in practice due to errno values).

(I am vaguely aware that Windows has special values with the high bit set, but Windows is as far from standard as possible)