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=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,31c0457c1c47fc2 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-10-22 15:56:23 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!psinet-eu-nl!psiuk-p4!psiuk-p3!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: Have you ever had a bug caused by... Date: Mon, 22 Oct 2001 18:14:22 -0400 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <9r25o0$fla$1@nh.pace.co.uk> References: <27085883.0110191714.784d3d25@posting.google.com> NNTP-Posting-Host: dhcp-200-133.miami.pace.co.uk X-Trace: nh.pace.co.uk 1003788864 16042 136.170.200.133 (22 Oct 2001 22:14:24 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 22 Oct 2001 22:14:24 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.ada:15054 Date: 2001-10-22T22:14:24+00:00 List-Id: The point is fair, but usually what gets considered a "Bug" is something that makes it out of development and is discovered during some kind of formal test or into a fielded system. The developer going through the edit-compile-link-run development cycle and generating an error in the process doesn't really count as a "defect" in the end product. I understand what you are saying: Ada programmers can still make the same mistakes in coding that C programmers can make. But the point is that those errors may not get past the compiler and/or the initial execution fo the code. There is also an advantage to getting some kind of runtime exception in a fielded system as well. If an index gets out of range under unusual conditions not tested for, yes this is a programmer error. But unlike silently running off the end of an array and scrogging memory with possibly non-fatal, yet serious problems being generated, Ada is going to halt the code and (if the implementation is nice!) report where it stopped and why. In most apps that is *usually* a good thing. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "David Bolen" wrote in message news:usncbuz01.fsf@ctwd0143.fitlinxx.com... > mjsilva697@earthlink.net (Mike Silva) writes: > > > While discussing (er, pushing) Ada with some C-coding co-workers today > > I asked a question to which I knew the answer (always the best kind!): > > "Have you ever had a bug caused by accessing off the end of an > > array?" Well, of course, they all had to say yes. Then I started > > thinking of other bugs that they would have to admit to, and which > > wouldn't occur in Ada. Nothing new here (Ada prevents many bugs...), > > but I thought it would be fun and useful to develop a group list as an > > Ada advocacy tool. For example: > > I'm curious as to how Ada _prevents_ such bugs. Are you saying that > no Ada programmer has ever had a bug caused by walking off the end of > an array either? > > I'll buy that Ada will catch that error more quickly than in C, and > probably help isolate the problem more quickly. And even that by > using attributes such as Range, Low and High that you can write more > robust code to avoid the issue (which is no small benefit). But given > that you can still compute indices and then attempt to dereference > based on those computations, there has to be the occasional bug that > is introduced through the use of indices that overflow the array. > > And that's different from saying "wouldn't occur in Ada" ... there's a > difference between better handling of the bug, and not having the bug > ever occur. Or to put it another way, if I have a bug that creates > this condition (or say, tries to set a value outside its range, as in > another example), generating an exception - even if handled - still > implies the bug exists. > > Some of the suggested items appear to be language checks that are > completely possible at compile time, for which I'd buy the "can't > happen" argument. But any issues that can occur at runtime and > require runtime checks and exceptions don't, IMHO, prevent bugs, but > simply act to make it easier to diagnose and manage them when they do > occur. > > -- > -- David > -- > /-----------------------------------------------------------------------\ > \ David Bolen \ E-mail: db3l@fitlinxx.com / > | FitLinxx, Inc. \ Phone: (203) 708-5192 | > / 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \ > \-----------------------------------------------------------------------/