On Tue, 2018-02-06 at 12:39 +0000, Nick Clifton wrote:
> Hi Martin,
>
> > My only suggestions are to consider how control characters and
> > excessively messages are handled in other contexts and adopt
> > the same approach here.
>
> Are there other places where user-supplied messages are displayed by
> gcc ?
#pragma GCC warning and error (as opposed to #warning and #error) also
print control chars without escaping:
$cat /tmp/prag.c
#error "foo\nbar"
#warning "foo\nbar"
#pragma GCC error "foo\nbar"
#pragma GCC warning "foo\nbar"
$ gcc -c /tmp/prag.c
/tmp/prag.c:1:2: error: #error "foo\nbar"
#error "foo\nbar"
^~~~~
/tmp/prag.c:2:2: warning: #warning "foo\nbar" [-Wcpp]
#warning "foo\nbar"
^~~~~~~
/tmp/prag.c:3:19: error: foo
bar
#pragma GCC error "foo\nbar"
^~~~~~~~~~
/tmp/prag.c:4:21: warning: foo
bar
#pragma GCC warning "foo\nbar"
^~~~~~~~~~
Note the newlines in the above output.
There may be other places.
My preference is either the status quo, or to escape the control
characters.
The patch is missing a test case.
>
> > In the tests I did, control characters
> > were mostly escaped (e.g., as \n or as \x0a) rather than replaced
> > with spaces.
>
> Ooo - what tests were these ?
>
> I agree that it there is a standard way to handle these characters
> then the deprecated attribute ought to do the same. (Plus hopefully
> there is already a function in gcc to do this kind of processing,
> so the deprecation code can just call it).
There ought to be; I don't know it off the top of my head.
> > I haven't thought too hard about how excessively
> > long messages should be handled, or about the interactions with
> > -fmessage-length= (i.e., if messages longer than the limit should
> > be broken up.)
>
> I believe that this will happen automatically. The diagnostic
> display
> routine will automatically insert newlines into the output if the
> message length is non-zero, and the message extends past this limit.
> (Well provided that the message contains spaces. The newlines are
> only inserted in place of space characters so a very long, single
> word message will not be split...)
>
> Cheers
> Nick
