We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
... 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 ?
The important thing for you is to make sure that the compiler can not consume more characters than you specifically want to belong to the hex constant. My first post shows what I normally do.
I agree. What's odd, however, is why the compiler seemingly ignores leading zeros, rather than consuming all valid hex characters following the \x. Refering back to my original post, you'll see that the "\x0CABC" does NOT consume the B and the C in the string ... both of which by definition are valid hexidecimal digits. It apparently ignores the leading zero, then encodes the next TWO digits ( the C and A in this case ).
Now, given that this forum's primary purpose is a venue for debate rather than assistance, I will accept the obligatory ongoing debate, but you do have to admit that the behavior of the \x conversion is a bit odd. No ?