[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: base64.? going into rfc3548bis
From: |
Simon Josefsson |
Subject: |
Re: base64.? going into rfc3548bis |
Date: |
Tue, 28 Mar 2006 11:47:07 +0200 |
User-agent: |
Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) |
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? The code assume C99 already (stdbool.h).
> 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? Is it enough to cast it to unsigned
char whenever you actually dereference 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.
Hm, I'd like to avoid 'unsigned char*' if possible, having explicit
signed and unsigned seems to generate a lot of warnings.
Thanks.
Re: base64.? going into rfc3548bis, Eric Blake, 2006/03/24