4 ms·
Use signed char for strings... What? No. Use plain "char" for strings (which may be signed or unsigned, depending on the environment). If you use "signed cha
by caf 11y ago
Use signed char for strings...
What? No. Use plain "char" for strings (which may be signed or unsigned, depending on the environment).
If you use "signed char" in an environment where plain "char" is unsigned then a comparison like:
string[i] == '\xff'
will be always false.
- metromint 11y agoIt won't make a difference for strings. But in C you can use a char to do math, when it will make a difference. In fact, when working in constrained memory environments, like embedded 8 bit applications a char will often be used to do math, and then it makes a big difference. This is because there is no byte type by default in C.
- nitrogen 11y agoThis is because there is no byte type by default in C. There is in C99 and newer: int8_t or uint8_t.
- analognoise 11y agoThis! C99 is old enough to drive; I don't know why there's so much cruft that's been fixed in C that gets perpetuated.
- 2bluesc 11y agoC99 is old enough to drive I'm using that from now on.
- Tomte 11y agoNo, char (not signed char, unsigned char, uint8_t or int8_t is the "byte type". By definition.
- nitrogen 11y agoCHAR_BIT must be at least 8 bits, but is not a "byte" as used by the original comment. The C standard defines "byte" differently from current common usage. To get exactly 8 bits of the desired signedness, which may not be possible on systems with CHAR_BIT greater than 8, one must use [u]int8_t. ---- From a draft version of the C standard: The typedef name intN_t designates a signed integer type with width N , no padding bits, and a two’s complement representation. Thus, int8_t denotes such a signed integer type with a width of exactly 8 bits. The typedef name uintN_t designates an unsigned integer type with width N and no padding bits. Thus, uint24_t denotes such an unsigned integer type with a width of exactly 24 bits. These types are optional. However, if an implementation provides integer types with widths of 8, 16, 32, or 64 bits, no padding bits, and (for the signed types) that have a two’s complement representation, it shall define the corresponding typedef names.
- Tomte 11y agoYes, exactly. Why are you telling me this? If we're talking about C, we should use the technical definition of "byte" as used by C. Everywhere else, sure, let's view byte as a 8 bit entity. That's so predominant that everything else would be nit-picking. But not in the context of the C language.
- nitrogen 11y agoI was commenting more for the benefit of the original commenter who said there is no "byte" type.
- caf 11y agoint8_t and uint8_t are definitely not possible on systems with CHAR_BIT greater than 8. (From 6.2.6.1: Values stored in non-bit-field objects of any other object type consist of n × CHAR_BIT bits, where n is the size of an object of that type, in bytes.)
- heinrich5991 11y agoI believe unsigned char is the byte type, as you're allowed to convert each type into a unsigned char array and read it out (by some standard, was it C99 or C11, I don't know).
- deleted 11y ago[deleted]
- btrask 11y agoYou're right, and that statement was poorly worded. If you check my project, I use plain char, which is signed on most platforms. The benefit of using unsigned char for binary data is the same, but the compiler warnings won't help on certain platforms.