On 02/06/2018 05:39 AM, 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 ?
There are a few that I know of. I added an incomplete list to
the bug but I'm pretty sure I missed some.
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 ?
Some of those David already mentioned (from my recent comment
on the bug):
1) #error and #warning where the string is printed as it appears
in the source (i.e., with escape sequences),
2) -Wformat where control characters are escaped,
3) -Wformat-overflow where control characters are not escaped
unless -fexec-charset= is specified. I consider it a bug
and plan to fix it.
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).
My preference is the same as David's: escape control characters
(using standard C escape sequences, i.e., \a, \n, etc, or \xff
for those that don't have the shorthand notation).
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...)
You're right, it does seem to happen automatically for strings
in #warning and attribute deprecated.
Martin
