Re: RFA: Sanitize deprecation messages (PR 84195)

On Fri, Feb 16, 2018 at 11:19 AM, Martin Sebor wrote: > On 02/16/2018 05:43 AM, Nick Clifton wrote: >> >> Hi David, >> >> Attached is a revised version of the patch which I hope addresses all >> of your (very helpful) comments on the v3 patch. >> >> OK to apply once the sources are back on

Re: RFA: Sanitize deprecation messages (PR 84195)

Hi Martin, > I'm getting a bootstrap failure: *sigh* yes - my bad. Fortunately a patch has already been posted: https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01039.html And I think that it has now been approved. Cheers Nick

Re: RFA: Sanitize deprecation messages (PR 84195)

Hi Nick, On Fri, Feb 16 2018, Nick Clifton wrote: > Hi David, > > Attached is a revised version of the patch which I hope addresses all > of your (very helpful) comments on the v3 patch. > > OK to apply once the sources are back on stage 1 ? > > Cheers > Nick > > gcc/ChangeLog >

Re: RFA: Sanitize deprecation messages (PR 84195)

On 05/03/2018 03:55 AM, Nick Clifton wrote: > Hi Jeff, > > Thanks for the review. > >> The docs still say "Control characters in the string will be replaced >> with spaces", but they're being escaped now. That needs to be fixed. > > Done. > >> I note you overload the cast operator in your

Re: RFA: Sanitize deprecation messages (PR 84195)

Hi Jeff, Thanks for the review. > The docs still say "Control characters in the string will be replaced > with spaces", but they're being escaped now. That needs to be fixed. Done. > I note you overload the cast operator in your new class. Why not just > use an accessor? Was this style

Re: RFA: Sanitize deprecation messages (PR 84195)

On Wed, May 02, 2018 at 11:00:20AM -0600, Jeff Law wrote: > + escaped = (char *) xmalloc (len * 2 + 1); > I believe that generally we want a slower growth pattern. You'll find > that we regularly do something like len * 3 / 2 + 1. Seems wise here too. We don't want to use xmalloc in

Re: RFA: Sanitize deprecation messages (PR 84195)

On 02/16/2018 05:43 AM, Nick Clifton wrote: > Hi David, > > Attached is a revised version of the patch which I hope addresses all > of your (very helpful) comments on the v3 patch. > > OK to apply once the sources are back on stage 1 ? > > Cheers > Nick > > gcc/ChangeLog > 2018-02-09

Re: RFA: Sanitize deprecation messages (PR 84195)

On 02/20/2018 05:48 AM, Nick Clifton wrote: Hi Martin, Since the class manages a resource it should ideally make sure it doesn't try to release the same resource multiple times. I.e., its copy constructor and assignment operators should either "do the right thing" (whatever you think that

Re: RFA: Sanitize deprecation messages (PR 84195)

Hi Martin, > Since the class manages a resource it should ideally make sure it > doesn't try to release the same resource multiple times.  I.e., its > copy constructor and assignment operators should either "do the right > thing" (whatever you think that is) or be made inaccessible (or declared

Re: RFA: Sanitize deprecation messages (PR 84195)

On 02/16/2018 05:43 AM, Nick Clifton wrote: Hi David, Attached is a revised version of the patch which I hope addresses all of your (very helpful) comments on the v3 patch. OK to apply once the sources are back on stage 1 ? Thanks (also) for adding the documentation! I have just one

Re: RFA: Sanitize deprecation messages (PR 84195)

On Fri, 2018-02-16 at 07:14 -0500, Trevor Saunders wrote: > On Thu, Feb 15, 2018 at 04:04:45PM -0500, David Malcolm wrote: > > On Fri, 2018-02-09 at 13:01 +, Nick Clifton wrote: > > > +class escaped_string > > > +{ > > > + public: > > > + escaped_string () { m_owned = false; m_str = NULL; };

Re: RFA: Sanitize deprecation messages (PR 84195)

On Fri, 2018-02-16 at 12:43 +, Nick Clifton wrote: > Hi David, > > Attached is a revised version of the patch which I hope addresses > all > of your (very helpful) comments on the v3 patch. > > OK to apply once the sources are back on stage 1 ? Yes. Thanks! Dave > Cheers > Nick >

Re: RFA: Sanitize deprecation messages (PR 84195)

Hi David, Attached is a revised version of the patch which I hope addresses all of your (very helpful) comments on the v3 patch. OK to apply once the sources are back on stage 1 ? Cheers Nick gcc/ChangeLog 2018-02-09 Nick Clifton PR 84195 * tree.c

Re: RFA: Sanitize deprecation messages (PR 84195)

On Thu, Feb 15, 2018 at 04:04:45PM -0500, David Malcolm wrote: > On Fri, 2018-02-09 at 13:01 +, Nick Clifton wrote: > > +class escaped_string > > +{ > > + public: > > + escaped_string () { m_owned = false; m_str = NULL; }; > > + ~escaped_string () { if (m_owned) free (m_str); } > > +

Re: RFA: Sanitize deprecation messages (PR 84195)

On Fri, 2018-02-09 at 13:01 +, Nick Clifton wrote: > Hi David, Hi Martin, > > OK, take 3 of the patch is attached. In this version: > > * The escaping is handled by a new class. > * Self-tests have been added (and they helped find a bug - yay!) > * The documentation has been

Re: RFA: Sanitize deprecation messages (PR 84195)

Hi David, Hi Martin, OK, take 3 of the patch is attached. In this version: * The escaping is handled by a new class. * Self-tests have been added (and they helped find a bug - yay!) * The documentation has been extended to mention -fmessage-length's effect on the #-directives, and

Re: RFA: Sanitize deprecation messages (PR 84195)

On 02/08/2018 04:04 AM, Nick Clifton wrote: Hi David, + /* PR 84195: Replace control characters in the message with their +escaped equivalents. Allow newlines if -fmessage-length has +been set to a non-zero value. I'm not quite sure why we allow newlines in

Re: RFA: Sanitize deprecation messages (PR 84195)

Hi David, >> + /* PR 84195: Replace control characters in the message with their >> + escaped equivalents. Allow newlines if -fmessage-length has >> + been set to a non-zero value. > > I'm not quite sure why we allow newlines in this case, sorry. Because the

Re: RFA: Sanitize deprecation messages (PR 84195)

On Wed, 2018-02-07 at 17:26 +, Nick Clifton wrote: > Hi Martin, Hi David, > > OK - attached is a new patch that: > > * Replaces control characters with their escape equivalents. > * Includes a testcase. > > I was not sure what to do about the inconsistencies between the > behaviour of

Re: RFA: Sanitize deprecation messages (PR 84195)

Hi Martin, Hi David, OK - attached is a new patch that: * Replaces control characters with their escape equivalents. * Includes a testcase. I was not sure what to do about the inconsistencies between the behaviour of #warning and #pragma GCC warning, (and the error equivalents), so I

Re: RFA: Sanitize deprecation messages (PR 84195)

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

Re: RFA: Sanitize deprecation messages (PR 84195)

On Tue, 2018-02-06 at 12:39 +, 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

Re: RFA: Sanitize deprecation messages (PR 84195)

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

Re: RFA: Sanitize deprecation messages (PR 84195)

On 02/05/2018 10:07 AM, Nick Clifton wrote: Hi Martin, Hi Dodji, Hi David, PR 84195 makes the point that deprecation messages do not follow the formatting guidelines set out by the -fmessage-length option, and that they could even contain unwanted control characters:

RFA: Sanitize deprecation messages (PR 84195)

Hi Martin, Hi Dodji, Hi David, PR 84195 makes the point that deprecation messages do not follow the formatting guidelines set out by the -fmessage-length option, and that they could even contain unwanted control characters: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84195 Below is