Run-Time vs. Config-time error checking controls

[Jason Kraftcheck]

On 10/21/2010 11:53 AM, Mark Miller wrote:
> On Thu, 2010-10-21 at 09:35, Carl Ollivier-Gooch wrote:
>> My memory is that we had already agreed that an implementation is free 
>> to skip expensive (and even cheap) checks when compiled in release mode, 
> 
> So, I don't recall there being an ITAPS-wide, agreed upon config-time
> switch names to control this. Do we have any defined?
> 
> I know projects like HDF5 use something like --enable-production or
> --enable-debug but I don't honestly know what the adopted 'ITAPS-way'
> for this is, if there is one. If not, we might ought to propose one
> ASAP.
> 
>> though it should do all checks in debug mode.  The latter is very 
>> important to help developers debug code, but once it's working (i.e., 
>> nothing stupid being done by accident), a lot of those checks are 
>> unnecessary, so turning them off for release code is no problem. 
>> Conditionally-defined macros will do this.  As Mark said, there are 
>> run-time configurable methods for this, too, though I suspect they add a 
>> small amount of overhead in practice.
> 
> There are indeed config-time ways of managing the amount of work a
> library is required to perform for error-checking, etc. And, honestly,
> if the ITAPS project as a whole wants to do it using ONLY a config-time
> control mechanism, I think that would be ok.
> 
> My very strong personal preference, based on a lot of experience with
> this kind of thing though, is a run-time check the default behavior of
> which is controlled at config-time.
> 
> If you config for 'release mode', the checks are OFF by default but can
> be turned ON at run-time. If you config for 'development mode', the
> checks are ON by default but can be turned off at run-time.
> 
> Finally, the run-time controls consist of a) a function in the library
> an application can call to affect ON/OFF control and b) an env. variable
> or command line argument a user can set to override everything else
> (note that a command-line argument appraoch would require a change to
> iMesh_newMesh to accept argc/argv from the command line much like
> MPI_Init does).
> 
> Yeah, there is probably a tiny, imperceptable, run-time cost associated
> with doing it this way. However, the flexibility it affords has always
> trumped concerns for that ;)
> 

If the iMesh API clearly states that developers should not expect an
implementation to support cyclical links, why is that not sufficient?  (I'm
not saying that I think such a limitation is desirable, but that isn't the
point I'm trying to make here.)  All the arguments for strict checking seem
to center around helping developers avoid accidentally doing things that are
not guaranteed to work with all implementations.  While people may think
that this is a good practice, mandating that our implementation conform to
this practice seems well beyond the scope of the API specification.  If
someone wants to verify the portability of their code across iMesh
implementations then they can test it against the reference implementation
(or whatever other iMesh implementations they expect to use it with.)  If
they need to do things that are beyond guarantees of the API then they
should a) choose an implementation that will do what they want and b) be
aware that their code may not work with all implementations.

- jason