From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,d778a4f52acd9d43 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.122.199 with SMTP id lu7mr571739pbb.1.1325029633004; Tue, 27 Dec 2011 15:47:13 -0800 (PST) Path: lh20ni71722pbb.0!nntp.google.com!news1.google.com!news4.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Representation clauses for base-64 encoding Date: Wed, 28 Dec 2011 01:47:11 +0200 Organization: Tidorum Ltd Message-ID: <9lv3nvF57cU1@mid.individual.net> References: <4ef31672$0$6574$9b4e6d93@newsspool3.arcor-online.net> <9lgls6FticU1@mid.individual.net> <4ef34839$0$7623$9b4e6d93@newsspool1.arcor-online.net> <4ef3acd0$0$6642$9b4e6d93@newsspool2.arcor-online.net> <9lobhaF9adU1@mid.individual.net> <4ef9aaad$0$6643$9b4e6d93@newsspool2.arcor-online.net> <9lul3qFmgaU1@mid.individual.net> Mime-Version: 1.0 X-Trace: individual.net R8/zj3H4QnP0K8UUweVqKg9/GN0fN1vwGhLmf2VHiO8OiAhTxe Cancel-Lock: sha1:OMvHmvtLz0AY3UcK+jgzcBxMk6M= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Date: 2011-12-28T01:47:11+02:00 List-Id: On 11-12-27 22:49 , Robert A Duff wrote: > Niklas Holsti 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 . @ .