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!.POSTED!not-for-mail
From: Paul Rubin <no.email@nospam.invalid>
Newsgroups: comp.lang.ada
Subject: Re: How to get Ada to ?cross the chasm??
Date: Sat, 12 May 2018 12:59:57 -0700
Organization: A noiseless patient Spider
Message-ID: <874ljc1w76.fsf@nightsong.com>
References: <fl938cFchk8U1@mid.individual.net> <pcnqgm$1tb4$1@gioia.aioe.org>
	<87k1sg2qux.fsf@nightsong.com> <pcov1b$1cvt$1@gioia.aioe.org>
	<87h8njmk4r.fsf@nightsong.com> <pcq81a$1n85$1@gioia.aioe.org>
	<87po27fbv9.fsf@nightsong.com> <flemg6FkatpU1@mid.individual.net>
	<87in7x62vw.fsf@nightsong.com> <flh2g3F5sg3U1@mid.individual.net>
	<878t8szdtk.fsf@nightsong.com> <fljpeuFogvdU1@mid.individual.net>
	<87tvrdhl5v.fsf@nightsong.com> <flnqeuFkst1U1@mid.individual.net>
	<c62efdtcm1hihak8qutkr26ojt6fs1efgb@4ax.com>
	<flos60FsbbqU1@mid.individual.net>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org;
 posting-host="9dec120c4fa556eefd384bbc0bb3fc36";
	logging-data="13433"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1+LvsDGUuvMdP3KX9ix3ykq"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)
Cancel-Lock: sha1:7bP/qRbcS89JaxU1oofD9pOoAAI=
	sha1:ROA+xWmg3IcpvSZyVMPUS6uW6Aw=
Xref: reader02.eternal-september.org comp.lang.ada:52326
Date: 2018-05-12T12:59:57-07:00
List-Id: <comp.lang.ada>

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> The question that interests me is: if dynamic allocation in the system
> heap is too risky for critical SW, where in this spectrum of dynamic
> memory allocation mechanisms does that risk go away, and why?

The situation you're describing, overflow of a fixed buffer, seems no
different from a stack overflow, and critical-software guidelines
typically prohibit recursion to eliminate the chance of a stack
overflow.  So that buffer overflow possibility should also be
eliminated.

I think of critical embedded applications as being primarily control
applications, i.e. the I/O is to analog or digital ports that are single
wires directly connected to sensors, actuators, etc., with no buffering.

If the application is also communicating with other devices then I'd
hope the communication part of both devices (including flow control to
make sure the buffers never overfill) is included in the verification
process, or else the communication stuff is outside of the critical
portion of the code.