Re: base64.? going into rfc3548bis

[Simon Josefsson]

Paul Eggert <address@hidden> writes:

> Ralf Wildenhues <address@hidden> writes:
>
>> -      *out++ = b64str[to_uchar (in[0]) >> 2];
>> +      *out++ = b64str[(to_uchar (in[0]) >> 2) & 0x3f];
>
> This change doesn't feel right to me.  It is ignoring the fact that
> the input to base64_encode is invalid.  The input is invalid because
> base64_encode is supposed to encode a series of octets, and you are
> working around the problem that the input is not a series of octets.
>
> You could change the interface so that base64_encode returns a
> boolean, indicating encoding failure.

Alternatively, the prototype could be 'void*' for the data and cast it
to 'uint8_t*' internally.  That would be safe, wouldn't it?

This (that is, using 'void*') may even be cleaner, because sometimes
you want to encode non-char binary data.  On the other hand, you may
then have endian and padding issues depending on how you are trying to
use it, but within the same software, encoding and decoding opaque
objects using base64 seem possible.

> Another possibility, which probably makes more sense, is to simply say
> that CHAR_BIT must be 8.  In reference code, you can check this as
> follows:
>
> #if CHAR_BIT != 8
>  #error "This code assumes that CHAR_BIT is 8."
> #endif
>
> POSIX already assumes CHAR_BIT is 8, so you're on pretty safe grounds
> nowadays if you assume it.  It's not worth going to a lot of effort
> worrying about non-8-bit hosts.  I'm sure there are other bugs in
> base64.c in this area, and we don't have time to scan for them.

After a quick review, I think the code handle CHAR_BIT > 8 fine except
for this problem.  But I'm inclined to follow your suggestion anyway,
if we can't agree on the void/uint8_t idea above.

Thanks.