Re: longjmp()/setjmp() difference between gcc 3.3 (Apple) and gcc3.4.x

["Remy X.O. Martin" <vsxo at hotmail dot com>]

On Sun, 23 Jan 2005 13:42:52 +0100, Clifford Wolf <clifford@clifford.at> wrote regarding "Re:
longjmp()/setjmp() difference between gcc 3.3 (Apple) and gcc 3.4.x"

Hello again,

I've been looking some more at this. I've modified my code so that the exact longjmp() behaviour in case of an invalid pointer can be chosen at startup.
But one of my original questions remains, and I'm still hoping to get some feedback on that.

Here's my situation again, in a nutshell. Specific code examples should not be necessary here.
I have a routine that receives a value which it has to translate into a pointer to an internal structure (say, IAddress). This is the sort of scenario that can arise when receiving data from the X11 context mechanism; in my case, it is a routine which is part of a scripting language. Let's say I can cast the value I receive directly onto an IAddress pointer <aa>, and that the IAddress structure has an 'int type' as its first element. Then, the only basic tests I know of to check if I probably  have received something which indeed points to a valid, existing IAddress are

aa!=NULL && aa->type==SpecifiedType

where SpecifiedType is some known, valid type specifier for IAddress. Of course, if the first test passes, the second is not guaranteed to pass without damage. If aa==10, for instance, a bus error is quite likely to occur (it does on G4 and G5 processors). I would like to prevent this sort of error condition to abort my programme, as this is not (directly) a programming error in the script language implementation.

What I'd need would be a magic function like PointerToValidAddress(void *ptr) which returns False if ptr doesn't point to a memory location I can read/write.

In absence, what is the best way to avoid a crash when accessing memory through a received --invalid-- pointer?

Thanks again,
R.

PS: I'm asking here since I expect relatively many people here are familiar with this sort of low-level issues.