[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

#if CHAR_BIT != 8
 #error "This code assumes that CHAR_BIT is 8."

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]