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 ? > 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). > 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
