Igor Schein on Wed, 10 Nov 1999 15:55:01 -0500

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: new guy wants to help with development

On Wed, Nov 10, 1999 at 01:28:19PM +0100, Karim BELABAS wrote:
> 1) Check the description of every GP function one by one in the reference
> manual, adding examples and all kind of possibly helpful information
> (mathematical explanation, algorithms used, efficiency remarks, "dirty
> tricks", ...). This requires experimenting with the command to check what it
> actually does in a variety of situations since, more often than not, the
> manual won't tell you.

This brings an interesting philosophical question, so to speak.  How
much of initial checking should a function perform on its arguments? 
I can name quite a few functions which make assumptions about its
arguments, and cannot handle ( SEGV, BUS, infinite loop, etc. )
arbitrary arguments.  We had this discussion before with Karim, and
his take at this time was that a user should be responsible for his
input.  But considering so many bad input bugs have been uncovered in
the past few weeks by Bill and Michael Somos, maybe the previous
approach should be revised.  If indeed initial check is too expensive
to make sense,  then it should be explicitely mentioned in the manual
( it is mentioned now for some functions, but not all of them ).  

Also, bring on more isxxx() functions, like for example
ispositivedefinitive(), or something to that extend.   If a function
doesn't check its arguments, then those would be useful if a user wants
to run the function in the loop.

I've been uncovering bad input bugs myself for the past year or so.
However, it's been done in non-systematical fashion.  So I'm willing
to participate in a formal review on a cooperative basis, once the
general approach is established.