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
