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!feeder.eternal-september.org!2.eu.feeder.erje.net!feeder.erje.net!2.us.feeder.erje.net!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!nntp.earthlink.com!news.earthlink.com.POSTED!not-for-mail NNTP-Posting-Date: Sun, 14 May 2017 17:20:14 -0500 From: Dennis Lee Bieber Newsgroups: comp.lang.ada Subject: Re: Rust's temporal safety for Ada/SPARK Date: Sun, 14 May 2017 18:20:15 -0400 Organization: IISS Elusive Unicorn Message-ID: References: <1c0e2c7c-4fd6-43d1-9848-f03e1a72bcb3@googlegroups.com> User-Agent: ForteAgent/8.00.32.1272 X-No-Archive: YES MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Usenet-Provider: http://www.giganews.com NNTP-Posting-Host: 108.68.179.137 X-Trace: sv3-6OMmT1+gKuIQZbfkgrK7WZabJDaGLnCBU2yiFArfostW8c4CKKpo/NZaG3k2YJF1bgXoqjGsfMghyjf!FsIzUQA60Ewgmpx0goExv4VpgKZ2RsNr2MCzVt7UnK5sa2QjNmBfIq5dyb6b6LVr13ANqPpEUO0H!QTyLmwCX8yseWqX+iXRkk12JnaDc X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 2517 Xref: news.eternal-september.org comp.lang.ada:46784 Date: 2017-05-14T18:20:15-04:00 List-Id: On Sun, 14 May 2017 22:59:55 +0300, Niklas Holsti declaimed the following: >Even in applications where heap allocation is forbidden, there are >usually some dynamically allocated resources -- elements of "resource >pools" such as message buffers -- with the corresponding >application-defined "reference" data types, and the same problems of >managing allocations over time. I don't know if Rust's memory-management >scheme extends to such non-heap "references, however. My last employment system environment came down to allocation only during the initialization of the application, no allocation permitted once the application transitioned to "running", an NO DEALLOCATION ALLOWED. That left only two potential erroneous situations: duplicating a reference such that two parts of the code were independently accessing the same memory, and the converse, "dropping" a reference such that the memory could no longer be accessed. The latter being the less likely to get out into the wild, as running out of a buffers from a pool would tend to be found in testing, given the limited number of buffers available. -- Wulfraed Dennis Lee Bieber AF6VN wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/