Re: [E-devel] E CVS: forecasts urandom

[Michael J. <e-...@ka...>]

On Saturday, 25 August 2007, at 18:56:44 (+0900),
Carsten Haitzler wrote:

> > In general, shouldn't E_OBJECT_CHECK be made to at least check
> > whether the object is not null? currently the final #else just
> > defines an empty macro.
> 
> depends how much checking we want to do and how much we trust it -
> non-null objects will cause a segv, which is able to be trapped and
> fixed. if we don't segv - we won't crash and thus not fix the
> bug. we could abort() or something else too - but the null will
> guarantee a crash anyway.

The issue being confused here is one of assertions vs. conditions.
Sometimes what is desired is a check for argument validity -- an
invalid value is something that should never be encountered, and its
presence constitutes a bug.  That is what assert() and similar
mechanisms are for:  to abort execution at the point of error so that
the problem can be traced back to its source.

This is often confused with arguments which are programmatically valid
but computationally must be handled separately or not at all.  So the
question is, is it *invalid* (meaning the code is wrong) to pass in a
NULL object, or is it simply a condition which must be handled
*differently* (perhaps by returning right away)?  If the former,
preserving the SEGV is correct (to make sure the bug is fixed).  If
the latter, the check and return is correct.

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <me...@ka...>
Linux Server/Cluster Admin, LBL.gov       Author, Eterm (www.eterm.org)
-----------------------------------------------------------------------
 "Who are you people?"  "We're writers."  "What are you striking for?"
 "More money."  "How much do you earn?"  "$350,000."
                -- conversation with striking Writer's Guild member as
                   reported by Bernard Weintraub in the New York Times