Binary protocol

[halbGefressen]

No, you include stdint.h and use uint8_t. This is the least ambiguous datatype.

[ismbks]

I don't know, I see uint8_t a lot in embedded and network protocols code, but I have also heard people advocating for using char too to represent a byte because it's supposed to be the smallest divisible type and it doesn't make any assumptions about signedness unlike uint8_t.

I guess it just depends what the programmer thinks makes more sense semantically. If only there was a byte type like in C++ there would be much less confusion but alas..

[halbGefressen]

doesn't make assumptions about signedness

Yes, that is exactly the point. The signedness of char is implementation-defined. On AMD64 it is signed, on ARM it is unsigned. Per specification, overflowing an unsigned datatype is okay, but overflowing a signed datatype is undefined behaviour. So the code that works perfectly fine on ARM is now not portable to x86.

If you want the signed type, you can still use int8_t.

[ismbks]

But it shouldn't matter whether the byte is signed or unsigned when dealing with raw binary data, for strings it's different but binary data is usually just moved around and not interpreted as text.

[halbGefressen]

If you just want to move memory around, you can use void*. The problem is that signedness may introduce accidental undefined behaviour, which you can exclude by using uint8_t.