'Read for pointers

'Read for pointers

[Ted Dennison]

I've seen it suggested in several places to handle Stream writing of
pointers by writing what the pointer points to instead. That's simple
enough.

But say I want to make this automatic. Lets say I have a pointer type
declared thusly:

package Example is
   type Handle is private;

   ...
private

   type Instance;

   type Handle is access all Instance;

end Example;

The user doesn't even really know or care that Handle is really a
pointer. But they may need to do stream I/O with it.

The obvious solution is to create my own 'Write and 'Read routines for
Handle. But there's a problem. Following is the profile for 'Read:

   procedure Read
     (Stream : access Ada.Streams.Root_Stream_Type'Class;
      Item   : out    Handle
     );
   for Handle'Read use Read;

The problem is that Item is an *out* parameter. That means I won't have
acces to the pointer's old value inside Read. There's no way I can put
the newly read data from the stream into the Instance that Handle
currently points to!

I see two possible solutions to this:
  1)  Redefine "Handle" to be a record with a single pointer field for
Instance in it.
  2)  Provide my own Read routine with an "in" or "in out" parameter for
Handle, then warn the user with copious comments not to use 'Read. This
may involve them writing their own 'Read for their compound objects to
prevent their users from transitivly calling Handle'Read.

I'm not too fond of either solution. It would have been nice if Read
used "in out" instead. Does anyone have any other solutions?

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: 'Read for pointers

[Pat Rogers]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:8lndgv$1om$1@nnrp1.deja.com...
> I've seen it suggested in several places to handle Stream writing of
> pointers by writing what the pointer points to instead. That's
simple
> enough.
>
> But say I want to make this automatic. Lets say I have a pointer
type
> declared thusly:
>
> package Example is
>    type Handle is private;
>
>    ...
> private
>
>    type Instance;
>
>    type Handle is access all Instance;
>
> end Example;
>
> The user doesn't even really know or care that Handle is really a
> pointer. But they may need to do stream I/O with it.
>
> The obvious solution is to create my own 'Write and 'Read routines
for
> Handle. But there's a problem. Following is the profile for 'Read:
>
>    procedure Read
>      (Stream : access Ada.Streams.Root_Stream_Type'Class;
>       Item   : out    Handle
>      );
>    for Handle'Read use Read;
>
> The problem is that Item is an *out* parameter. That means I won't
have
> acces to the pointer's old value inside Read. There's no way I can
put
> the newly read data from the stream into the Instance that Handle
> currently points to!

Further to my previous post, to the effect that one can indeed read
mode out parameters: the access value of the actual is copied into the
formal, so you get a meaningful value coming in even though the mode
is out. See RM 6.4.1{12,13}

--
Pat Rogers                            Consulting and Training in:
http://www.classwide.com      Deadline Schedulability Analysis
progers@classwide.com        Software Fault Tolerance
(281)648-3165                       Real-Time/OO Languages

Adam ... does not deserve all the credit; much is due to Eve, the
first woman, and Satan, the first consultant.
Mark Twain

Re: 'Read for pointers

[tmoran]

>Further to my previous post, to the effect that one can indeed read
>mode out parameters: the access value of the actual is copied into the
>formal, so you get a meaningful value coming in even though the mode
>is out. See RM 6.4.1{12,13}
So to catch bugs at an early time, given
    type Handle_Type is access ...
    procedure p(x : some_stuff;  Handle : out Handle_Type);
one should
    Handle := null;
    p(y, Handle);
otherwise a supposedly new object at Handle.all may actually be
an old object.  That must be fun to debug.

Re: 'Read for pointers

[Pat Rogers]

<tmoran@bix.com> wrote in message
news:YEJf5.49$LV1.69164@news.pacbell.net...
> >Further to my previous post, to the effect that one can indeed read
> >mode out parameters: the access value of the actual is copied into
the
> >formal, so you get a meaningful value coming in even though the
mode
> >is out. See RM 6.4.1{12,13}
> So to catch bugs at an early time, given
>     type Handle_Type is access ...
>     procedure p(x : some_stuff;  Handle : out Handle_Type);
> one should
>     Handle := null;
>     p(y, Handle);
> otherwise a supposedly new object at Handle.all may actually be
> an old object.  That must be fun to debug.

I'm not sure I see your point, given the context.  The variable
Handle, used as the actual to the call to P, would initially have the
null value (absent any explicit initialization) automatically.  So the
value copied in is still meaningful, even if never assigned prior to
the call.

--
Pat Rogers                            Consulting and Training in:
http://www.classwide.com      Deadline Schedulability Analysis
progers@classwide.com        Software Fault Tolerance
(281)648-3165                       Real-Time/OO Languages

Adam ... does not deserve all the credit; much is due to Eve, the
first woman, and Satan, the first consultant.
Mark Twain

Re: 'Read for pointers

[tmoran]

>I'm not sure I see your point, given the context.
  The "out" parameter is not set to null so if the procedure has a bug
so that it isn't set, it will retain its previous value.  Any
uninitialized variable bug can be hard to find.  But a pointer is
especially hard, and in fact most pointers are automatically
initialized to null, which helps a lot.  Here the "out" parameter
pointer in fact points to an internally correct data structure, just
the wrong one, or one that might have been deallocated.  I think such
a bug might take a while to track down.

Re: 'Read for pointers

[Pat Rogers]

<tmoran@bix.com> wrote in message
news:xRLf5.61$M35.39742@news.pacbell.net...
> >I'm not sure I see your point, given the context.
>   The "out" parameter is not set to null so if the procedure has a
bug
> so that it isn't set, it will retain its previous value.  Any
> uninitialized variable bug can be hard to find.  But a pointer is
> especially hard, and in fact most pointers are automatically
> initialized to null, which helps a lot.  Here the "out" parameter
> pointer in fact points to an internally correct data structure, just
> the wrong one, or one that might have been deallocated.  I think
such
> a bug might take a while to track down.

Having parsed the above a couple of times, let me try to restate what
you're saying, just  to be sure I understand it.  What I believe
you're saying -- and if so I agree with it (which is why I question my
understanding of it:) -- is this: Given that the value of the actual
is copied in for an access type formal parameter of mode out, if the
subprogram has a bug such that the formal is not updated then the
actual will retain the old value, and this would be a hard bug to
find.  If that's what you mean I agree, but it is preferable to
copying back junk, which can certainly happen with by-copy types other
than access types.  At least we don't go off into the weeds when
dereferencing the pointer.

--
Pat Rogers                            Consulting and Training in:
http://www.classwide.com      Deadline Schedulability Analysis
progers@classwide.com        Software Fault Tolerance
(281)648-3165                       Real-Time/OO Languages

Adam ... does not deserve all the credit; much is due to Eve, the
first woman, and Satan, the first consultant.
Mark Twain

Re: 'Read for pointers

[Ted Dennison]

In article <lZIf5.190$wE4.35361@nnrp3.sbc.net>,
  "Pat Rogers" <progers@NOclasswideSPAM.com> wrote:

> "Ted Dennison" <dennison@telepath.com> wrote in message
> news:8lndgv$1om$1@nnrp1.deja.com...
> > The problem is that Item is an *out* parameter. That means I won't
> > have acces to the pointer's old value inside Read. There's no way I

> Further to my previous post, to the effect that one can indeed read
> mode out parameters: the access value of the actual is copied into the
> formal, so you get a meaningful value coming in even though the mode
> is out. See RM 6.4.1{12,13}

Wow. That's one I would not have guessed. So there's effectively no
difference between "out" and "in out" for access types, composite types
with discriminants, or record types with default field values? %-}

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: 'Read for pointers

[Pat Rogers]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:8lpeog$gvc$1@nnrp1.deja.com...
> In article <lZIf5.190$wE4.35361@nnrp3.sbc.net>,
>   "Pat Rogers" <progers@NOclasswideSPAM.com> wrote:
>
> > "Ted Dennison" <dennison@telepath.com> wrote in message
> > news:8lndgv$1om$1@nnrp1.deja.com...
> > > The problem is that Item is an *out* parameter. That means I
won't
> > > have acces to the pointer's old value inside Read. There's no
way I
>
> > Further to my previous post, to the effect that one can indeed
read
> > mode out parameters: the access value of the actual is copied into
the
> > formal, so you get a meaningful value coming in even though the
mode
> > is out. See RM 6.4.1{12,13}
>
> Wow. That's one I would not have guessed. So there's effectively no
> difference between "out" and "in out" for access types, composite
types
> with discriminants, or record types with default field values? %-}

As long as the latter two happen to be passed by copy (access types
always are).

--
Pat Rogers                            Consulting and Training in:
http://www.classwide.com      Deadline Schedulability Analysis
progers@classwide.com        Software Fault Tolerance
(281)648-3165                       Real-Time/OO Languages

Adam ... does not deserve all the credit; much is due to Eve, the
first woman, and Satan, the first consultant.
Mark Twain

Re: 'Read for pointers

[Ted Dennison]

In article <HVXf5.612$wE4.155736@nnrp3.sbc.net>,
  "Pat Rogers" <progers@NOclasswideSPAM.com> wrote:
> "Ted Dennison" <dennison@telepath.com> wrote in message
> news:8lpeog$gvc$1@nnrp1.deja.com...
> > Wow. That's one I would not have guessed. So there's effectively no
> > difference between "out" and "in out" for access types, composite
> types
> > with discriminants, or record types with default field values? %-}
>
> As long as the latter two happen to be passed by copy (access types
> always are).

But if they aren't passed by copy, then they have to be passed by
reference, right? In that case there would *also* be no difference.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: 'Read for pointers

[Pat Rogers]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:8lpo5p$os0$1@nnrp1.deja.com...
> In article <HVXf5.612$wE4.155736@nnrp3.sbc.net>,
>   "Pat Rogers" <progers@NOclasswideSPAM.com> wrote:
> > "Ted Dennison" <dennison@telepath.com> wrote in message
> > news:8lpeog$gvc$1@nnrp1.deja.com...
> > > Wow. That's one I would not have guessed. So there's effectively
no
> > > difference between "out" and "in out" for access types,
composite
> > types
> > > with discriminants, or record types with default field values?
%-}
> >
> > As long as the latter two happen to be passed by copy (access
types
> > always are).
>
> But if they aren't passed by copy, then they have to be passed by
> reference, right? In that case there would *also* be no difference.

Yeah, good point.

--
Pat Rogers                            Consulting and Training in:
http://www.classwide.com      Deadline Schedulability Analysis
progers@classwide.com        Software Fault Tolerance
(281)648-3165                       Real-Time/OO Languages

Adam ... does not deserve all the credit; much is due to Eve, the
first woman, and Satan, the first consultant.
Mark Twain

Re: 'Read for pointers

[Pat Rogers]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:8lndgv$1om$1@nnrp1.deja.com...
> I've seen it suggested in several places to handle Stream writing of
> pointers by writing what the pointer points to instead. That's
simple
> enough.
>
> But say I want to make this automatic. Lets say I have a pointer
type
> declared thusly:
>
> package Example is
>    type Handle is private;
>
>    ...
> private
>
>    type Instance;
>
>    type Handle is access all Instance;
>
> end Example;
>
> The user doesn't even really know or care that Handle is really a
> pointer. But they may need to do stream I/O with it.
>
> The obvious solution is to create my own 'Write and 'Read routines
for
> Handle. But there's a problem. Following is the profile for 'Read:
>
>    procedure Read
>      (Stream : access Ada.Streams.Root_Stream_Type'Class;
>       Item   : out    Handle
>      );
>    for Handle'Read use Read;
>
> The problem is that Item is an *out* parameter. That means I won't
have
> acces to the pointer's old value inside Read. There's no way I can
put
> the newly read data from the stream into the Instance that Handle
> currently points to!

You can read mode out parameters in Ada 95 (unlike Ada 83).  (Am I
missing something?)

--
Pat Rogers                            Consulting and Training in:
http://www.classwide.com      Deadline Schedulability Analysis
progers@classwide.com        Software Fault Tolerance
(281)648-3165                       Real-Time/OO Languages

Adam ... does not deserve all the credit; much is due to Eve, the
first woman, and Satan, the first consultant.
Mark Twain

Re: 'Read for pointers

[Stephen Leake]

"Pat Rogers" <progers@NOclasswideSPAM.com> writes:

> "Ted Dennison" <dennison@telepath.com> wrote in message
> news:8lndgv$1om$1@nnrp1.deja.com...

> > package Example is
> >    type Handle is private;
> >
> >    ...
> > private
> >
> >    type Instance;
> >
> >    type Handle is access all Instance;
> >
> > end Example;
> >
> > But there's a problem. Following is the profile for 'Read:
> >
> >    procedure Read
> >      (Stream : access Ada.Streams.Root_Stream_Type'Class;
> >       Item   : out    Handle
> >      );
> >    for Handle'Read use Read;
> >
> > The problem is that Item is an *out* parameter. That means I won't
> have
> > acces to the pointer's old value inside Read.
> 
> You can read mode out parameters in Ada 95 (unlike Ada 83).  (Am I
> missing something?)

Yes, you are missing something.

Suppose the user writes:

My_Handle : Handle;

(somehow, My_Handle is given some value)

Read (Stream, My_Handle);

The value of My_Handle is _not_ copied to Item at the procedure call.
That only happens for "in" or "in out" parameters, not "out"
parameters.

Inside the body of Read, you can indeed do something like:

Foo := Item;

This allows refering to a previously assigned Item. It does _not_
provide access to the user's value My_Handle.

-- 
-- Stephe

Re: 'Read for pointers

[tmoran]

>The value of My_Handle is _not_ copied to Item at the procedure call.
>That only happens for "in" or "in out" parameters, not "out" parameters.

with Ada.Streams,
     Ada.Text_IO,
     Ada.Text_IO.Text_Streams;
procedure Test is
  type Instance is new Integer;

  type Handle is access all Instance;

  procedure Read
    (Stream : access Ada.Streams.Root_Stream_Type'Class;
     Item   : out    Handle
    );
  for Handle'Read use Read;

  procedure Read
    (Stream : access Ada.Streams.Root_Stream_Type'Class;
     Item   : out    Handle
    ) is
  begin
    Item.all := 2;
    Item := new Instance;
    Item.all := 3;
  end Read;

  Dummy_File : Ada.Text_IO.File_Type;

  Dummy_Stream_Access : Ada.Text_IO.Text_Streams.Stream_Access;

  P, Saved_P : Handle;

begin

  Ada.Text_IO.Open(Dummy_File, Ada.Text_IO.In_File, "dummy");
  Dummy_Stream_Access := Ada.Text_IO.Text_Streams.Stream(Dummy_File);

  P := new Instance;
  P.all := 1;
  Saved_P := P;
  Ada.Text_IO.Put_Line("P.all=" & Instance'image(P.all)
                       & " Saved_P.all=" & Instance'image(Saved_P.all));
  Ada.Text_IO.Put_Line("Handle'Read(Dummy_Stream_Access, P);");
  Handle'Read(Dummy_Stream_Access, P);
  Ada.Text_IO.Put_Line("P.all=" & Instance'image(P.all)
                       & " Saved_P.all=" & Instance'image(Saved_P.all));
  Ada.Text_IO.Close(Dummy_File);

end Test;

produces:

P.all= 1 Saved_P.all= 1
Handle'Read(Dummy_Stream_Access, P);
P.all= 3 Saved_P.all= 2

So Handle'Read not only returned a P to a new Instance with P.all=3,
but it also modified the instance previously pointed to by P,
setting Saved_P.all=2.
  Also, if, due to an error, it hadn't done
    Item := new Instance;
then in fact P would still point to the same thing as Saved_P, to
the eventual surprise of the programmer.

Re: 'Read for pointers

[Pat Rogers]

"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:uaef1lxlw.fsf@gsfc.nasa.gov...
> "Pat Rogers" <progers@NOclasswideSPAM.com> writes:
>
> > "Ted Dennison" <dennison@telepath.com> wrote in message
> > news:8lndgv$1om$1@nnrp1.deja.com...
>
> > > package Example is
> > >    type Handle is private;
> > >
> > >    ...
> > > private
> > >
> > >    type Instance;
> > >
> > >    type Handle is access all Instance;
> > >
> > > end Example;
> > >
> > > But there's a problem. Following is the profile for 'Read:
> > >
> > >    procedure Read
> > >      (Stream : access Ada.Streams.Root_Stream_Type'Class;
> > >       Item   : out    Handle
> > >      );
> > >    for Handle'Read use Read;
> > >
> > > The problem is that Item is an *out* parameter. That means I
won't
> > have
> > > acces to the pointer's old value inside Read.
> >
> > You can read mode out parameters in Ada 95 (unlike Ada 83).  (Am I
> > missing something?)
>
> Yes, you are missing something.
>
> Suppose the user writes:
>
> My_Handle : Handle;
>
> (somehow, My_Handle is given some value)
>
> Read (Stream, My_Handle);
>
> The value of My_Handle is _not_ copied to Item at the procedure
call.
> That only happens for "in" or "in out" parameters, not "out"
> parameters.

Have a look at RM 6.4.1{12,13} for a surprise.

--
Pat Rogers                            Consulting and Training in:
http://www.classwide.com      Deadline Schedulability Analysis
progers@classwide.com        Software Fault Tolerance
(281)648-3165                       Real-Time/OO Languages

Adam ... does not deserve all the credit; much is due to Eve, the
first woman, and Satan, the first consultant.
Mark Twain

Re: 'Read for pointers

[Stephen Leake]

"Pat Rogers" <progers@NOclasswideSPAM.com> writes:

> "Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
> news:uaef1lxlw.fsf@gsfc.nasa.gov...
> > Suppose the user writes:
> >
> > My_Handle : Handle;
> >
> > (somehow, My_Handle is given some value)
> >
> > Read (Stream, My_Handle);
> >
> > The value of My_Handle is _not_ copied to Item at the procedure
> call.
> > That only happens for "in" or "in out" parameters, not "out"
> > parameters.
> 
> Have a look at RM 6.4.1{12,13} for a surprise.

I stand corrected. I guess the Ada designers were trying to prevent
garbage pointers. I think I'd prefer the standard "initialized to
null" behavior here, for consistency. 

I guess it's easy enough to remember that "out" is the same as "in
out" for access types, and composite types with discriminants.

On further thought, I can't think of a time when this behavior is
actively bad; it's just not what I thought the rules were.

-- 
-- Stephe

Re: 'Read for pointers

[Robert A Duff]

Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:

> I stand corrected. I guess the Ada designers were trying to prevent
> garbage pointers. I think I'd prefer the standard "initialized to
> null" behavior here, for consistency. 

I kind of agree.  But suppose you pass something as an 'out' parameter,
and under some conditions, the called procedure does not assign into
it.  Do you really want the actual to be set to null in that case?
Perhaps so...

- Bob

Re: 'Read for pointers

[Pat Rogers]

"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:uem4awakr.fsf@gsfc.nasa.gov...
> "Pat Rogers" <progers@NOclasswideSPAM.com> writes:
>
> > "Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
> > news:uaef1lxlw.fsf@gsfc.nasa.gov...
> > > Suppose the user writes:
> > >
> > > My_Handle : Handle;
> > >
> > > (somehow, My_Handle is given some value)
> > >
> > > Read (Stream, My_Handle);
> > >
> > > The value of My_Handle is _not_ copied to Item at the procedure
> > call.
> > > That only happens for "in" or "in out" parameters, not "out"
> > > parameters.
> >
> > Have a look at RM 6.4.1{12,13} for a surprise.
>
> I stand corrected. I guess the Ada designers were trying to prevent
> garbage pointers.

That's what the AARM indicates.

> I think I'd prefer the standard "initialized to
> null" behavior here, for consistency.
>
> I guess it's easy enough to remember that "out" is the same as "in
> out" for access types, and composite types with discriminants.
>
> On further thought, I can't think of a time when this behavior is
> actively bad; it's just not what I thought the rules were.

There is, however, an interesting side issue from the part of RM
6.4.1{13} that says no constraint check is done on the incoming value.
Keith Thompson (no, the other Keith:) submitted a question and this
bit of code that led to AI95-00110:

   with Ada.Text_IO; use Ada.Text_IO;
   procedure Foo is
      type Pointer is access String;
      P: Pointer := new String'("hello");
      subtype Pointer_10 is Pointer(1 .. 10);

      procedure Proc(Param: out Pointer_10) is
      begin
         Put_Line("Param'Length = " & Integer'Image(Param'Length));
      end Proc;

   begin
      Proc(P);
   end Foo;

Param'Length is clearly 5, which violates the constraint but is not
checked.  (Evaluation of the attribute is another matter.)  The AI is
pretty interesting reading (but then I thought the Implementer's Guide
was interesting too:).

--
Pat Rogers                            Consulting and Training in:
http://www.classwide.com      Deadline Schedulability Analysis
progers@classwide.com        Software Fault Tolerance
(281)648-3165                       Real-Time/OO Languages

Adam ... does not deserve all the credit; much is due to Eve, the
first woman, and Satan, the first consultant.
Mark Twain

Re: 'Read for pointers

[Stephen Leake]

Ted Dennison <dennison@telepath.com> writes:

> I've seen it suggested in several places to handle Stream writing of
> pointers by writing what the pointer points to instead. That's simple
> enough.
> 
> But say I want to make this automatic. Lets say I have a pointer type
> declared thusly:
> 
> package Example is
>    type Handle is private;
> 
>    ...
> private
> 
>    type Instance;
> 
>    type Handle is access all Instance;
> 
> end Example;
> 
> The user doesn't even really know or care that Handle is really a
> pointer. But they may need to do stream I/O with it.
> 
> The obvious solution is to create my own 'Write and 'Read routines for
> Handle. But there's a problem. Following is the profile for 'Read:
> 
>    procedure Read
>      (Stream : access Ada.Streams.Root_Stream_Type'Class;
>       Item   : out    Handle
>      );
>    for Handle'Read use Read;
> 
> The problem is that Item is an *out* parameter. That means I won't have
> acces to the pointer's old value inside Read. There's no way I can put
> the newly read data from the stream into the Instance that Handle
> currently points to!

But if you are reading from a stream, Handle doesn't yet point to
anything! So 'Read needs to allocate an Instance, and set Handle to that.

I guess Handle could point to an Instance that the user no longer
needs; it should be free'd before the new Instance pointer is
assigned. So Handle must be a controlled type. My, this is getting fun
:). 

-- 
-- Stephe

Re: 'Read for pointers

[Ted Dennison]

In article <uhf99lxx4.fsf@gsfc.nasa.gov>,
  Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote:
> Ted Dennison <dennison@telepath.com> writes:
>
> >    type Handle is access all Instance;
> > The problem is that Item is an *out* parameter. That means I won't
> > have acces to the pointer's old value inside Read. There's no way I
> > can put the newly read data from the stream into the Instance that
> > Handle currently points to!
>
> But if you are reading from a stream, Handle doesn't yet point to
> anything! So 'Read needs to allocate an Instance, and set Handle to
> that.

Not true. In my case, Handle points to some working user data that the
client is continually saving off using 'Write, but may in certian
situations want to restore using 'Read. It will *always* have a good
(non-null) value when 'Read is called. I don't care about the previous
value referenced by the pointer, but I defintely do care about the
pointer's value itself.

> needs; it should be free'd before the new Instance pointer is
> assigned. So Handle must be a controlled type. My, this is getting fun
> :).

Bleach! When this is happening, its in a realtime program in a
high-priority task running at 60HZ. You want me to needlessly deallocate
then reallocate the same sized memory at 60Hz?

Uhhh...no.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.