From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 79675 invoked by alias); 21 Mar 2017 23:56:14 -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 79659 invoked by uid 89); 21 Mar 2017 23:56:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy= X-HELO: mail-qk0-f170.google.com Received: from mail-qk0-f170.google.com (HELO mail-qk0-f170.google.com) (209.85.220.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 21 Mar 2017 23:56:12 +0000 Received: by mail-qk0-f170.google.com with SMTP id p22so7600426qka.3 for ; Tue, 21 Mar 2017 16:56:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ZrKSWhKDmcnFt37slOb4gsH11UUCfISMU2rNwG3WNcE=; b=eb0vWz5LduX9/9d+4oXXNqu7VDtoZKE2nBy9TjF/HN25ZF5pXmnEXuu/zPJj4qoM2N 1+nuyWGs5qrQLc5fwmHwae+Iw7Q23Jl2lDRDboXvHoiDHjNjujeALvZqoHWOKoxeDlxH 3NMURUW5wEiiLI3GjSnz3F4J9gSjLebCo80SEpbIIflVZpXOf1GTnlKrb3Qven7MGVFo 5geDp6oVM1S+2qJBhD/CieIh/lIM9AYbd68KTzBZiTsf5dNhX04oGiT6EC2FMJoX6mVT QKBtWKq0feZnUWp5bFgMlShOcDQcBLSjONY/phu3jsMUZi9KUcDQnQagMicoz/dfVIyt zv4A== X-Gm-Message-State: AFeK/H3OUxSNSfL7dxG/hlJN9ka/j3yM42JRPhJ9uy8f+M01ULMB3jGXF8gQHSIOd4eJpg== X-Received: by 10.55.92.195 with SMTP id q186mr30260699qkb.84.1490140571726; Tue, 21 Mar 2017 16:56:11 -0700 (PDT) Received: from localhost.localdomain (97-118-178-40.hlrn.qwest.net. [97.118.178.40]) by smtp.gmail.com with ESMTPSA id y3sm13067581qke.59.2017.03.21.16.56.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Mar 2017 16:56:11 -0700 (PDT) Subject: Re: [PATCH] have chkp skip flexible member arrays (PR #79986) To: Marek Polacek References: <4c6d8cdd-46f8-216d-56cb-07a74284f69a@gmail.com> <6320faa1-1958-5033-8352-665d0acfd5db@gmail.com> <20170321154649.GN3172@redhat.com> Cc: Jason Merrill , Gcc Patch List From: Martin Sebor Message-ID: <100585c2-eff0-0f86-b55a-a42544a8ce0c@gmail.com> Date: Tue, 21 Mar 2017 23:56:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20170321154649.GN3172@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-03/txt/msg01144.txt.bz2 > Since I've also spent some time on this: my take on this is that the C++ FE > should just follow C FE's suit and reject such initializations where > possible; it seems they've never worked reliably anyway, and bring more > harm than good. I don't see that rejecting such code would cause too much > trouble, if any, although the timing could be better. Schedule concerns aside, and although I agree that rejecting such code is far preferable to generating buggy programs, I'm not sure that rejecting auto initialization of flexible array members will ultimately lead to the best results. Users who want to initialize local objects with flexible array members will find some other (likely convoluted) way that GCC may not be able to find bugs in. A possible solution for those who can't or don't want to use std::array might be something like this: void f () { struct S { size_t n; int a[]; }; S *ps = (S*)alloca (sizeof (S) + 5); ps->n = 5; memcpy (ps->a, (const int[]){ 1, 2, 3, 4, 5 }, sizeof *ps->a * 5); ... } but that's clearly error-prone and hard to diagnose. GCC has no mechanism to detect bugs in this code without optimization, and because it folds the memcpy into a bunch of assignments, -Wstringop-overflow doesn't detect buffer overflows in the call to the function. I think it would be better to get the initialization to work so that users don't have to jump through hoops and can instead write cleaner code that more readily lends itself to checking for bugs. It might be even worth proposing local initialization as an enhancement for C2X. Martin