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 [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id EAB52385800C for ; Fri, 19 Nov 2021 15:56:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EAB52385800C Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-347-jZppvW1_P0O58k3l3wqJwQ-1; Fri, 19 Nov 2021 10:56:17 -0500 X-MC-Unique: jZppvW1_P0O58k3l3wqJwQ-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 BFCCA87D543; Fri, 19 Nov 2021 15:56:16 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.54]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5C12E60862; Fri, 19 Nov 2021 15:56:16 +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 1AJFuDOH4064070 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 19 Nov 2021 16:56:13 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 1AJFuCdg4064069; Fri, 19 Nov 2021 16:56:12 +0100 Date: Fri, 19 Nov 2021 16:56:12 +0100 From: Jakub Jelinek To: Siddhesh Poyarekar Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH 00/10] __builtin_dynamic_object_size Message-ID: <20211119155612.GQ2646553@tucnak> Reply-To: Jakub Jelinek References: <20211109190137.1107736-1-siddhesh@gotplt.org> MIME-Version: 1.0 In-Reply-To: <20211109190137.1107736-1-siddhesh@gotplt.org> 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=-5.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Fri, 19 Nov 2021 15:56:21 -0000 On Wed, Nov 10, 2021 at 12:31:26AM +0530, Siddhesh Poyarekar wrote: > - Instead of bailing out on non-constant sizes with > __builtin_object_size, it should be possible to use ranger to > get an upper and lower bound on the size expression and use that to > implement __builtin_object_size. I'd prefer not to. One thing is that VRP heavily relies on UB not happening in the program, while __bos is typically used to catch UB in those programs. And, I'm afraid fairly often VRP would result in runtime tests for limits that aren't useful for security at all. Say VRP figures out that some integer isn't negative or doesn't have MSB set etc., suddenly we have range of [0, INT_MAX] or similar and making that imply __builtin_object_size INT_MAX rather than ~(size_t) 0 would mean we need to use __*_chk and compare at runtime, even when it is very unlikely an object would be that big... The compiler computes some range, but there is not information on how much the range actually maps to the actual range the program is using, or when it is some much larger superset of the actual range (same problem is with Martin's warnings BTW). Some unrelated inlined function can perform some comparison just in case, perhaps some jump threading is done and all of sudden there is non-VARYING range. Jakub