Subj : Re: Software Job Market Myths To : comp.programming,comp.software-eng From : Richard Heathfield Date : Fri Aug 19 2005 09:02 am Chris Sonnack wrote: > Richard Heathfield writes: > >>>> curious as to whether you can find the /other/ robustness >>>> problem that I was describing here. >>> >>> It might prove impossible to derefernce s1 or s2 without >>> catching a SEGV. >> >> Curiosity satisfied. Thank you. > > Because they might be NULL? Yes. There are three states a pointer can be in: 1) null 2) indeterminate 3) points to object or function Alas, in C you cannot easily and portably test function parameters to distinguish between indeterminate (invalid) pointers and legitimate pointers to object or function. But you /can/ test for NULL. Whether you do or not... > Isn't this one of those religious issues? It's more of a design issue, really. I can certainly see that an intelligent programmer might choose, on some occasions, /not/ to check for NULL ("we've used the best algorithms in the book, we've pared the code to the bone, we're 0.00000000137 seconds over budget, we're only ever passing stack addresses to this function, and it's called in a tight loop - if we drop the NULL check, we not only hit budget but gain a tiny bit of slack, too"), and yet might on other occasions wish to retain it. > I recall going > several painful rounds with Dan Pop over this one. He was > adament that the function should fault--as (IIRC) the usual > C lib functions do. Yes, I remember. I think it was a silly argument, to be honest, since the "right" answer depends on circumstances. > I was (and very much am) of the opinion that no low-level > routine of *mine* will allow a fault, if at all possible > (some of my stuff helps run manufacturing production lines, > and a software crash is not viewed kindly). I would tend to prefer an assertion, on the grounds that a program that lets a null pointer get that far is almost certainly screwed. But I can certainly see your point. -- Richard Heathfield "Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk mail: rjh at above domain .