Why is '\xff' not being recognized? - c

Question

I know that 0xff can have different representations depending on what the variable type is. Like -1 for signed (chars/ints(?)) and 255 for unsigned chars.
But I am using the implementation-independent type of uint8_t and i've made sure that 0xff is infact inside the structure I am iterating across. Here is the code:
struct pkt {
uint8_t msg[8];
};
void main(int argc, char **argv) {
...
struct pkt packet;
memset(&packet, 0, sizeof packet);
strcpy(packet.msg, "hello");
packet.msg[strlen("hello")] = '\xff';
crypt(&packet, argv[1]);
...
}
void crypt(struct pkt *packet, unsigned char *key) {
int size = msglen(packet->msg);
...
}
int msglen(uint8_t *msg) {
int i = 0;
while(*(msg++) != '\xff') {
i++;
}
return i;
}
I've looked into the structure, and packet.msg[5] is indeed set to 0xff. But the while loop goes into an infinite loop, like it never discovered 0xff.
Values such as 0x7f works. I haven't tried 0x80 but I suspect it probably won't work if 0xff doesn't. It probably has something to do with the signness, but I just cant't see where the problem is supposed to come from.
Thanks.
EDIT: For me, it doesn't matter if I use 0x7f or 0xff. But I would just like to know what is preventing me from detecting 0xff.

Answer 1

If you have an unsigned, you can't use character literals.
'\xff' is -1, not 255, because the a character literal is signed.
The while condition is always true. If you are unsigned you should be using numbers only: 0 to 255, or casting characters you know are <128 to unsigned.

Answer 2

\xff is a character constant. It's of type int, not char (this is one way in which C differs from C++), but its value depends on whether plain char is signed or unsigned, which is implementation-defined.
The wording in the C standard is:
The hexadecimal digits that follow the backslash and the letter x in a
hexadecimal escape sequence are taken to be part of the construction
of a single character for an integer character constant or of a single
wide character for a wide character constant. The numerical value of
the hexadecimal integer so formed specifies the value of the desired
character or wide character.
If plain char is unsigned, then '\xff' is equivalent to 0xff or 255; it's of type int and has the value 255.
If plain char is signed, then '\xff' specifies a value that's outside the range of char (assuming that char is 8 bits). The wording of the standard isn't 100% clear to me, but at least with gcc the value of '\xff' is -1.
Just use an integer constant 0xff rather than a character constant \xff'. 0xff is of type int and is guaranteed to have the value 255, which is what you want.

Answer 3

I know that 0xff can have different representations depending on what the variable type is. Like -1 for signed (chars/ints(?)) and 255 for unsigned chars.
This needs some explanation. The integer literal 0xFF in a C program always means 255. If you assign this to a type for which 255 is out of range, e.g. a signed char then the behaviour is implementation-defined. Typically on 2's complement systems this is defined as assigning the value -1.
Character literals have different rules to integer literals. The character literal '\xff' must be a value that can sit in a char. You appear to have signed char, so it's implementation-defined what happens here, but again the most common behaviour is that this gets value -1. Note that character literals actually have type int despite the fact that they must have values representable by char.
In the line packet.msg[strlen("hello")] = '\xff'; , you try to assign (int)-1 to a uint8_t. This is out of range, but the behaviour is well-defined for out-of-range assignment to signed types, so the value you get is -1 (mod 256) which is 255.
Finally, when using the == operator (and most operators), the values are promoted to int if they were not already int. The 8-bit int 255 is promoted to (int)255, and you compare this against (int)-1, and they differ.
To solve this , change your comparison to have either 0xFF, or (uint8_t)'\xFF'.