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!feeder.eternal-september.org!news.unit0.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: How to get Ada to ?cross the chasm?? Date: Sun, 13 May 2018 16:19:33 +0300 Organization: Tidorum Ltd Message-ID: References: <87k1sg2qux.fsf@nightsong.com> <87h8njmk4r.fsf@nightsong.com> <87po27fbv9.fsf@nightsong.com> <87in7x62vw.fsf@nightsong.com> <878t8szdtk.fsf@nightsong.com> <87tvrdhl5v.fsf@nightsong.com> <874ljc1w76.fsf@nightsong.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net o7CUJNtI3p/x4QRH5GWbdAr5riu+O9hzcEaUR30mGM3+nfWK3O Cancel-Lock: sha1:yzflz2AyCYcNkyQbn6lUhNE0jno= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: <874ljc1w76.fsf@nightsong.com> Xref: reader02.eternal-september.org comp.lang.ada:52336 Date: 2018-05-13T16:19:33+03:00 List-Id: On 18-05-12 22:59 , Paul Rubin wrote: > Niklas Holsti 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. The difference is how the overflow can/cannot be eliminated. Taking the wide interpretation of "dynamic allocation", stack space is indeed dynamically allocated by every push and released by every pop. But a suitable programming discipline (no recursion, no dynamically sized stack-allocated data) allows a static computation of an upper bound on the stack usage. Statically allocating a stack area of that size eliminates the risk of overflow. For the UART input-line buffer, the number of non-CR characters received before a CR character depends on external causes; the receiving program cannot control it; it can only control what it, itself, does, if the buffer threatens to overflow. > 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. I think most such applications also have logging functions, at least in order to report errors as anomaly events. Such events could occur at a higher rate than the log channel can consume them. > 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) Flow control can also *cause* buffer overflow: if the receiver says "stop sending" to the sender, it can cause overflow of the sender's transmission queue. Queue-length bounds become a global system problem. > is included in the verification > process, or else the communication stuff is outside of the critical > portion of the code. To be sure the communication stuff should usually be considered less critical than the control part. But today, when time-and-space-isolated partitions are not yet common, they are still part of the same program, thus usually under the same coding and design rules. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .