5 ms·
> unsigned char * is better for both raw binary buffers and dealing w/ buffers of UTF-8 data. Or, even better, uint8_t. Fundamental types don’t have guarantee
by uranusjr 8y ago
> unsigned char * is better for both raw binary buffers and dealing w/ buffers of UTF-8 data.
Or, even better, uint8_t. Fundamental types don’t have guarantee fixed sizes, only minimum. Explicitly asking for 8 bits only can save sanity in edge cases in a long running code base where no one is sure what other people is doing anymore.
- maccard 8y ago> Or, even better, uint8_t. Fundamental types don’t have guarantee fixed sizes This is overly pedantic IMO. Practically speaking, a char will always be 8bits, unless you're working in embedded (even then, only some ancient DSP devices IIRC have non 8 bit Char). If you're writing code for POSIX, a chae will always be 8 bits, as will windows^. Almost evrry embedded device also works with an 8 bit Char, and anything that doesn't you probably know about in advance, and probably aren't handling Unicode text on. ^ Citation needed
- mikeash 8y agoChar is also the smallest data type the language can have, so if char isn’t 8 bits then uint8_t won’t be available and your code won’t build anyway. That’s preferable to building and misbehaving, but if you got that far without realizing you’re dealing with an unusually-sized char then you’re probably doomed anyway.
- dagenix 8y ago> This is overly pedantic IMO. Practically speaking, a char will always be 8bits ... [List of some cases where it isn't] If you want an 8-bit unsigned type, uint8_t is that type. If it's available, going with it isn't "overly pedantic", not going with it is irresponsible. What does "overly pedantic" even mean here? Whenever I see that phrase, it's often a case of someone who is wrong trying to shame someone who is a right for the crime of being right.