From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 107f24,582dff0b3f065a52 X-Google-Attributes: gid107f24,public X-Google-Thread: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-Thread: 109fba,582dff0b3f065a52 X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,582dff0b3f065a52 X-Google-Attributes: gid1014db,public X-Google-ArrivalTime: 2001-08-06 09:07:02 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news.ems.psu.edu!not-for-mail From: cross@augusta.math.psu.edu (Dan Cross) Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.lang.functional Subject: Re: How Ada could have prevented the Red Code distributed denial of service attack. Date: 6 Aug 2001 12:07:00 -0400 Organization: Mememememememmeme Message-ID: <9kmfb4$rfd@augusta.math.psu.edu> References: <3b6a4414.1193645865@news.worldonline.nl> <9ked75$fa8@augusta.math.psu.edu> <3b6e981c.1477345425@news.worldonline.nl> NNTP-Posting-Host: augusta.math.psu.edu X-Trace: boatanchor.ems.psu.edu 997114022 9848 146.186.132.2 (6 Aug 2001 16:07:02 GMT) X-Complaints-To: security@psu.edu NNTP-Posting-Date: 6 Aug 2001 16:07:02 GMT Xref: archiver1.google.com comp.lang.ada:11386 comp.lang.c:72480 comp.lang.c++:80344 comp.lang.functional:7349 Date: 2001-08-06T16:07:02+00:00 List-Id: In article <3b6e981c.1477345425@news.worldonline.nl>, Richard Bos wrote: >> I see. And have you ever worked on a project with more than one >> programmer? > >Sure. And when I write a bug, it's still my bug. When one of us writes a >bug but I don't know who did it yet, it's our bug. It's called >"responsibility". And it's the programmer's responsibility, _not_ the >tools'. If the programmer is really taking responsibility for his or her actions, why would he or she willingly choose to use a tool that s/he was more likely to make a mistake with? Wouldn't programmers with this sense of responsibility be lining up to use tools that would enhance the safety of their software? ...or is it that they're too macho to admit their fallability and instead come up with lame excuses on the order of, ``I make sure to be aware of what I'm doing when I program!'' Well, we all try to do the latter, but what seperates the good programmers from the really great ones is that the latter recognize their own limitations and react accordingly, including using tools that are safer. But no one ever said that, ``oh, the tool will take care of it.'' What we did say was, ``the tool helps the programmer to take care of it.'' And that's the important distinction; tools can't solve problems for us, but some tools are more effective than others at assisting us to solve problems. As has been stated before in this thread, none of us are 100% all the time. We make mistakes; we're human. It's the wise programmer who recognizes this and takes it into account by using tools he or she knows will catch some of those mistakes. She takes responsibility for her actions and attempts to address her natural, humanistic shortcomings by equiping herself with the best tools for the job. >> Who ever said there was a language that would prevent one from making a >> mistake? > >You patently do not understand the meaning of the word "sarcasm". You >must be a USAlien. You resport to ad hominem attacks when your logic breaks down. You must be an arrogant European. :-) >> Indeed, today's programmer's attitude towards quality and quality >> assurance represents a sad truly state of affairs. Case in point, >> programmers who feel that their work is done in a bubble, and refuse to >> use tools which are likely to reduce [*] instances of error injection. > >Such as? Let me remind you that array bounds checking only allows you to >spot array bounds infringements _after_ they have happened. Only a >thorough design can help prevent bugs to occur in the first place. Such as, oh, I don't know, programming in Ada instead of C, making their code legible enough to be reviewed by their peers, actually thinking about what they're doing. That sort of thing. Of course, no one argues that good design (and before that, requirements gathering and analysis) are requisite for reducing defects. In particular, I've stated in this thread that it is absolutely important. But, it's not the only thing, and any tool that helps us catch those other errors is a Good Thing. btw- Array bounds checking isn't the only thing that Ada does to help protect the programmer from his or herself. I will note, however, that it's a lot nicer to get an array bounds exception and handle it accordingly than to simply have a program crash with a segmentation violation or bus error; both common things in C. - Dan C.