Re: Introductory Presentations, especially aimed at C++ programmers!

[Paul Rubin <no.email@nospam.invalid>]

Maciej Sobczak <see.my.homepage@gmail.com> 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.