I've read a lot, including here on SO that suggests this is a very bad idea in general and that the only thing you can do safely is exit the program. I'm not sure that this is true.
This is for a pooling memory allocator that hands off large allocations to malloc. During pool_free() a pointer needs to be checked it it belongs to a pool or was allocated with malloc. By rounding the address down to the nearest 1MB boundary, I get a pointer to the beginning of a block of memory in the pool, or undefined if malloc was used. In the first case I can easily verify that the block of memory belongs to the pool, but, if it does not I will either fail this verification, OR I will get an access violation (note that this is a read-only process). Could I not catch this with SEH (Windows) or handle the signal (POSIX) and simply treat it as a failed verification? (i.e. this is only possible if malloc was used, so pass the ptr to free())
Edit: People seem to be missing the OR above. I do not expect to get an access violation if the pointer was allocated with malloc, but it is one possible outcome. The procedure using the pointer to the beginning of the block (at the 1MB boundary) is to verify a magic number, then follow a pointer to the memory pool, and check that it actually contains aforementioned pointer to the block. If any of these read-only steps produces an access violation, it fails validation as surely as if any individual step failed.