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. 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. _______________________________________________ bug-gnulib mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-gnulib
