Re: S-expression I/O in Ada

[Natasha Kerensikova <lithiumcat@gmail.com>]

On 2010-08-25, Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> wrote:
> On 08/24/2010 04:41 AM, Natasha Kerensikova wrote:
>> Does anybody have an idea about how to solve this issue?
>
> What issue? You haven't demonstrated that a deep copy is a problem anywhere 
> outside your mind. If you implement this and find that actual use exhausts 
> memory or takes longer than the user is willing to wait (~2 sec) then
> you have something to worry about.

Well, if it were about performances I would completely agree with you:
this is way too early in the development process to care about
performances or optimization.

However it is more about security. I guess it's a bad habit from C, but
I can't make a design or write some code without considering how it can
be abused. And I acknowledge the Ada compiler does a lot to free the
programmer from such considerations.

The deep copy won't be a problem for all the real-life cases I've ever
encountered so far, which is still quite a decent amount. However it
requires only one specially-crafted input from a single attacker to
bring the system on its knees (well, honestly I don't know how much an
Ada deep copy costs, but I do know how much a memcpy() costs and I'm
sure Ada deep copy is not cheaper).

> This is called "renaming as body": you implement the declaration with
> a renames 
>
> This requires that both subprograms have the same parameter and result
> type profile.

Thanks a lot for letting me know of the at possibility.

However I'm afraid the type profile is the issue here. Maybe I did it
wrong, but I didn't manage to get to compile any of my attempts at using
a package-provided type as the private implementation of a public type.

And if the public type doesn't match the package-provided type, none of
the package-provided subprograms can be used as publicly exposed
subprograms.

>> I still can't estimate how bad or inelegant
>> or ugly are explicit access. I guess even in Ada they have some niche
>> use, and avoiding expensive copy can be one them, right?
>
> They are needed to implement things like Ada.Containers.Doubly_Linked_Lists.

Yes, and I have the feeling the package I'm trying to write can thought
of as the same level as Ada standard containers: it's just a kind of
branching simply-linked list, with a predefined Element_Type instead of
a generic one.

That's why I came to think using accesses here might be legitimate, but
then again I still don't know how biased I am from my C pointer
juggling past. Hence my asking for external, hopefully less biased,
opinions.

>>     procedure String_To_Atom(S : in String; A : out Atom_Data);
>>     procedure Atom_To_String(A : in Atom_Data; S : out String);
>
> These are only partly specified. What happens if S'Length /= A'Length?

Maybe I should have kept them private.

If the source is shorter than the destination, the destination is
partially filled an everything continues; if the destination is shorter,
an exception is raised.

Should this kind of information be put as comments after the procedure
declaration?

> What happens if Element isn't an Atom?
>
> What happens when Element isn't a List?

Constraint_Error is raised, which felt like the right thing to do. At
first I used to explicitly check the node type, and explicitly raised the
exception, until I discovered that the compiler already does this when
casting the input Node'Class object into Atom or List.



Thanks a lot for your comments (even those I snipped here, have been
read and acknowledged),
Natasha