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.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1d321b3a6b8bcab2 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1995-01-19 21:01:49 PST Path: nntp.gmd.de!newsserver.jvnc.net!nntpserver.pppl.gov!princeton!udel!gatech!swrinde!news.uh.edu!uuneo.neosoft.com!Starbase.NeoSoft.COM!not-for-mail From: smize@Starbase.NeoSoft.COM (Samuel Mize) Newsgroups: comp.lang.ada Subject: Re: "Subtract C, add Ada" Date: 19 Jan 1995 23:01:49 -0600 Organization: NeoSoft Internet Services +1 713 684 5969 Message-ID: <3fng3t$2ak@Starbase.NeoSoft.COM> References: <3fdcoi$chn@miranda.gmrc.gecm.com> NNTP-Posting-Host: starbase.neosoft.com Date: 1995-01-19T23:01:49-06:00 List-Id: In article <3fdcoi$chn@miranda.gmrc.gecm.com>, R.A.L Williams wrote: > >Robert Dewar wrote.. >> Bill comments that for his points 3. and 4. >> >> 3. uninitialised pointer access >> 4. pointer references to local variables in defunct procedures >> >> "The syntax of Ada .. does not really address 3. or 4." >> >> Taking point 3, it is impossible to have an uninitialized pointer in Ada, >> all pointers are initialized to null, and any attempt to use a null pointer, >> i.e. to dereference it, will cause a constraint error. Seems like pretty >> complete protection to me. > >Yes, you're right, Ada *guarantees* a run time crash, in C/C++ it's just very >likely. ... The rest of your post suggests that you understand this, but I will point it out for the less-versed souls reading this newsgroup: Ada does not guarantee a run-time crash. It guarantees that the program will identify, and respond to, the error. If you have exception handlers properly in place, they can do some default action; e.g., you can drop to a degraded mode. In C/C++, you can (1) dereference a bad value and merrily use it (2) write to an arbitrary address (e.g., the OS or your instruction pointer), creating phantom bugs in other code (3) seg error (core dump). Even a well-designed C program can provide these exciting opportunities, since the occasional human error is unavoidable, not to mention hardware failures. In Ada, you have to make the original error, *and* not provide a fall-back in your exception handlers. Only if you do both will you get a run-time crash. Otherwise, you will get a run-time performance degradation. >likely. It's still not a compile time check so you're relying on the >quality of your run time environment to tie down where the problem >occurs. ... True. Wish we could solve the problem of uninitialized variables, 'cause then we'd know how to solve undecidable problems. >occurs. Of course, in embedded systems you don't want *any* exceptions, >no matter how cleanly you handle them! Sure you do, if there was a programmer error, or a hardware glitch, or a bad memory location, etc. These are the things you don't want. Given that you can't eliminate those, oh *boy* do you want exceptions, given the alternative (core dump at 30,000 feet -- how do I reboot my F-16?!?!?!?) >... I was just trying to point out that using Ada is no substitute >for good engineering practice in design and coding. > Very true. I'm pointing out that Ada provides tools for good engineering practice that are not available in C/C++ . > > >Bill Williams > Sam Mize - smize@starbase.neosoft.com