Subj : Re: Software Job Market Myths
To   : comp.software-eng,comp.programming
From : Chris Sonnack
Date : Fri Aug 19 2005 02:50 pm

Arthur J. O'Dwyer writes:

>> Because [the inputs] 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 [...] 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);

Two simple reasons.  (1) I consider the latter error FAR more common,
so you gain a good measure of robustness with a little effort, and
(2) I don't consider the fact that I can't prevent ALL errors a
reason not to catch the ones I can.


> 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.)

My concern is what happens after deployment, AFTER debugging, when a
crash is not an option.  If the system works very, very hard to prevent
low-level routines from blowing up, higher level code can manage errs
and react gracefully.

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

.