On Thu, 30 Aug 2001, Stephen Robert Norris wrote:

> On Wed, Aug 29, 2001 at 05:14:36PM -0500, Kelly Martin wrote:
> > On 29 Aug 2001 16:59:18 -0500, Larry Ewing <[EMAIL PROTECTED]> said:
> >
> > >Ah so it is the libraries fault that it crashes when you pass it an
> > >unterminated string?
> >
> > Yes, in this case bad design on the part of the library designer for
> > allowing such behavior.  I realize that the use of null-terminated
> > strings is a legacy of the original C runtime library.  That doesn't
> > mean that it's right.
> >
> > Kelly
>
> So it's the library's fault if I pass it a bad pointer and it causes
> a SEGV?

This is a silly debate.

* There are cases where utter software reliability is required.

  In these cases, having a subroutine identify errors in it's inputs
  may well be pointless because there is almost certainly no action
  it can take to recover the situation anyway - you simply have to
  have all your software be bug free - and if it is then there is no
  need to check function parameters anyway.  If your Airbus fly-by-wire
  software's sqrt routine is given -1 as a parameter, you are already
  in deep trouble and:

  fprintf ( stderr, "Oh my GOD we're all going to DIE!!\n" ) ;
  return 0 ;

  ...just isn't going to cut it!  Even with proper heirarchical
  exception handling, this just isn't going to work.

* There are cases where it IS important to KNOW that there is an
  error then it is worth doing horrible things like not using
  null-terminated strings or not passing pointers and having
  every subroutine check all of it's arguments minutely.  You
  should realise though that you have to design-for-checkability
  and the cost of doing that is quite high.  I used to design
  telephone exchanges and they fall into this category.  You
  really need special custom programming languages that avoid
  these situations by design.

  Then you get into all the hurt of testing the error trapping
  mechanisms using a whole new raft of code that'll get thrown
  away eventually.  You can't test it with your live code because
  that's probably bug-free anyway and will never trigger the
  fault conditions whose recovery routines you are trying to test.

* There are yet other cases where performance is so critical
  that starting every subroutine with a dozen lines of parameter
  checking code is too costly to contemplate.  I've worked in
  embedded environments where that is definitely the case.

So everyone is right and we can conveniently end this horribly
off-topic and silly debate.

----
Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: [EMAIL PROTECTED]           http://www.link.com
Home: [EMAIL PROTECTED]       http://web2.airmail.net/sjbaker1

_______________________________________________
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Reply via email to