Re: Examining individual bytes of an integer

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2018-10-18 00:10, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:pq6r7i$1o47$1@gioia.aioe.org...
>> On 2018-10-17 00:33, Randy Brukardt wrote:
>>
>>> That's the model for the entire compiler: all objects are
>>> statically sized, and if needed, the actual data is found by indirection.
>>
>> That makes me missing RM rule (not advice): for any instance of
>>
>>     new X
>>
>> Allocate of the corresponding storage pool is called exactly once.
> 
> I would fight that at every level, since it would make a useful
> implementation of discriminated records impossible. Ada has always been very
> clear that non-contiguous representations are allowed.

I know, but on the other hand it would make a lot of useful applications 
non-portable.

> It might make sense to introduce some sort of aspect to require a contigious
> representation for an array or record, so long as that's only required to be
> supported on sensible types.

I would rather consider a general method for handling all sorts of type 
constraints in a regular manner available for the programmer.

This should include stripping constraints when statically known when the 
object is passed as a parameter and adding constraints when a statically 
constrained object gets dynamically constrained (e.g. slices, conversion 
to T'Class). We could use hidden parameters for this (such objects 
cannot be used for interfacing with other languages anyway, if that is a 
concern).

Another point is calculation of such constraints in a separate body 
(possibly static) when doing assignment or allocation. Presently 
reasonable object initialization is impossible when constraints are 
dynamic. The same case: static checks for dimensioned arithmetic are 
impossible because the constraint (dimension) must be calculated in the 
same body as the operation itself, but we want it calculated and checked 
at compile time instead.

> In particular, this type should work with raising Storage_Error or some
> other exception on all Ada compilers:
> 
>       type Rec (D : Natural) is record
>           Arr : String (1 .. D);
>       end record;
> 
>       C0Rec : constant Rec(0) := (D => 0, Arr => "");
>       C1Rec : constant Rec(1) := (D => 1, Arr => "R");
>       A_Rec : Rec := C0Rec;
> 
>       A_Rec := C1Rec;
>       A_Rec := (D => 3, Arr => "RLB");
> 
> A type like this pretty much requires discontiguous representations and
> reallocation on assignment.

It is no loss, Storage_Error is OK to me. IMO no built-in type shall use 
hidden dynamic allocation, except when required by the target OS (e.g. 
for tasks). Anything that is impossible to implement otherwise must be 
moved to the library (like Unbounded_String).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de