Subj : Re: Software Job Market Myths
To   : comp.software-eng,comp.programming
From : Arthur J. O'Dwyer
Date : Thu Aug 18 2005 10:43 pm


On Wed, 17 Aug 2005, 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?

   Or they might be uninitialized, or freed, or for some other reason have 
undefined values.

> Isn't this one of those religious issues?  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.
>
> 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).
>
> My logic is, gimme a NULL, getta NULL back--you deal with it
> (tho, in some cases, such as a "strlen() substitute", I'd
> treat a NULL as a "" and return 0).

   I agree with Dan Pop's position (as I think I've mentioned before, but I 
feel like repeating myself now) --- if you can't possibly prevent the user 
from stupidly writing

     free(foo); strconcat(foo, bar);

then why are you wasting time trying to prevent him from stupidly writing

     foo = NULL; strconcat(foo, bar);

?

   I do think your proposed semantics ("get NULL, return NULL") are very 
useful in some situations, but /unless/ you're writing subroutines to be 
used in one of those situations (e.g., you have code that's most elegantly 
expressed as

     p = fred(barney(strconcat(foo_or_NULL(), bar_or_NULL())));
     if (p == NULL) {
         /* something failed; we don't care what, exactly */
     }

then IMO you should eschew the bulk and (micro)inefficiency that comes 
with that kind of test. (For debugging, use 'ASSERT' or its ilk.)

-Arthur

.