From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by sourceware.org (Postfix) with ESMTP id A0A2E384A030 for ; Thu, 5 Nov 2020 15:30:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A0A2E384A030 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-246-I4dqQyDFNs27KAI3bUyoxw-1; Thu, 05 Nov 2020 10:29:58 -0500 X-MC-Unique: I4dqQyDFNs27KAI3bUyoxw-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 2167B1084D63; Thu, 5 Nov 2020 15:29:57 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-113-127.ams2.redhat.com [10.36.113.127]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8D7EB73679; Thu, 5 Nov 2020 15:29:56 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 0A5FTqCP3362457 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 5 Nov 2020 16:29:52 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 0A5FTpit3362456; Thu, 5 Nov 2020 16:29:51 +0100 Date: Thu, 5 Nov 2020 16:29:51 +0100 From: Jakub Jelinek To: Martin Sebor Cc: Richard Biener , gcc-patches Subject: Re: [PATCH] cache compute_objsize results in strlen/sprintf (PR 97373) Message-ID: <20201105152951.GD3788@tucnak> Reply-To: Jakub Jelinek References: <34f3587a-7c93-804e-639a-da37a1ef50ab@gmail.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 15:30:03 -0000 On Thu, Nov 05, 2020 at 08:20:20AM -0700, Martin Sebor via Gcc-patches wrote: > compute_objsize() and the objsz pass are completely independent. > The pass is also quite limited in that it doesn't make use of > ranges. That limitation was also the main reason for introducing > the compute_objsize() function. > > I'd love to see the objsize pass and compute_objsize() integrated > and exposed under an interface similar to range_query, with > the information available anywhere, and on demand. I might tackle As I said multiple times, that would be a serious security hazard. _FORTIFY_SOURCE protects against some UBs in the programs, and ranges are computed on the assumption that UB doesn't happen in the program, so relying on the ranges etc. in there is highly undesirable. Jakub