Re: pairs(t, skey) and ipairs(t, skey)

[Francisco Olarte <folarte@...>]

Hi:


On Wed, Oct 2, 2013 at 10:09 PM, Tim Hill <drtimhill@gmail.com> wrote:
> Agreed, there is always an issue with "how much" validation is enough. Usually, this comes down to an analysis of the consequences of NOT checking some aspect of a parameter. If you don't check for NULL pointers, for example, you risk crashing the app (or OS if you are a driver).

There you need a definition of 'You', I mean, WHO is crashing the app.
If the cient code passes null to strlen it may crash, but it also
crash if it das ((char*)null)=0, it's not strlen's fault. If some
external input generates a null and it gets passed to strlen, it is
the operator feeding the input who crashes it, in which case if the
app should not crash on any input the culprit is the code which
generates and passed the null. As long as it's properly documented,
teh api is ok with any quantity of error checking.

> There is also, of course, the issue of final consequences. Some of the software I design and develop is mission-critical; if it fails unexpectedly people die (really). This leads to a certain level of (healthy) paranoia when writing APIs :)

In this case you are probably not allowed to build a function with
undefined behaviour, which is really complex. But then your API must
document all exceptional cases and behave per the specs. That is not
so simple, a simple strlen() is very difficult to write so it never
fails. NULL is easy, but what about, 1 and -1 cast as pointer, an
slightly out of bounds ( above and below ) pointer to a stack / heap
buffer, or a pointer to a code segment, or to a specially built write
only memory region?

Francisco Olarte