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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,bffcdbd805329ff8 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-08-29 11:51:01 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newshub2.home.com!news.home.com!news1.rdc1.sfba.home.com.POSTED!not-for-mail From: tmoran@acm.org Newsgroups: comp.lang.ada Subject: Re: Ada and Internet stuff References: <3B8D181E.8C9523D@san.rr.com> X-Newsreader: Tom's custom newsreader Message-ID: Date: Wed, 29 Aug 2001 18:51:01 GMT NNTP-Posting-Host: 24.7.82.199 X-Complaints-To: abuse@home.net X-Trace: news1.rdc1.sfba.home.com 999111061 24.7.82.199 (Wed, 29 Aug 2001 11:51:01 PDT) NNTP-Posting-Date: Wed, 29 Aug 2001 11:51:01 PDT Organization: Excite@Home - The Leader in Broadband http://home.com/faster Xref: archiver1.google.com comp.lang.ada:12574 Date: 2001-08-29T18:51:01+00:00 List-Id: > Do people generally treat Ada.Streams.Stream_Element_Array as the > equivalent of an array of octets without further checking? They shouldn't. Base64 encoding conceptually takes 24 bit chunks of input and encodes it in 4 output text characters. But the code to automagically adjust to Stream_Elements that aren't 8 bits wide would, I suspect, be substantally less clear, and rarely used, so my base64 routine doesn't do it. I thought about putting in a test that Stream_Element'size=8, but decided, again for simplicity and clarity vs frequency of use, to settle for a comment instead. Full generality might be an interesting exercise. > Also, what's the mechanism for dealing with things like UTF-8? Base64 is specifically designed to work across various character encodings. Thus an 'A' means 6 bits of zeroes, regardless of how that 'A' is represented. You *should* be able to replace String with Wide_String and Character with Wide_Character appropriately and have it work. Of course your 24 bits of input would then be 64, rather than 32 bits, encoded, for an expansion factor of 2.66, which would rather argue against it. > -- Target'length must be at least: > -- Output_Quad_Count: constant := (Source'length + 2) / 3; > -- Output_Byte_Count: constant := 4 * Output_Quad_Count; > -- Target'length = Output_Byte_Count + 2 * (Output_Byte_Count / 76) > > This should be a function. :-) Probably, it would be best to have a > function that takes an input length and returns the output length in > both directions, so you can allocate your buffers properly before > calling the functions. Extra whitespace and missing line breaks are both allowed in encoded data, so you can't tell without looking at it, ie running the decoding, just what it will decode into. No such problem on encoding. You could make function Encode(X : Stream_Element_Array) return String; function Decode(S : String) return Stream_Element_Array; and let them generate and return the correct size results. That's not terribly hard but is surely less speedy, which may matter. > I'd be happy to tackle this. :-) Looking forward to it!