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.133.124]) by sourceware.org (Postfix) with ESMTPS id DB41F3858C52 for ; Fri, 23 Sep 2022 13:03:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DB41F3858C52 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1663938181; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=eJnKbxogcE8yvQmwhkjhG+qKHBNuLg0HFcNdDhMaTQc=; b=UdxYa+IKZzfdy6z0raN/pXqz+oaTT7L/ton/fhGManbmKml8I3wJ1FGf1t+mrfa90/xc5s px6mEolQNzCLTEDV+xzFSN0dq51mZ7iY24qpJ6azesTkTz3Zl2ToJIXYNVF6tcD1rOuCXK Jear4AeSVuqEtYBRtBwrM0BomjO6rwo= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-618-3FfmNu4sPQeF6RuAyN0g_Q-1; Fri, 23 Sep 2022 09:02:59 -0400 X-MC-Unique: 3FfmNu4sPQeF6RuAyN0g_Q-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 08E20811E81; Fri, 23 Sep 2022 13:02:59 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.194]) by smtp.corp.redhat.com (Postfix) with ESMTPS id BA03D492B15; Fri, 23 Sep 2022 13:02:58 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 28ND2tRC291359 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 23 Sep 2022 15:02:56 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 28ND2tEh291358; Fri, 23 Sep 2022 15:02:55 +0200 Date: Fri, 23 Sep 2022 15:02:54 +0200 From: Jakub Jelinek To: Siddhesh Poyarekar Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] tree-object-size: Support strndup and strdup Message-ID: Reply-To: Jakub Jelinek References: <20220815192311.763473-1-siddhesh@gotplt.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.10 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=-4.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, Sep 22, 2022 at 11:26:29AM -0400, Siddhesh Poyarekar wrote: > On 2022-09-22 09:02, Jakub Jelinek wrote: > > On Mon, Aug 15, 2022 at 03:23:11PM -0400, Siddhesh Poyarekar wrote: > > > --- a/gcc/tree-object-size.cc > > > +++ b/gcc/tree-object-size.cc > > > @@ -495,6 +495,18 @@ decl_init_size (tree decl, bool min) > > > return size; > > > } > > > +/* Get the outermost object that PTR may point into. */ > > > + > > > +static tree > > > +get_whole_object (const_tree ptr) > > > +{ > > > + tree pt_var = TREE_OPERAND (ptr, 0); > > > + while (handled_component_p (pt_var)) > > > + pt_var = TREE_OPERAND (pt_var, 0); > > > + > > > + return pt_var; > > > +} > > > > Not sure why you want a new function for this. > > This is essentially get_base_address (TREE_OPERAND (ptr, 0)). > > Oh, so can addr_object_size be simplified to use get_base_address too? You can try. As you can see in get_base_address, that function handles something that the above doesn't (looking through some MEM_REFs too). > > Even if c_strlen (src, 1) is constant, I don't see what you can assume > > for object size of strndup ("abcd\0efgh", n); for minimum, except 1. > > Can't we assume MIN(5, n) for STRING_CST? If you mean MIN(5, n + 1), for c_strlen constant yes, but say if you have strndup (&"abcd\0efgh"[i], n); you can't just from seeing a base address being a STRING_CST with certain length assume anything than 1. > For ARRAY_REFs, it may end up being MIN(array_size, n) and not account for No, for non-OST_MINIMUM array size of objects (or string literals) containing the strings is relevant and you can indeed use MIN(__b{d}os (src), n + 1) as maximum. But for the minimum, the object size is irrelevant, you don't know where in the string there are '\0's and they could appear anywhere (unless you do string length range analysis). With c_strlen on src returning constant you know the exact string length and so you can use MIN (c_strlen (src, 1) + 1, n + 1) as both minimum and maximum, but in all other cases, 1 is the safe answer. Jakub