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=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,11c630572e59f461 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "(see below)" Newsgroups: comp.lang.ada Subject: Re: Bug in GNAT GPL 2006? Date: Thu, 22 Feb 2007 06:09:44 +0000 Message-ID: References: <1172110443.971020.58150@v33g2000cwv.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Trace: individual.net WvR/6MxUbJYDaF9KR2vl5Q7j7jJgcMltXlx7cgZt0ShgTgaH1O User-Agent: Microsoft-Entourage/11.3.3.061214 Thread-Topic: Bug in GNAT GPL 2006? Thread-Index: AcdWSAvcSoqMWcI7EduXeQARJIjQTg== Xref: g2news2.google.com comp.lang.ada:9396 Date: 2007-02-22T06:09:44+00:00 List-Id: On 22/2/07 02:14, in article 1172110443.971020.58150@v33g2000cwv.googlegroups.com, "Adam Beneschan" wrote: > On Feb 21, 12:19 pm, "Randy Brukardt" wrote: >> Bill Findlay writes: >>> Using GNAT GPL 2006 (20060522-34) I get warning messages >>> like the following when using extended return statements: >> >>> function is_empty (the_table : a_safe_table) return Boolean is >>> begin >>> return result : Boolean do >>> | >>>>>> warning: variable "result" is assigned but never read >> >>> lock_table; >>> result := is_empty(a_basic_table(the_table)); >>> unlock_table; >>> end return; >>> end is_empty; >> >>> I'm inclined to assume that this is a compiler bug, but can >>> anyone more knowledgeable about Ada 200[57] confirm this? >> >> Sure looks like a (harmless) compiler bug to me. It's hard to imagine why >> you would be required to read the result of a function before returning it. > > Looks to me like the compiler is (incorrectly) pretending it's a > normal variable. If you had declared "result : Boolean" before the > "begin", and then assigned it but never used it, I can imagine the > compiler being suspicious that something was perhaps mistyped > somewhere, and displaying a warning. Just a very understandable > implementation bug. Yes, I think so. Extraordinarily, the example given in the Ada 2005 RM has this property. Unfortunately, it is not the only extended return bug in GNAT GPL 2006. Obtaining the value of a defining identifier from a call to another (inlined) function having itself an extended return also fails to compile; giving a nonsensical message at the point of call of the latter. -- Bill Findlay chez blueyonder.co.uk