3 ms·
uint8_t is guaranteed to always be an octet, and stdint types (uint8_t, int32_t, uint32_t etc.) are also the recommended types to use when you want to make the
by alxlaz 8y ago
uint8_t is guaranteed to always be an octet, and stdint types (uint8_t, int32_t, uint32_t etc.) are also the recommended types to use when you want to make the size and signedness of the data clear. An array of uint8_t is definitely correct, and it's also the right thing to do in 2018. An array of char is something you should only use to store human-readable character in array form.
Many OS network APIs are "char based" because the C standard requires that sizeof char be exactly one byte, so it used to be a convenient shorthand, but that's not the case anymore.
- viraptor 8y ago> the C standard requires that sizeof char be exactly one byte That's at least 1, not exactly 1. It's POSIX that requires char to be 8bit.
- evincarofautumn 8y agoIt’s “exactly one byte” in the sense that by definition, sizeof(char) = 1, but it’s “at least one byte” in the sense that CHAR_BIT ≥ 8.
- alxlaz 8y agoNope, the C standard requires that sizeof char = 1, regardless of the width of a byte :-).
- jstimpfle 8y agoOne of the things I was not sure about is whether the size of uint8_t is guaranteed to be 1 as well. And whether that means the both are pointer-compatible. And if so, where is this specified?
- alxlaz 8y agoAs far as I know, C99 makes no requirements about the byte width of int8_t, only about its bit width. The relevant bits are in section 7.18.1.1 . There are few architectures and runtimes where this is relevant anymore, and the answer is really best given on a case-by-case basis. I think it's technically possible to make the two pointer-compatible on architectures with wider bytes. Last time I used one it was Analog Devices' SHARC, and I think they were pointer-compatible, but that was a long time ago, so take it with a grain of salt.
- deleted 8y ago[deleted]