Is there some way to check a pointer ?

[Victor.Lin_1]

Is there some way to check whether a pointer is legal, before memory access ?

[Klaus Crusius · Accepted solution]

There is no general and portable way to check, if an address is valid.
Several thing you could do as an approximation.

1. check if pointer is NULL
2. check if pointer is in allocated heap space (call sbrk(0) at start of program to obtain lower limit, and sbrk(0) to get the current upper limit). If you know the address has been allocated by malloc etc.
3. Install a signal handlers for signals SIGSEGV and SIGBUS. That would allow to react, not to prevent, on wrong addresses.

Regards, Klaus

[A. Clay Stephenson]

Hi Victor:

There is no general rule other than the trivial cases of NULL and outside of heap boundaries. I can tell you are a few of the most common errors:

Consider the following examples:
typedef struct MY_REC
{
char s[80];
struct MY_REC *ptr;
} my_rec;

#define NROWS 100
my_rec *p,*p2;

p = (my_rec *) malloc((size_t) (NROWS * sizeof(my_rec));
It is perfectly legal to treat p as an array and any access between p[0] and p[NROWS - 1] is
perfectly legal but values less than 0 or >= NROWS would be legal c syntax but bad pointer values. You could insert assert statements to test such indices.

A much sneakier error is to take that same array and do this:

#define MORE_ROWS 1000

p2 = (my_rec *) realloc((void *) p,(size_t) (MORE_ROWS * sizeof(my_rec));
if (p2 != NULL) p = p2;

You have just increased the sizeof the array from 100 to 1000. This is the standard dynamic array idiom. Now here's the killer part: Suppose the you had used the ptr field in each member to point to other members. Everything works well until you call realloc. Realloc copies everything in the old block to the new block and tries to simply expand the memory block. However, sometimes it has to move the entire block and the old pointers still point to the locations in the OLD block. Heap tests on the pointer values still appear good but you are pointing to bad values which in the meantime may have even been reassigned with another malloc(), calloc(), etc. I hope I've been clear. In any event, the vast majority of the non-trivial pointer errors and those not caused by programmer confusion using multiple layers of pointers are those outlined above.

Hope this helps, Clay

[Victor.Lin_1]

Thank you very much .

[Mike Stroyan]

If some caller hands one of your functions an address you can use the pstat_procvm
function to see if reading or writing that address will cause a SIGBUS or SIGSEGV.
The attached example shows how to see if an address is in a valid memory region and what permissions such a region has.
You would also need to check alignment of an address for pointer types larger than a byte to see if the pointer can be used for that size of data.

[Gregory Fruth]

By default, HP-UX (or maybe it's the PA-RISC
arch) is too forgiving with NULL pointers. Accessing
a NULL pointer returns a garbage value, so the error
can corrupt your results without raising an exception.

Use cc's -z flag to make NULL pointer access
immediately raise a SIGSEGV. On other platforms
this seems to be the default behavior.

[Erik Trolle]

Use mprotect(2)

I have never tried it myself, but this is likely what you are looking for.