Re: Problem with Position of the enumeration Type

["Randy Brukardt" <randy@rrsoftware.com>]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:gauihgF9eu2U1@mid.individual.net...
> On 19-01-24 18:43 , Jeffrey R. Carter wrote:
>> On 1/23/19 11:35 PM, Simon Wright wrote:
>>> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>>>
>>>> Such rules also commonly say that such types should not be used as
>>>> array index types, because of the possible introduction of gaps in the
>>>> array representations.
>>>
>>> Not, it seems, with GNAT:
>>
>> This is not a language rule. I can find nothing in the ARM about
>> disallowing such types as array indices. So naturally GNAT and all other
>> compilers must support it.
>
> All compliant compilers, yes. But the question was: if the enumerated 
> index type has gaps in its representation, can there be corresponding gaps 
> (unused intervals of storage units) between the elements of the array, as 
> represented in memory? Or must the elements still be contiguous, except 
> for alignment padding?
>
> In other words, can the compiled code compute the offset of an array 
> element directly from the representation of the enumerated index value 
> (causing gaps in the array), or must it always first compute the position 
> number of that value, and then compute the offset from the position number 
> (suppressing gaps)?
>
> This discussion has not yet pointed to an ARM rule that forbids gaps in 
> the array's representation.

There's no language rule of course, but more a practical one: operations 
like slicing and sliding become challenging if the array has gaps. And you 
don't get to ignore those just 'cause they're hard.

                      Randy.