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: Sat, 12 May 2018 22:04:32 +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> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net i6okmJlSwBr0Upb0bG6MMQjK8CZQuYIgASCmf1hNmpFzr8gb3f Cancel-Lock: sha1:U3iMx89jWgW4QW2YIHWgu5xhQeY= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: Xref: reader02.eternal-september.org comp.lang.ada:52323 Date: 2018-05-12T22:04:32+03:00 List-Id: On 18-05-12 18:45 , Dennis Lee Bieber wrote: > On Sat, 12 May 2018 12:29:05 +0300, Niklas Holsti > declaimed the following: > >> In my view, if your system has a UART and accumulates incoming >> characters into a line buffer until in comes a CR to end the line, you >> are allocating space dynamically in the buffer for each incoming >> character. Now that is an extreme example, but I hope it shows what I am >> driving at: in principle, if the program uses up space, when needed, in >> any "memory" that can fill up, it is allocating that space dynamically, >> even if this "memory" is not the system heap. >> > > By that interpretation, any program using "static arrays" with an index > tracking "current location" can be considered to be doing "dynamic > allocation". Yes, if the static array can become full in a way that prevents the program from continuing normally. As I remember, this discussion started from the common prohibition of "dynamic memory allocation" in critical high-reliability SW. It is probably true that the people who establish and enforce such prohibitions mean "dynamic allocation from the system heap", but IMO there is a spectrum of "dynamic memory allocation" mechanisms with different levels of determinism. The spectrum starts with the system heap as the least deterministic mechanism, passes through "application heaps" or application-defined storage pools with more or less dedication to certain types of application objects, and ends at the level of the (admittedly extreme) example of the UART buffer, which is very deterministic in the sense that it contains exactly one type of object (an UART character), and one can describe, pretty easily and exactly, the case(s) in which it might overflow and what the program should do in those cases. Anyway, if you are developing SW that "shall not allocate memory dynamically", I'm 99% certain that you will satisfy your product assurance group if you show that your SW contains no allocators ("new sometype") -- even if your SW uses its own memory pools logically similar to the system heap. No product assurance person would consider the UART buffer as a case of dynamic memory allocation. 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? And if some risk remains in the mechanism that I would like to use for the SW, what should/must I do to defend against that risk? -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .