RE: Variable length raw-byte data

[Robert Dewar <robert_dewar@my-deja.com>]

In article
<B6A1A9B09E52D31183ED00A0C9E0888C469948@nctswashxchg.
nctswash.navy.mil>,
  comp.lang.ada@ada.eu.org wrote:
> -----Original Message-----
> From: Robert Dewar
[mailto:robert_dewar@my-deja.com]
>
> > Of *course* you never allocate an instance of a
> > big array. in fact it is not a bad idea to add
>
> Allocate was a bad choice of words.

It wasn't just a matter of words, you specifically
expressed concern about *allocating* 2 gigs on a
64K machine. Not much ambiguity there!

> But you missed my real point.  My biggest concern
> is that by doing this:
>
>    type byte is mod 2 ** 8;
>
>    type memory is array (natural) of byte;
>    type memptr is access memory;
>
>    myMemory : memptr;
>
> You are telling the compiler that you're pointing
> at a 2GB array and depending on the programmer to
> be "kind" and use the length returned (smacks way
> too much of C/C++),

Please carefully read my response, which in fact
responds to this exact point, there is nothing that
I missed here.

Look at the subject line of this thread "variable
length raw-byte data".

When you are dealing with raw data streams from
a foreign environment, then as I described in my
previous post, there are two cases.

1. You know the length in advance, in this case, of
course you use a constrained array of the right
length. No one argues with that, since it is standard
practice.

2. You do not know the length (my example in my
previous post was a null terminated C string, yes
you can find the length but only AFTER you have
imported the data into the Ada environment, and
the point of the big array approach is to allow
you do to do that importation).

> instead of letting the language tell
> you when you've over-reached your bounds.

The language cannot do magic, there is no way for
you to deal with the null terminated string case in
some automatic language controlled way.

> If you use the constrained sub-type approach, you
> can still use 'first and 'last, and it properly
> sets the state data of the access type.

Yes, of course, that's elementary, and I cannot
imagine ANY Ada programmer not understanding that
of course you use a constrained array if the length
is known in advance.

> Of course the counter-danger is that the programmer
> will inadvertently uncheck convert something using
> the unconstrained type instead of the constrained
> subtype.  Which will likely lead to peculiar
> behavior.

You should avoid using the unconstrained type in
all cases with foreign data, that's my point. Using
unconstrained types leads you into nasty
implementation dependent areas.

> Another approach is to do the following:
>
>   type Byte is mod 2**8;
>
>   buffer_Address : System.Address;
>
> begin
> ...
>   status := Get_C_Stuff(length         => length,
>                         buffer_Address =>
>                                  buffer_Address);
>
>   if (length > 0) then
>     declare
>       type Byte_Array is Byte_Array(1..length) of
>                                              Byte;

----> Well you sure managed to crowd a lot
----> of errors into one line here :-)

1. You cannot have Byte_Array on both sides of a
declaration like this

2. You mean either a new array declaration, or a
derived type declaration, or a subtype declaration.
What you have written is a confused mixture of the
three :-)

Let's assume you meant one of the following

type Byte_Array is new Raw_Storage (1 .. length);
subtype Byte_Array is Raw_Storage (1 ., length);
type Byte_Array is array (1 .. length) of Byte;

It does not matter which, all three are reasonable
choices in context. (I always suggest that people
compile code before they post :-)

>       type Byte_Array_Pointer is access Byte_Array;
>       buffer_Pointer : Byte_Array_Pointer;
>       function To_Buffer_Pointer is
>         new
>Ada.Unchecked_Conversion(System.Address,Byte_Array);

------> ooops, you mean to convert to
        Byte_Array_Ptr here, the above UC is totally
        meaningless. Furthermore, in Ada 95 we should
        always use Address_To_Access conversions.

>     begin
>       buffer_Pointer :=
To_Buffer_Pointer(buffer_Address);
>     end;
>     ...
>   end if;
> ...
>
> This is fine so long as everything you need to do
is
> within the declare block.
>
> Every system I've worked on, both the unconstrained
> subtype and the declare type have worked fine.

Your example above is THE standard way of doing
things. It does not involve any "unconstrained
subtypes" and is likely to work in all
implementations, though, as I emphasize once
again, it is applicable only if, as in this case,
you know the length of the data before you look
at it, which often is not the case.

> The DEC VAX Ada compiler would let you do unchecked
> conversion with unconstrained types

No, that cannot be generally true, there is no
implementation model under which this will always
work. Yes, with a given compiler, SOME cases will
work. Which cases work will depend on the compiler.

> other
> compilers
> require constrained types.  What's the rule in Ada
> 95?
> Does the language require both types to be
> constrained?

The language has nothing to say here, since all it
talks about is interpreting bit strings as a
different type. Whether this "works" or not is
entirely implementation defined.

Even the unchecked conversion of the pointer to
constrained array (the standard solution you present
above, that is familiar to us all) is not guaranteed
to work from the RM.

I would argue that if you use the correct diction of
Address_To_Access_Conversions it definitely SHOULD
work with constrained arrays.

The conversion of an Address to a pointer to an
unconstrained array is fundamentally meaningless.
The former has no bounds, the latter has bounds,
where do they come from? Yes, in some limited cases
it may magically work, but it cannot work in the
general case.

Robert Dewar


Sent via Deja.com
http://www.deja.com/