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 X-Received: by 10.224.42.141 with SMTP id s13mr3086670qae.3.1369879311188; Wed, 29 May 2013 19:01:51 -0700 (PDT) X-Received: by 10.50.176.234 with SMTP id cl10mr827396igc.6.1369879311058; Wed, 29 May 2013 19:01:51 -0700 (PDT) Path: border1.nntp.dca3.giganews.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!ch1no2841455qab.0!news-out.google.com!y6ni57245qax.0!nntp.google.com!ch1no2841451qab.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 29 May 2013 19:01:50 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ NNTP-Posting-Host: 66.126.103.122 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <32d94173-533a-471e-95a0-abb73a6cdcc2@googlegroups.com> Subject: Re: Gnat 2013 is out! From: Adam Beneschan Injection-Date: Thu, 30 May 2013 02:01:51 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Original-Bytes: 4158 Xref: number.nntp.dca.giganews.com comp.lang.ada:181765 Date: 2013-05-29T19:01:50-07:00 List-Id: On Wednesday, May 29, 2013 3:39:44 PM UTC-7, Randy Brukardt wrote: > >> But it's reporting a problem with my Ada 2005 Math Extensions .. not > >> so good (for me). >=20 > > Turned out to be a warning new to GNAT GPL 2013 (also in GCC 4.8.0): = =20 > > had a subprogram with two out parameters that designated the same > > object. It was a dummy, though, so no harm done. > > > ada_numerics-generic_arrays.adb:325:28: warning: writable actual for > > "V_L" overlaps with actual for "V_R" >=20 > You do know that's illegal in some cases in Ada 2012? (A known and intend= ed=20 > incompatibility.) I wouldn't be surprised if GNAT is putting out a warnin= g=20 > in other modes in order to reduce the incompatibility. (Or, perhaps, they= 're=20 > using the code they had to write to make the Ada 2012 check to issue=20 > warnings in other cases.) I'd suggest getting rid of any such code. Even before Ada 2012, it's been possible to run into a problem with "distin= ct access paths". A subprogram with two OUT parameters could set a compone= nt in one OUT parameter, and then later try reading it back; if it's writte= n something into the other OUT parameter in between, and if the caller uses= the same actual for both OUT parameters, it could cause a real problem. I= 'm guessing that Simon is calling one of his own routines, so he knows that= won't happen. But it still seems like bad practice. I've always wanted some kind of feature in Ada that would allow a caller to= provide a "dummy" for OUT parameters, without having to declare a new vari= able. The compiler would allocate a temporary object (and a separate one f= or each use of a "dummy") and then discard it after the call. It wouldn't = work well when parameter types are unconstrained array or discriminant reco= rds, though. =20 Now that we have preconditions, and Has_Same_Storage and Overlap_Storage at= tributes [this is why I was looking into those! :-)], in theory it should b= e possible for programmers to use this any time there are two not-by-copy p= arameters (not both IN parameters) that shouldn't overlap. Then it would b= e safe to use the same dummy variable for both (or other overlapping cases)= if there's no such precondition. The programmer has promised that the bod= y of the subprogram is able to handle overlap. But that doesn't seem feasi= ble to me, since I think in *most* cases, the intent of subprograms with OU= T or IN OUT parameters is that they're not expected to overlap. Expecting = a precondition to be added to all such subprograms seems like too big a bur= den. I think the best practice here is: don't ever call a subprogram with overla= pping parameters (if they're not both IN parameters), unless there is some = comment on the subprogram declaration saying that it's OK. (Or an implemen= tation-defined pragma.) -- Adam