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!.POSTED!not-for-mail From: Paul Rubin Newsgroups: comp.lang.ada Subject: Re: Introductory Presentations, especially aimed at C++ programmers! Date: Thu, 08 Dec 2016 17:30:01 -0800 Organization: A noiseless patient Spider Message-ID: <87mvg551pi.fsf@nightsong.com> References: <1905815374.502825168.454102.laguest-archeia.com@nntp.aioe.org> <87y3zq4t05.fsf@nightsong.com> <0ad2eb12-421f-4159-8df2-5bf7e0dddf06@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="2296ec77468b8e05d91b989ab2eec0a5"; logging-data="11029"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19Elk+POFT7nfdmbc+ItPRE" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:m578u1S2kodnWIkIjxGTbauoN44= sha1:9tyT7j0CQ8eYPBNZXYXNUyuC8+c= Xref: news.eternal-september.org comp.lang.ada:32686 Date: 2016-12-08T17:30:01-08:00 List-Id: Maciej Sobczak writes: > How? Your unit test contains the checks for proper program outcome, This type of thing wouldn't show up in unit tests, since the bug was from a mismatch between behaviours of two separate units. But it could show up during whole-system testing. > Let's say I made a bug that overflows the array under some > specific conditions, but my "private workflow" for testing does not > involve input that overflows that array. This error will go to > release, no matter what is the programming language. Let's say you write the program in C, and you do make such a bug. Assigning arbitrary probabilities to possible outcomes, let's say: 1) with 40% likelihood, your test inputs don't encounter the bug, so you don't detect the bug, and you ship the buggy code. 2) with 30% likelihood, the test input encounters the bug and the program crashes. You find and fix the bug before shipping. 3) with 30% likelihood, the test input encounters the bug, but the program keeps running with no observable misbehaviour (you've written outside the array bounds in a way that doesn't break anything for that particular input). You don't notice the bug so you ship the buggy code. So you have 70% chance of shipping the buggy code. With Ada and subscript checks, you eliminate possibility #3, so it becomes 40% #1 and 60% #2. You aren't guaranteed to fix the bug before shipping, but your chances of doing so have nearly doubled. Sounds like a win to me. >> I think the claim was that it's impossible for humans to stop making >> silly errors in general > Agreed. But the argument was that Ada would prevent humans from making > such errors, which is (yet) an unfounded claim. I think the claim is that Ada prevents a certain class of silly errors, not that it eliminates all silly errors. If you write the code in assembler, there might be 100 places where you could go wrong. If you write it in C, you get control structures, named variables, etc. so that might eliminate 50 of the 100 possible error sites. With Ada you get a serious type system, much more runtime checks, etc., so that might eliminate another 30. It's possible (say with SPARK) to eliminate even more, but never all 100, and it gets harder and harder as you push closer to machine-checked perfection. > Of course, there are errors that can be detected at compile-time and > there are some that are even prevented by the grammar itself - > arguably Ada is stronger in this area than C (or C++), but buffer > overflows are not, at least directly, in this category. I would say that C++ is stronger in this area than Ada, since it has dynamically sized strings in the STL container library. You'd use those instead of fixed-size buffers, so there's no way to overflow except OOM. The main cost becomes non-deterministic timing from the dynamic allocation, making STL strings unsuitable for realtime control. But since we're talking about a desktop application, it's ok to use them.