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 <no.email@nospam.invalid>
Newsgroups: comp.lang.ada
Subject: Re: Introductory Presentations, especially aimed at C++ programmers!
Date: Thu, 08 Dec 2016 02:25:46 -0800
Organization: A noiseless patient Spider
Message-ID: <87y3zq4t05.fsf@nightsong.com>
References: <jece55l78ag2atq3emcqtpvtj9pri91qug@4ax.com>
	<a18053a0-2566-4e12-a2d0-0def9828c19a@googlegroups.com>
	<1905815374.502825168.454102.laguest-archeia.com@nntp.aioe.org>
	<o29kmm$mt7$1@dont-email.me> <o2a4fn$jdk$1@franka.jacob-sparre.dk>
	<o2a6vq$q8s$1@dont-email.me>
	<f3abc4c7-9009-40eb-ac09-ad984c8d3fec@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: mx02.eternal-september.org;
 posting-host="601cec4476227572321c209a8a18d585";
	logging-data="3501"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1+hZCigdqV9af9lAfqbcXcP"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
Cancel-Lock: sha1:jaeZim/Kb9sWOIkB/vo/KBSVViI=
	sha1:Pl9CSL6qEv2ERbsLDzweNC/yCkY=
Xref: news.eternal-september.org comp.lang.ada:32679
Date: 2016-12-08T02:25:46-08:00
List-Id: <comp.lang.ada>

Maciej Sobczak <see.my.homepage@gmail.com> writes:
> Randy has correctly shown that in Ada it would not be any better - the
> log history would contain the same number of fixes for what is the
> same programming error.  

I'm not convinced: because of C's lack of checks, more bugs make it
through the testing process, and end getting noticed after released,
resulting in fixes in the log.  An Ada programmer might code the same
bug, but it might get caught right away during the developer's private
workflow, so the buggy version wouldn't make it into the public repo
resulting in a bug ticket and fix.

> Instead, you have written: "it is impossible for humans to write code
> in them without making such errors"
>
> The problem is - you did not provide any evidence to claim that those
> same humans would not make such errors in Ada.

I think the claim was that it's impossible for humans to stop making
silly errors in general, not that specific error of mismatched bounds on
a buffer.

> SPARK is a game-changer in this area - but there are too few
> long-lived internet-oriented open-source projects in SPARK to make a
> realistic comparison either.  That is, if for whatever reason it is
> unrealistic to write such projects in SPARK, then SPARK is not a
> solution, either.

In this case another solution is dynamically allocated buffers and
automatic reclamation (GC, RAII, or whatever).  Then a bug could result
in OOM, but that doesn't seem to happen nearly as often as buffer
overflows.

> And *this* is a real argument. Ada is safer not because it would
> prevent programmers from making errors, but because it would help them
> *contain the damage* resulting from those errors. 

Best is to do both.