Re: Gnat 2013 is out!

[Adam Beneschan <adam@irvine.com>]

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).
> 
> > Turned out to be a warning new to GNAT GPL 2013 (also in GCC 4.8.0):  
> > 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"
> 
> You do know that's illegal in some cases in Ada 2012? (A known and intended 
> incompatibility.) I wouldn't be surprised if GNAT is putting out a warning 
> in other modes in order to reduce the incompatibility. (Or, perhaps, they're 
> using the code they had to write to make the Ada 2012 check to issue 
> 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 "distinct access paths".  A subprogram with two OUT parameters could set a component in one OUT parameter, and then later try reading it back; if it's written 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 variable.  The compiler would allocate a temporary object (and a separate one for 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 records, though.  

Now that we have preconditions, and Has_Same_Storage and Overlap_Storage attributes [this is why I was looking into those! :-)], in theory it should be possible for programmers to use this any time there are two not-by-copy parameters (not both IN parameters) that shouldn't overlap.  Then it would be 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 body of the subprogram is able to handle overlap.  But that doesn't seem feasible to me, since I think in *most* cases, the intent of subprograms with OUT 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 burden.

I think the best practice here is: don't ever call a subprogram with overlapping parameters (if they're not both IN parameters), unless there is some comment on the subprogram declaration saying that it's OK.  (Or an implementation-defined pragma.)

                             -- Adam