Re: [PATCH] avoid non-printable characters in diagnostics (c/77620, c/77521)

[Martin Sebor <msebor@gmail.com>]

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