[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: Sun, 26 Mar 2006 00:07:26 -0800
User-agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)

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.

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.

So you may need to change the interface to use 'unsigned char *'
instead.  The C Standard says that 'unsigned char' is safe; it cannot
possibly have a trap representation.

But all this is relevant only if you want the code to be portable to
hosts where CHAR_BIT is not 8, or which do not use two's complement.
For sanity's sake, you may be better on insisting that CHAR_BIT is 8,
and on using unsigned char so that UCHAR_MAX must be 255.  That's good
enough for an RFC, I think.

reply via email to

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