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.191.41 with SMTP id gv9mr14707113pbc.5.1324808236030; Sun, 25 Dec 2011 02:17:16 -0800 (PST) Path: lh20ni62303pbb.0!nntp.google.com!news2.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: Sun, 25 Dec 2011 12:17:13 +0200 Organization: Tidorum Ltd Message-ID: <9lobhaF9adU1@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> Mime-Version: 1.0 X-Trace: individual.net jezBeAqxZaSkuca0fWXIGQUgO0gpB4wsDYYUmRHixlx7t4xp2g Cancel-Lock: sha1:XFyTc0Kn3MlZMS0ym4Y25HCp/9c= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 In-Reply-To: <4ef3acd0$0$6642$9b4e6d93@newsspool2.arcor-online.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Date: 2011-12-25T12:17:13+02:00 List-Id: On 11-12-23 00:18 , Georg Bauhaus wrote: > On 22.12.11 17:00, Natasha Kerensikova wrote: > >> However here representation is not used as a notion, only as a tool: >> using explicit shifts and masks, it is possible to write portable Ada >> that performs the correct split of 3 octets on any platform. >> >> The previous argument was that representation clauses allow more >> readable code, which I'm inclined to believe. But is it really necessary >> to give up portability for the sake of readability? > > There is middle ground, I think, insofar as it is possible > to extract bits in Ada without thinking about shifts and masks, > or logical operations. > > Given a stream chopped into octets, the goal is to extract slices > of 6 consecutive bits and represent these using the characters > from a Base 64 encoding table. Leave the how-to of extraction to > the compiler, just say which bits. This does not use representation > clauses for extraction, and not shifts or mask either. Without claiming > originality, completeness, enough subtypes, portability of bit indexing > of bits in a single octet, or sufficient code quality, the following might > illustrate the convenience of arrays of packed Booleans (guaranteed by > the LRM to have desirable properties): What are these "desirable properties" on which you rely, and where in the LRM are they guaranteed? > package B64 is [snip] > subtype Bit_Index is Natural range 0..23; > > type Bit_String is array(Bit_Index range <>) of Boolean; > pragma Pack(Bit_String); > > subtype Octet is Bit_String(Bit_Index range 0..7); [snip] > subtype Base_64_Digit is Bit_String(Bit_Index range 0..5); [snip] > procedure Add(Bits : Octet) is > Six_Pack : Base_64_Digit; > -- six bits ready to be processed > begin > case Position_In_Group is > when 0 => > Six_Pack := Base_64_Digit(Bits(2..7)); This assumes that the bits in an Octet are indexed in order of increasing significance, so that the slice Bits(2..7) gives the six most significant bits. Since you defined the Octet type, you are of course free to assume this. But your code does not show how the Octet values are derived from the original data, e.g. from a stream of Unsigned_8, or whatever binary data is to be encoded as Base-64. That is an essential part of the problem, and without it we cannot know if your approach works, or what operations it really needs. There are certainly ways to convert an Unsigned_8, for example, into an Octet value, such that the bits are indexed in increasing significance order, but it requires either shifting and masking, or the equivalent division or mod operations, or Unchecked_Conversion to a record type with eight Boolean components and a representation clause and a Bit_Order clause. If you use an Unchecked_Conversion directly from Unsigned_8 to Octet, you are assuming that the compiler implementes the indexing of Octet in significance order. Where does the LRM guarantee that? I don't think it does. Your Unchecked_Conversion (not quoted) from Base_64_Digit to Repertoire has the same problem, so at least that part of your code is not portable. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .