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!mx02.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: Ada.Strings.Fixed.Count raises Storage_Error Date: Wed, 29 Jun 2016 11:15:23 +0300 Organization: Tidorum Ltd Message-ID: References: <57346ac8$0$4570$426a74cc@news.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net 3evYq711YZPUiVUNrYvaKAhkczejmveD7TfQpmDMSVJGy/n7nl Cancel-Lock: sha1:TPX0qsDClkL3vaFW/xnMjrVfK2Q= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 In-Reply-To: Xref: news.eternal-september.org comp.lang.ada:30964 Date: 2016-06-29T11:15:23+03:00 List-Id: On 16-06-27 02:23 , rieachus@comcast.net wrote: > On Sunday, June 26, 2016 at 5:18:49 PM UTC-4, Victor Porton wrote: > >> Let's decide who of us will report the bug, so that the report >> won't happen to be duplicate? > > How about no one reports this non-existent error? There are IMO three bugs/errors here: 1. That AdaCore delivers a default RTS compiled with checks off, without having ensured (by CodePeer &c) that checks cannot fail. This bug is similar to AdaCore's original choice to have overflow checks disabled by default (as I understand it, they are now enabled by default) but is harder to work around for the average GNAT user. I understand that the motivation is performance, but Ada is about correctness and reliability, not about getting wrong answers quickly. 2. That an integer overflow manifests itself as a Storage_Error exception, which is misleading. However, an overflow with checks off is erroneous execution, I believe, so perhaps nothing can or should be done about this bug. 3. The coding error in the library function Ada.Strings.Fixed.Count, which is a very common and simple kind of error, and should surely be corrected. > This is a category > of problem that the ARG decided long ago should be considered > pathologies. The original case was a program that checked whether a > task returned by a function was Terminated. I don't see any connection between these problems. Can you give a reference for the "original case", an AI number perhaps? > A string which ends at Integer'Last is either huge enough to raise > Storage_Error anyway, or a clever compiler test that exists only to > make compiler developers lives miserable. Such strings can also occur in tests of application programs, to check that _their_ index arithmetic works without overflows. These test cases may even be required, and automatically generated, to cover boundary values. Writing loop code so that the counter and index arithmetic cannot cause overflow should be normal practice for Ada programmers. If that makes us miserable, we should be doing something else. And today we even have tools like CodePeer that can find such mistakes by static analysis. We make fun of C programs falling over when a coding error causes wrap-around in a loop counter, for example. We expect Ada to be better. > And as Randy pointed out anything is allowed to raise Storage_Error. That Storage_Error is raised here is surely not intentional, but an unexpected and misleading consequence of the erroneous behaviour of the library function. > but in this case (Strings ending at Integer'Last) no > sensible user is going to run into the problem. There are sensible uses of such Strings. If your position is that predefined library subprograms should not be expected to work for a String S with S'Last = Integer'Last, then it would have been a simple matter for the ARG to define String with an index subtype extending only to Integer'Last - 1. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .