Re: copying data between memory locations

[Adam Beneschan <adam@irvine.com>]

On Sep 3, 3:38 am, Martin Krischik <krisc...@users.sourceforge.net>
wrote:
> jef.mangelsch...@gmail.com schrieb:
>
> > In our current design, we have a package that maintains a list of
> > descriptors of various buffers in the application. We don't want to
> > know their datatypes or how to write data into them. We only want to
> > maintain a physical address of them and use that address to directly
> > write data into these buffers (this data comes out incoming packets
> > over the network).
>
> > In C, this is very straightforward and use the address as a pointer
> > and simply copy the packet into the memory location.
>
> straightforward and highly dangerous.
>
> > I can't figure out a way to do this in Ada (at least not Ada83).
>
> You just have not found the right features yet. Suggested reading:
>
> http://en.wikibooks.org/wiki/Ada_Programming/Types/access#Access_vs._...http://en.wikibooks.org/wiki/Ada_Programming/Type_System#Address_conv...http://en.wikibooks.org/wiki/Ada_Programming/Type_System#Overlays
>
> and from the reference manual:
>
> http://www.adaic.com/standards/05rm/html/RM-13-7-2.html#I4643http://www.adaic.com/standards/05rm/html/RM-13-3.html#I4496
>
> As you can see (once you read the articles) you have even got two
> options open and now you are left with choosing the right one ;-).

Unfortunately, most of the features you've referred to are not
available in Ada 83, and the original poster hinted that he needed an
Ada 83 way to accomplish this.

In Ada 83, you'll need to do something like:

   type Byte_Array is array (1 .. Num_Bytes) of Byte;
--or--
   subtype Byte_Array is BYTE_ARRAY_TYPE (1 .. Num_Bytes);
   Dest : Byte_Array;
   for Dest use at Buffer_Details(idx) + Offset;

   Dest := Data;

I don't know what "data" is, but if its type is an unconstrained array
whose length is guaranteed to be Num_Bytes, the above assignment will
work; otherwise you'll need a slice, like

   Dest := Data (Data'First .. Data'First + Num_Bytes - 1);

I also don't know that "Buffer_Details(idx) + Offset" will work.
Probably not.  Someone already pointed out that
System.Storage_Elements is available in Ada 95 (and later) to do this
sort of address arithmetic, but in Ada 83 you have to invent your own
method.  If you know that a System.Address type is represented as just
a simple address whose size is the same as an Integer, then using
Unchecked_Conversion to convert System.Address to an Integer, add
Offset to it, and convert it back to System.Address may be necessary.
If a System.Address is more complicated, you'll need a more
complicated method.  Of course, anything you do is likely to be non-
portable but that's probably not your concern.

I agree with others that trying to deal with addresses directly like
this *may* be evidence of a poor design decision; it's better to try
to see if Ada has nicer features for accomplishing something than to
assume you have to do things the same way you do it in C.  (I've seen
a lot of needlessly horrendous Ada code written by programmers who
still tried to do things the C way.)  I say *may* because we can't say
for sure, without knowing more about your particular problem.  Also,

rant: begin

I'd like to gripe about those who respond to a question like this by
telling them how they should have designed their program in the first
place, rather than by answering their question.  We do want Ada to be
used in the Real World, after all (we do, right?), and the Real World
can be messy sometimes---sometimes you have to come up with a quick
solution to cope with a previous poor design decision, because your
customer has a problem and can't wait for you to rewrite a billion
lines of code or whatever to make the design nice and clean and
perfect.  I've had to do ugly things like that.  Ada generally
provides ways to get around problems like this, and this is a strength
of the language rather than a weakness, despite the fact that these
features are things you're better off not using if you don't have to.
Anyway, maybe a better design is feasible in this particular poster's
case and maybe it isn't.  But I'm afraid that being unhelpful could
help scare programmers back to using C.

end rant;

                        -- Adam