Paul Eggert <[EMAIL PROTECTED]> writes: > Simon Josefsson <[EMAIL PROTECTED]> 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. _______________________________________________ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
