Re: Representation clauses for base-64 encoding

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

On 11-12-27 22:49 , Robert A Duff wrote:
> Niklas Holsti<niklas.holsti@tidorum.invalid>  writes:
>
>> Whether a Boolean array is packed to Component_Size = 1, with no gaps,
>> depends on the Ada compiler. It is not a hard requirement in the Ada RM,
>> as I understand it.
>
> For any compiler that supports the SP annex (which pretty-much all do),
> it is a hard requirement.

Yes, a compiler cannot claim to support annex C (Systems Programming) 
unless it implements chapter 13 as recommended, so that all the 
"shoulds" are implemented. But this is only an argument for "probable" 
portability, since supporting annex C is optional.

For this discussion, I have again studied the chapter 13 rules about 
Bit_Order and record representation clauses. I think I understand now 
how it is meant to work, at least to some extent. As I understand it, if 
you specify Bit_Order and want your record representation clauses to be 
portable, the form of your clauses is strongly limited by the size of 
the "largest machine scalar" in the compilers you use. In particular, if 
you want to follow the style that always writes "at 0 range first_bit .. 
last_bit", you cannot specify the layout of a record that is larger than 
the largest machine scalar.

For example, the 24-bit record that Natasha suggested for the Base-64 
encoding does not work if the largest machine scalar is less than 24 
bits in size.

Out of curiosity, what is the case for JGNAT? Does it support annex C, 
and if not, how much of chapter 13 does it implement?

>> But there is not even a recommendation on the order in which bits in a
>> packed Boolean array are indexed, as far as I can see.
>
> True, but in practice, it will follow the endianness of the machine.

In that case, the meaning of slices of packed Boolean arrays, such as 
Georg Bauhaus presented, is different for little-endian and big-endian 
machines, and this cannot be corrected with a Bit_Order specification,

> Likewise, the RM doesn't say which bits of an integer represent
> what,

Well, combining the definition of Bit_Order in RM 13.5.3 with the 
definition of the First_Bit and Last_Bit attributes in RM 13.5.2 
suggests rather strongly that bit numbers defined by "offsets in bits" 
correspond either to increasing or decreasing significance in unsigned 
integer values.

> but in practice, the implementation is unlikely to make
> bit 17 be the high-order bit of a 32-bit integer.  ;-)

Agreed.

> I'd prefer these rules to be nailed down better.  But they're not, so
> you really have no choice but to rely to some extent on compilers doing
> sensible things.

You can avoid chapter 13 when portability is required, and use other 
means, such as Interfaces.Unsigned_N, where the only uncertainty is 
which sizes of Unsigned are implemented. But it is usually easy to use a 
larger Unsigned, if the exact size you would like to have is not 
provided. For example, the natural size of the bit-buffer for the 
Base-64 encoding is 8+(6-1) = 13 bits, but an Unsigned_N for any N >= 13 
can be used as well.

In contrast, the 24-bit-record-method falls apart if the compiler 
rejects its representation clause for some reason (for example because 
the largest machine scalar is less than 24 bits).

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