[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: base64.? going into rfc3548bis
From: |
Paul Eggert |
Subject: |
Re: base64.? going into rfc3548bis |
Date: |
Fri, 24 Mar 2006 14:02:41 -0800 |
User-agent: |
Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) |
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.
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.
Re: base64.? going into rfc3548bis, Eric Blake, 2006/03/24