Re: Ada and Internet stuff

[tmoran@acm.org]

> 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!