On 12/31/2016 12:08 PM, Gerald Pfeifer wrote:
On Fri, 9 Sep 2016, Martin Sebor wrote:
I mentioned the hex vs octal notation to invite input into which
of the two of them people would prefer to see used by the %qc and
qs directives, and whether it's worth considering changing the %qE
directive to use the same notation as well, for consistency (and
to help with readability if there is consensus that one is clearer
than the other).
I do think hex is the way to go, and that it would be good to be
consistent across the board.
(All e-mail alert, but I don't think I saw a response to that.)
What I meant by ambiguity is for example a string like "\1234"
where it's not obvious where the octal sequence ends. Is it '\1'
followed by "234" or '\12' followed by "34" or '\123' followed
by "4"? (It's only possible to tell if one knows that GCC always
uses three digits for the octal character, but not everyone knows
that.)
Agreed. And octal notation is just not very common today, too,
I'd argue.
Thanks. I think the thread petered out after that and I didn't
remember to get back to it and the still outstanding %qE problem
where GCC uses the octal base and doesn't convert the character
values to unsigned char, resulting in confusing output like that
below:
$ echo 'constexpr int i = "\x80";' | gcc -S -Wall -Wextra -xc++ -
<stdin>:1:19: error: invalid conversion from ‘const char*’ to ‘int’
[-fpermissive]
<stdin>:1:19: error: ‘(int)((const char*)"\37777777600")’ is not a
constant expression
(The still unconfirmed bug 77573 came out of my tests of the fix
for the related bugs in the subject and tracks the wide character
part of the problem.)
Martin
