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 ?
But C51 ( the MCU specified in this thread ) DOES specifically state chars are 8 bits wide.
Of course it does. But that doesn't affect the parsing of character and string literals. Those are defined by the language standard.
I recommend that you do: "\x0C""ABC"
Alternatively you could use three digit octal constants. I find the concatenated string literal approach a bit hard on the eye.
Who says that Octal constants are guaranteed to be exactly three digits?
Again, the spec says:
"Each octal or hexadecimal escape sequence is the longest sequence of characters that can constitute the escape sequence."
When written just as:
"\x0C""ABC"
I agree with you - but I would argue that's just poor presentation.
You could easily write it much more clearly; eg,
"\x0C" "ABC"
Which, I think, makes it mach clearer that there's an initial "special" code, followed by some plain text.
Comments should, of course, be provided to explain this...
Octal is sooooooo seventies!
But even so, at least in C99 an octal sequence can't be longer than three digits. So if you actually write down a three-character octal sequence, the result is unambiguous.
The difference is not in the text, but in the grammar rules (which are implied by the "can constitute" clause in the above). An octal escape sequence is a '\' followed by one to three octal digits, a hex escape sequence is a '\x' followed by at least one hex digit.
Now that I like. Thanks!
Nobody.
Indeed it does. It is your interpretation that is flawed.
I am amazed it did not digest all the characters as hex since they are in range, and even with the "" as that might go away before the final parse! Why did it stop short?The safe way is char by char:
char x[] = { 0x0C, 'A', 'B', 'C', '\0' };
You realise you are replying to a 12 year old thread ?