Re: base64.? going into rfc3548bis

[Paul Eggert]

Simon Josefsson <address@hidden> writes:

> Paul Eggert <address@hidden> writes:
>
>> Simon Josefsson <address@hidden> writes:
>>
>>> Alternatively, the prototype could be 'void*' for the data and cast it
>>> to 'uint8_t*' internally.  That would be safe, wouldn't it?
>>
>> No, because C implementations need not support uint8_t.  It is an
>> optional type.
>
> Even in C99?

That's correct.  C99 requires uint_least8_t, but not uint8_t.  There
is no requirement in C to support any 8-bit type.  Some C ports are to
hosts that are not byte-addressible.  Typically these are signal
processors these days.

>> Come to think of it, even 'char *' might have problems, since the
>> value (char) 0x80 might be a 'trap representation', which causes
>> undefined behavior if you try to use it.
>
> Do you have a reference for this?

Sure: section 6.2.6.1 of the C99 standard.  Paragraph 3 says that
unsigned char and unsigned bit-fields have pure binary
representations, but paragraph 5 says that all other types (and this
includes 'char') can have trap representations.  The behavior is
undefined if you attempt to load or store a trap representation.

> Is it enough to cast it to unsigned char whenever you actually
> dereference it?

No.  You have to convert the char * pointer to unsigned char *, and
then dereference the unsigned char * pointer.

> Hm, I'd like to avoid 'unsigned char*' if possible, having explicit
> signed and unsigned seems to generate a lot of warnings.

Yup.

It's much simpler just to assume a machine with 8-bit bytes
and 2's complement arithmetic with no trap representations.
Lots of gnulib code already does that.

The main reason to worry about weird machines for gnulib is (1) it's
fun, sometimes, and (2) if it's easy to port to them then you might as
well do it.  But I suspect that neither (1) nor (2) applies to base64.

I suppose the other reason that might apply is that you're writing an
RFC that could in principle be used on a Univac mainframe or some such
other weird host that really needs all this portability stuff.  But
that's really just category (2) again.