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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,e710f7d3f890e76b X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!news3.google.com!proxad.net!feeder1-2.proxad.net!62.111.101.3.MISMATCH!news.germany.com!news-stu1.dfn.de!news.uni-stuttgart.de!not-for-mail From: Stefan Bellon Newsgroups: comp.lang.ada Subject: Re: Base64-Encoding Date: Mon, 15 Oct 2007 16:54:35 +0200 Organization: Comp.Center (RUS), U of Stuttgart, FRG Message-ID: <20071015165435.0eef160d@cube.tz.axivion.com> References: <20071015161229.3f439230@cube.tz.axivion.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: infosun2.rus.uni-stuttgart.de 1192460084 30177 129.69.226.23 (15 Oct 2007 14:54:44 GMT) X-Complaints-To: news@news.uni-stuttgart.de NNTP-Posting-Date: Mon, 15 Oct 2007 14:54:44 +0000 (UTC) X-Newsreader: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; i486-pc-linux-gnu) X-URL: http://www.axivion.com/ Xref: g2news2.google.com comp.lang.ada:2452 Date: 2007-10-15T16:54:35+02:00 List-Id: On Mon, 15 Oct, Jacob Sparre Andersen wrote: > Stefan Bellon wrote: > > > Padded_Data : String (1 .. Padded_Length) := (others => > > ASCII.NUL); -- Padded input data. > [...] > > begin > > Padded_Data (1 .. Data'Length) := Data; > > -- Initialize data into padded-data (can't be done with > > aggregate -- in elaboration part, sadly). > > Why? I may have missed something obvious, but I would have thought > that > > Padded_Data : String (1 .. Padded_Length) := Data & (others => > ASCII.NUL); > > would work fine. This results in: error: "others" choice not allowed here > > However it looks like this solution has a problem with endianness, > > in a way that the wrong 6 bits of the Bytes are used in the > > conversion. > > :-( > > > Is there an easy way to fix this (as I think the rest would be > > pretty neat) or is this way of trying to do it, doomed to fail > > anyway? > > Is it a problem that section 13.5.3 (Bit Ordering) can handle? I hoped for this as well, but it looks like the attribute Bit_Order is only defined for record types. This is what 13.5.3 says and indeed GNAT refuses to accept a 'Bit_Order on Six_Bits or the array thereof. -- Stefan Bellon