I think that I used to know this but currently am not sure:

Assuming the a value is passed by reference, is 'Address of a parameter
always the address of the object that is passed as in:

....

type Big_Record is ...

Object : Big_Record;

procedure Proc (Param : in out Big_Record) is
begin
if Param'Address /= Object'Address then
raise Constraint_Error;
end if;
end;

begin
Proc(Object);
...

Also, does parameter mode (in, in out, out) make any difference?

I'm not a compiler builder, but pass by referene has always meant, you access the parameter object directly. And of course, the parameter mode does not (and must not) have any influence on the parameter passing method.
You can force pass by ref by adding access to the parameter.
In most cases, passing method is of no interest, compiler makes the correct choice. RM is silent on most types about this.
Tagged types and limited types are always PbR.

Le 20/04/2021 à 17:10, Vincent Marciante a écrit :
> I think that I used to know this but currently am not sure:
>
> Assuming the a value is passed by reference, is 'Address of a parameter
> always the address of the object that is passed as in:
>
> ...
>
> type Big_Record is ...
>
> Object : Big_Record;
>
> procedure Proc (Param : in out Big_Record) is
> begin
> if Param'Address /= Object'Address then
> raise Constraint_Error;
> end if;
> end;
>
> begin
> Proc(Object);
> ...
>
As usual, the real question is "why do you need that?"

If you want to check whether a parameter IS a certain variable, use
Param'Has_Same_Storage(Object). If you want to check whether variables
have a part in common, use Param'Overlaps_Storage (Object).
See 13.3 (73.1/3 .. 73.10/3)

--
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52
https://www.adalog.fr

On Tuesday, April 20, 2021 at 12:35:07 PM UTC-4, J-P. Rosen wrote:
> Le 20/04/2021 à 17:10, Vincent Marciante a écrit :
> > I think that I used to know this but currently am not sure:
> >
> > Assuming the a value is passed by reference, is 'Address of a parameter
> > always the address of the object that is passed as in:
> >
> > ...
> >
> > type Big_Record is ...
> >
> > Object : Big_Record;
> >
> > procedure Proc (Param : in out Big_Record) is
> > begin
> > if Param'Address /= Object'Address then
> > raise Constraint_Error;
> > end if;
> > end;
> >
> > begin
> > Proc(Object);
> > ...
> >
> As usual, the real question is "why do you need that?"
>
> If you want to check whether a parameter IS a certain variable, use
> Param'Has_Same_Storage(Object). If you want to check whether variables
> have a part in common, use Param'Overlaps_Storage (Object).
> See 13.3 (73.1/3 .. 73.10/3)
>
>
> --
> J-P. Rosen
> Adalog
> 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
> Tel: +33 1 45 29 21 52
> https://www.adalog.fr

I actually do not want to test that: I just wrote that as an attempt to
make explicit want I was asking and what I did not expect (exception).
I am really working with old code where I am moving some logic out
from within a package body that contains the "address'd" variable to
an unassociated package that defines the "Big_Record" type and I
wanted to be sure that passing it as a parameter would (always) have
the same behavior with the variable being passed as a parameter.

On 4/20/21 5:52 PM, AdaMagica wrote:
> You can force pass by ref by adding access to the parameter.

I hope you meant to say "aliased", not "access". "Access" does not force pass by
reference; it forces pass by copy because access types are always passed by copy.

--
Jeff Carter
"I'm particularly glad that these lovely children were
here today to hear that speech. Not only was it authentic
frontier gibberish, it expressed a courage little seen
in this day and age."
Blazing Saddles
88

On 2021-04-20 18:52, AdaMagica wrote:

> You can force pass by ref by adding access to the parameter.

Or adding "aliased", which does not force one to use 'Access in the call.

"Vincent Marciante" <vincent.marciante@l3harris.com> wrote in message
news:13f272e5-14a3-45cb-abf2-3d9f5a98f715n@googlegroups.com...
On Tuesday, April 20, 2021 at 12:35:07 PM UTC-4, J-P. Rosen wrote:
> Le 20/04/2021 � 17:10, Vincent Marciante a �crit :
> > I think that I used to know this but currently am not sure:
> >
> > Assuming the a value is passed by reference,

You can only assume that for by-reference types (see RM 6.3(4-9)).

Your example just used an unspecified record type. For any old record type
(not in that list), the parameter passing mechanism is unspecified. Which
means a compiler can pass by copy if it wants (it *probably* will pass by
reference, but that's not the same as being required to do so). And if it
does, your assumption doesn't hold.

For instance, for a small record like:
type Screen_Position is
X, Y : System.Byte; -- A Janus/Adaism, but I think you get the point.
end record;
it might make more sense to pass by copy (especially if registers are used
in the usual calling convention).

Randy.

On Tuesday, April 20, 2021 at 3:25:25 PM UTC-4, Randy Brukardt wrote:
> "Vincent Marciante" wrote in message
> On Tuesday, April 20, 2021 at 12:35:07 PM UTC-4, J-P. Rosen wrote:
> > Le 20/04/2021 à 17:10, Vincent Marciante a écrit :
> > > I think that I used to know this but currently am not sure:
> > >
> > > Assuming the a value is passed by reference,
> You can only assume that for by-reference types (see RM 6.3(4-9)).
>
> Your example just used an unspecified record type. For any old record type
> (not in that list), the parameter passing mechanism is unspecified. Which
> means a compiler can pass by copy if it wants (it *probably* will pass by
> reference, but that's not the same as being required to do so). And if it
> does, your assumption doesn't hold.
>
> For instance, for a small record like:
> type Screen_Position is
> X, Y : System.Byte; -- A Janus/Adaism, but I think you get the point.
> end record;
> it might make more sense to pass by copy (especially if registers are used
> in the usual calling convention).
>
> Randy.

Got it (and "no way" that the big record that is in the real code would be passed by copy
but I'll see if specifying it explicitly would not be disruptive). Thanks.

Jeffrey R. Carter schrieb am Dienstag, 20. April 2021 um 19:32:08 UTC+2:
> On 4/20/21 5:52 PM, AdaMagica wrote:
> > You can force pass by ref by adding access to the parameter.
> I hope you meant to say "aliased", not "access". "Access" does not force pass by
> reference; it forces pass by copy because access types are always passed by copy.

Of course you're right. Sorry for the confusion.
The access value is passed by copy, if you then dereference, you get at the actual object.
I reall meant alias.

On Tuesday, April 20, 2021 at 11:18:24 AM UTC-6, Vincent Marciante wrote:
> I actually do not want to test that: I just wrote that as an attempt to
> make explicit want I was asking and what I did not expect (exception).
> I am really working with old code where I am moving some logic out
> from within a package body that contains the "address'd" variable to
> an unassociated package that defines the "Big_Record" type and I
> wanted to be sure that passing it as a parameter would (always) have
> the same behavior with the variable being passed as a parameter.
Why not use genreics?

Generic
Object : in out Big_Record;
Procedure Do_Something;

Remember, also, that you can supply subprograms in the formal parameters.

On Wednesday, April 21, 2021 at 4:17:43 PM UTC-4, Shark8 wrote:
> On Tuesday, April 20, 2021 at 11:18:24 AM UTC-6, Vincent Marciante wrote:
> > I actually do not want to test that: I just wrote that as an attempt to
> > make explicit want I was asking and what I did not expect (exception).
> > I am really working with old code where I am moving some logic out
> > from within a package body that contains the "address'd" variable to
> > an unassociated package that defines the "Big_Record" type and I
> > wanted to be sure that passing it as a parameter would (always) have
> > the same behavior with the variable being passed as a parameter.
> Why not use genreics?
>
> Generic
> Object : in out Big_Record;
> Procedure Do_Something;
>
> Remember, also, that you can supply subprograms in the formal parameters.

Using a method that ensure that the parameter will be passed by reference
is all that I need. Generics would just add one extra step - the instantiation.

"Vincent Marciante" <vincent.marciante@l3harris.com> wrote in message
news:07a090e1-85b4-4ebb-a093-dcda57b56579n@googlegroups.com...
>Got it (and "no way" that the big record that is in the real code would be
>passed by copy
>but I'll see if specifying it explicitly would not be disruptive). Thanks.

Careful about assumptions, if you want the code to be portable. At one
point, Janus/Ada would pass pretty anything by copy to parameters of certain
generic types. (We got rid of that in the Ada 95 version because of the need
to deal with "aliased" components, but the cost is that one needs to use a
thunk to access anything of most generic formal types in a generic body.
[Janus/Ada still uses universal generic sharing.])

Randy.

On 2021-04-24 4:25, Randy Brukardt wrote:
> "Vincent Marciante" <vincent.marciante@l3harris.com> wrote in message
> news:07a090e1-85b4-4ebb-a093-dcda57b56579n@googlegroups.com...
>> Got it (and "no way" that the big record that is in the real code would be
>> passed by copy
>> but I'll see if specifying it explicitly would not be disruptive). Thanks.
>
> Careful about assumptions, if you want the code to be portable.

Seconded.

Long ago I was working with early "public" GNAT versions ("gnatp") on a
certain program. After we upgraded to the next version of gnatp (I think
around version 3.12) our program started failing with Storage_Error.
Turned out that the GNAT developers had decided that this gnatp version
would pass all record-type parameters by value, "to be more like C"
(IIRC Robert Dewar was said to be the origin of that idea, but that may
be a calumny). And our program had some large record types.

We ended up shipping the program with the advice to use a 10 MiB stack
allocation -- but it worked (it did not have any real-time requirements).

As a positive, the value-passing gnatp version made us discover a couple
of unintended parameter-vs-global aliasing issues that had been hidden
when all records were passed by reference.

The very next gnatp version returned to pass-by-reference for
record-type objects. It seems there had been some negative user
feed-back :-)

> At one point, Janus/Ada would pass pretty anything by copy to
> parameters of certain generic types. (We got rid of that in the Ada
> 95 version because of the need to deal with "aliased" components, but
> the cost is that one needs to use a thunk to access anything of most
> generic formal types in a generic body. [Janus/Ada still uses
> universal generic sharing.])
> Randy.