Re: API design problem - buffer scatter I/O

[Robert A Duff <bobduff@shell01.TheWorld.com>]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

> On 22 Lis, 23:16, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
>
>> There is no such concept as "fat pointer" or "thin pointer" in Ada!
>
> I understand that the distinction is to make the reader aware that
> some access values need to carry over the bounds whereas some other
> don't.

Perhaps, but I still find that wiki page confusing.

When you have an access to unconstrained array, the implementation
has to arrange some way to find the bounds -- e.g. if the program
says X.all'Last.  Fat pointers are one way to do that, but not the
only one.  GNAT can use either fat pointers or thin pointers
(for access to unconstrained array) -- it's a programmer choice.

And (I claim) this has no place in a description of the semantics
of the language.  It's an implementation detail.

>> It does point to a real problem, though. �Given your above declarations,
>> you might want to say:
>>
>> � � This_Buf : aliased Stream_Element_Array (1..10);
>> � � That_Buf : aliased Stream_Element_Array (1..10_000);
>>
>> � � Scatter_Input_Data ((This_Buf'Access, That_Buf'Access)); -- wrong!
>>
>> but that's illegal. �You can do this instead:
>>
>> � � This_Buf : aliased Stream_Element_Array := (1..10 => <>);
>> � � That_Buf : aliased Stream_Element_Array := (1..10_000 => <>);
>>
>> � � Scatter_Input_Data ((This_Buf'Access, That_Buf'Access)); -- OK
>
> Yes, I have noticed that. Not a big issue for the user (all bounds can
> be still variable at run-time), but highlights some part of the
> language that is maybe unnecessarily rigid.

Perhaps.  If the above "wrong!" thing were allowed, there would be a
slight efficiency hit.  That (efficiency) is the _only_ reason for
this rule.  Maybe it was a mistake.

>> Another workaround is to wrap the Stream_Element_Array in a record
>
> Good idea.
>
> Still, in both of these solutions, there is a problem of scope - the
> type of access value is defined by the library API (well, at the
> library level), whereas user-provided buffers are likely to be defined
> locally.

Right.  You have to use Local'Unchecked_Access, and take care to avoid
dangling pointers.

> This brings the old problem of having an access value of global type
> pointing to local object (GNAT says: "non-local pointer cannot point
> to local object").
> Unrestricted_Access hides the issue,...

Don't use Unrestricted_Access here (which is not standard Ada).
Use Unchecked_Access.  Yes, it's dangerous -- you need to ensure that
Scatter_Input_Data doesn't save pointers to locals into globals,
along with comments explaining what clients can do.
There's no better solution.

>... but I know from Rationale that
> anonymous access types were supposed to solve some of that mess.

"Supposed to", maybe.  But they don't.  I suggest you stay away from
them.  They are confusing, and don't help here.

>...The
> problem is that I cannot find any way to benefit from them.

Right.  Neither can I.
[snipped discussion of failed attempts to use anonymous
access types]

By the way, ARG is discussing some ideas for improving anonymous
access types.  My own opinion is that this will not work out,
but others do not agree with me.

- Bob