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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!reality.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Introductory Presentations, especially aimed at C++ programmers! Date: Wed, 7 Dec 2016 17:03:22 -0600 Organization: JSA Research & Innovation Message-ID: References: <1905815374.502825168.454102.laguest-archeia.com@nntp.aioe.org> NNTP-Posting-Host: rrsoftware.com X-Trace: franka.jacob-sparre.dk 1481151799 19892 24.196.82.226 (7 Dec 2016 23:03:19 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 7 Dec 2016 23:03:19 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:32668 Date: 2016-12-07T17:03:22-06:00 List-Id: "Jeffrey R. Carter" wrote in message news:o29kmm$mt7$1@dont-email.me... > On 12/07/2016 10:44 AM, Luke A. Guest wrote: >> >> And shoot down the bullshit argument if "any good Programmer wouldn't >> make >> that mistake" because it can happen to anyone. > > Examine the change logs of long-lived, open-source, C++ projects, > especially those that communicate over the internet, like Firefox, and > you'll find lots of fixes for buffer overflows and signed integer > overflows, same as with C: things that are impossible in a well designed > language. The proportion of such errors doesn't seem to decrease with > time, either, so they are continuing to create new errors even as they > patch the old ones. We have decades of experience with these languages > that show beyond the shadow of a doubt that it is impossible for humans to > write code in them without making such errors. To be fair, though, such things can happen in Ada, too. Case in point: something that happened to me today. A customer had what appears to be a permissions problem installing Janus/Ada, so before contacting us, they tried an uninstall. The uninstaller crashed. I asked them to send me the exact message, and it proved to be overflow error in Claw.Registry. Tracking that down showed that the buffer for reading a registry variable (so stuff could be removed from it) wasn't big enough. Of course, Ada detected the error and crashed, but that's only an iota better than what would have happened in C (the uninstaller didn't do its job either way). The problem seemed familar, and it turns out that I had a similar problem in the installer a few years back. And I had increased the buffer size in the installer program back then. But I failed to increase the buffer size in the separate uninstaller program. A rookie mistake. After 35 years of Ada programming. (You may argue precisely what the rookie mistake was, but surely there is one here.) Yet another data point that no one is immune from making silly errors, in any language. It at least helps to have a language where the culture is to detect rather than ignore errors (and especially when customers think the same way, allowing a more rapid squashing of bugs). Randy.