From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 35156 invoked by alias); 12 Aug 2019 20:04:21 -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 35148 invoked by uid 89); 12 Aug 2019 20:04:21 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy= 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, 12 Aug 2019 20:04:19 +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 9F2D130EA19E; Mon, 12 Aug 2019 20:04:18 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-27.rdu2.redhat.com [10.10.112.27]) by smtp.corp.redhat.com (Postfix) with ESMTP id 81AF162675; Mon, 12 Aug 2019 20:04:17 +0000 (UTC) Subject: Re: [PATCH] fold more string comparison with known result (PR 90879) To: Martin Sebor , Jakub Jelinek Cc: gcc-patches References: <223e6275-98b9-f46d-a5c0-4ea802a68aaf@gmail.com> <20190809162257.GB2726@tucnak> <80cf0a28-35c9-d57f-729a-d1cf58bd21d1@gmail.com> <20190809165803.GC2726@tucnak> <0e9e9034-3357-6d8e-d38d-35c38bdb2882@gmail.com> From: Jeff Law Openpgp: preference=signencrypt Message-ID: Date: Mon, 12 Aug 2019 20:15:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <0e9e9034-3357-6d8e-d38d-35c38bdb2882@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00771.txt.bz2 On 8/9/19 4:14 PM, Martin Sebor wrote: > On 8/9/19 10:58 AM, Jakub Jelinek wrote: >> On Fri, Aug 09, 2019 at 10:51:09AM -0600, Martin Sebor wrote: >>> That said, we should change this code one way or the other. >>> There is even less of a guarantee that other compilers support >>> writing past the end of arrays that have non-zero size than >>> that they recognize the documented zero-length extension. >> >> We use that everywhere forever, so no. > > Just because some invalid code has been in place "forever" doesn't > mean it cannot be changed.  Relying on undocumented "extensions" > because they just happen to work with the compilers they have been > exposed to is exactly how naive users get in trouble.  Our answer > to reports of "bugs" when the behavior changes is typically: fix > your code.  There's little reason to expect other compiler writers > to be any more accommodating. > >> See e.g. rtx u.fld and u.hwint arrays, tree_exp operands array, >> gimple_statement_with_ops op array just to name a few that are >> everywhere.  Coverity is indeed unhappy about >> that, but it would be with [0] certainly too.  Another option is >> to use maximum possible size where we know it (which is the case of >> rtxes and most tree expressions and gimple stmts, but not e.g. >> CALL_EXPR or GIMPLE_CALL where there is no easy upper bound. > > The solution introduced in C99 is a flexible array.  C++ > compilers usually support it as well.  Those that don't are > likely to support the zero-length array (even Visual C++ does). > If there's a chance that some don't support either do you really > think it's safe to assume they will do something sane with > the [1] hack?  If you're concerned that the flexible array syntax > or the zero length array won't compile, add a configure test to > see if it does and use whatever alternative is most appropriate. Given that we require a C++03 compiler to build GCC, I think we can revisit how we represent the trailing array. But that seems independent of the bulk of this patch. Can we separate this issue from the rest of the patch? jeff