From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 63947 invoked by alias); 15 Aug 2018 14:47:19 -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 63927 invoked by uid 89); 15 Aug 2018 14:47:18 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=interactions, personal X-HELO: mail-qt0-f195.google.com Received: from mail-qt0-f195.google.com (HELO mail-qt0-f195.google.com) (209.85.216.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 15 Aug 2018 14:47:17 +0000 Received: by mail-qt0-f195.google.com with SMTP id r21-v6so1430686qtm.2 for ; Wed, 15 Aug 2018 07:47:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=Keb9U4sd/m84klPO1e1BlabUTtMBPo+7/FrVS+wWesw=; b=Vzdh/NJ8ySF7JsqJadbduLOHQqcBGxv+wHrS95/r8jpgMBRw3VL49WRPyzaObpiqqj rrMiDCasZDf0GHPl58QwvyVto6IvpGIWW023GJhMnTlzE8xceH3LBgiV36FxIN0y9AfC ybLynR2v4GCiVNQRwbVN2FxgIK95dH1UMagUiRsFkVuiQpxCEvoo42UbJERGKtAC9Okb OwN0M2a7m0GovV+rjOM0tESAKpECO/LS6gulIdgp4fjqBUqleGmJ/kZa9F2PIaSh1Iw3 mXkUOBdTtGlQfEsBIQ90d8UtNrlR0W+DhASIPjpbz+wpP7Mp9oxLxxvKi5KNns1SdA+V VkUg== Return-Path: Received: from localhost.localdomain (75-166-100-32.hlrn.qwest.net. [75.166.100.32]) by smtp.gmail.com with ESMTPSA id s64-v6sm13680102qkc.70.2018.08.15.07.47.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Aug 2018 07:47:13 -0700 (PDT) Subject: Re: [PATCH 0/6] improve handling of char arrays with missing nul (PR 86552, 86711, 86714) To: Jeff Law , Gcc Patch List References: <1deebf5b-f41f-1e2c-c278-a67017cbe201@redhat.com> From: Martin Sebor Message-ID: <0bf707ad-a28f-ab08-cdd9-28dd47a4a2eb@gmail.com> Date: Wed, 15 Aug 2018 14:47:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1deebf5b-f41f-1e2c-c278-a67017cbe201@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-08/txt/msg00880.txt.bz2 On 08/15/2018 12:02 AM, Jeff Law wrote: > On 08/13/2018 03:23 PM, Martin Sebor wrote: >> To make reviewing the changes easier I've split up the patch >> into a series: > [ ... ] > I'm about done for the night and thus won't get into the series (and as > you know Bernd has a competing patch in this space). But I did want to > chime in on two things... > >> >> There are many more string functions where unterminated (constant >> or otherwise) should be diagnosed. I plan to continue to work on >> those (with the constant ones first) but I want to post this >> updated patch for review now, mainly so that the wrong code bug >> (PR 86711) can be resolved and the basic detection infrastructure >> agreed on. > Yes, I think we definitely want to focus on the wrong code bug first. > >> >> An open question in my mind is what should GCC do with such calls >> after issuing a warning: replace them with traps? Fold them into >> constants? Or continue to pass them through to the corresponding >> library functions? > My personal preference is to turn them into traps. I don't think we > have to preserve the call itself in this case. I think the sequencing > is to insert the trap before the call point, split the block after the > trap, remove the outgoing edges, let DCE clean up the rest. At least I > think that's the sequencing. That sounds fine to me. It would be close in its effects to what _FORTIFY_SOURCE does. It would be helpful to get a broader consensus on this and start adopting the same consistent solution in all contexts. The question has come up a few times, most recently also in PR 86519 (folding memcmp(a, "a", 3)) where GCC ends up calling the library function. FWIW, if there are other preferences it might be worthwhile to consider providing an option to control the behavior in these cases. There may also be interactions with or implications for the sanitizers to consider. Once there is agreement on what the solution should be I can look into implementing it at some point in the future. Martin