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 <lewing@xxxxxxxxxx> 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: sjbaker@xxxxxxxx http://www.link.com Home: sjbaker1@xxxxxxxxxxx http://web2.airmail.net/sjbaker1
