... or a misunderstanding on my part ?
From string "\x0CTUV", the compiler generates 0x0C 0x55 0x56 0x57 0x00
From string "\x0CABC", the compiler generates 0xCA 0x42 0x43 0x00 ... rather than the expected 0x0C 0x41 0x42 0x43 0x00
I thought the \x escape sequence in a string instructed the compiler to encode the very next two characters as a hexadecimal byte.
Am I missing something ?
Don't assume that it will encode the next two characters. If the next character after your constant is a valid hexadecimal character, I recommend that you do: "\x0C""ABC" to make sure that you have separated your hexadecimal character from any following characters.
> Don't assume that it will encode the next two characters.
Well, apparently I shouldn't, but do you think it was an unreasonble assumption? I don't. I've never read that this escape sequence ignores a leading zero when the 3rd character is a valid hex digit. It makes no sense.
but do you think it was an unreasonble assumption?
Yes, it was unreasonable, because it contradicts what the language definition says about \x. There are specific examples in the C99 standard demonstrating exactly this pitfall (6.4.4.4 paragraph 14, 6.4.5 paragraph 7).
The deeper reason for this is that C doesn't assume chars are always 8 bits wide.
You just assumed that it accepts two non-zero charactersc :)
It will continue to eat characters until the first non-valid character is found.
gcc would consume every signle character in your second string, and then complain about "hex escape sequence out of range".
View all questions in Keil forum