Re: Examining individual bytes of an integer

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 18-10-14 22:55 , Jeffrey R. Carter wrote:
> On 10/14/2018 09:15 PM, Henrik Härkönen wrote:
>>
>>     type Byte is mod 256;
>>     type Word is mod 2 ** 32;
>>
>>     type E2 is array(1 .. 4) of Byte;
>>         function Convert_To_E2 is new Ada.Unchecked_Conversion (Source
>> => Word,
>>                                                             Target =>
>> E2);
>>
>>     function Convert_To_Word is new Ada.Unchecked_Conversion (Source
>> => E2,
>>                                                               Target
>> => Word);
>
> Unchecked_Conversion is the Ada Way.

Or Interfaces.Unsigned_xx and shifts.

> Often it is a good idea to specify
> the sizes of all the types involved to ensure that the conversion is
> between equal-sized hunks of memory.

Yes, but GNAT normally gives a warning if the sizes differ.

> However, with the array, you don't know which index corresponds to which
> byte of the integer. You can examine the bytes of several values to
> determine this, but on a different platform or with a different compiler
> the correspondence may be different.

Yes: endianness (or a perverse array index order, see below).

> Usually the lowest index
> corresponds to the lowest address, but that is not guaranteed by the
> language.

Not guaranteed, but implied by the "Implementation advice":

- RM 13.3(11): X'address denotes the address of the first of the storage 
elements allocated to X.

- RM 13.3(14): For an array X, X'Address should point at the first 
component of the array [...].

Combining those two, it seems that the first element of an array should 
start at the first storage element (= lowest address) allocated to the 
array.

By reasonable induction  :-)  the second, third, etc. array elements 
follow in increasing address order. But not _guaranteed_, I agree.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .