From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 129022 invoked by alias); 5 Feb 2018 17:07:23 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 129008 invoked by uid 89); 5 Feb 2018 17:07:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-10.9 required=5.0 tests=BAYES_00,GIT_PATCH_2,GIT_PATCH_3,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=guidelines, HTo:U*dodji X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 05 Feb 2018 17:07:20 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5FD8F4F1D4; Mon, 5 Feb 2018 17:07:19 +0000 (UTC) Received: from snowball.redhat.com (ovpn-117-92.ams2.redhat.com [10.36.117.92]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B4D585EDEA; Mon, 5 Feb 2018 17:07:13 +0000 (UTC) From: Nick Clifton To: msebor@gcc.gnu.org, dodji@redhat.com, dmalcolm@redhat.com Cc: gcc-patches@gcc.gnu.org Subject: RFA: Sanitize deprecation messages (PR 84195) Date: Mon, 05 Feb 2018 17:07:00 -0000 Message-ID: <87h8qv9xhb.fsf@redhat.com> MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg00182.txt.bz2 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 my attempt at a patch to fix this. It is not very clever, just replacing the control characters with spaces, and doing it each time that a deprecation warning is displayed. But I figured that such warnings are going to be rare and do not need to be efficiently handled. So I choose to keep it simple. :-) No regressions with an x86_64-pc-linux-gnu toolchain. OK to apply ? Cheers Nick gcc/ChangeLog 2018-02-05 Nick Clifton PR 84195 * tree.c (warn_deprecated_use): Sanitize deprecation messages. Index: gcc/tree.c =================================================================== --- gcc/tree.c (revision 257389) +++ gcc/tree.c (working copy) @@ -12436,6 +12436,39 @@ else msg = NULL; + char * new_msg = NULL; + if (msg) + { + unsigned int i; /* FIXME: Do we need to check to see if msg is longer + than 2^32 ? */ + + /* PR 84195: Sanitize the message: + + If -fmessage-length is set to 0 then replace newline characters with + spaces. Replace other non-printing ASCII characters with spaces too. + + We do this check here, rather than where the deprecated attribute is + recorded because the setting of -fmessage-length can be changed + between those two locations. */ + for (i = 0; i < strlen (msg); i++) + { + char c = msg[i]; + + if (! ISCNTRL (c)) + continue; + + if (c != '\n' || ! pp_is_wrapping_line (global_dc->printer)) + { + if (new_msg == NULL) + new_msg = xstrdup (msg); + new_msg [i] = ' '; + } + } + + if (new_msg) + msg = new_msg; + } + bool w; if (DECL_P (node)) { @@ -12505,6 +12538,8 @@ } } } + + free (new_msg); } /* Return true if REF has a COMPONENT_REF with a bit-field field declaration