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 ESMTP id B433C3858D39 for ; Fri, 8 Oct 2021 17:56:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B433C3858D39 Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-358-6aeQF4S-MsGeNPxOp6mggg-1; Fri, 08 Oct 2021 13:56:52 -0400 X-MC-Unique: 6aeQF4S-MsGeNPxOp6mggg-1 Received: by mail-qk1-f197.google.com with SMTP id m6-20020a05620a24c600b004338e8a5a3cso8862394qkn.10 for ; Fri, 08 Oct 2021 10:56:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=ceKYlkqzrCLUCMPius3yffF5iy7rlLkl0QfTVcXsRek=; b=Fs6lEw1pFr9OQyXv0MXw7RRG9RFt6dzTajKvo8rXnCwJbTaf/ih/5o7q8as4y443GW PzA8aLWjH4HnRSRS4cl+321ZeNR01Jsa2/FkJrVWX+FZ34C0O0ceQ6mbdTKHXvY19pRv 05UhN3u7UmB4CvgPywL/TbZaQhAKeS6qGor78/hs3F1xYHj43X5iI78W6+TG8N6B5FwJ ws0yXmg6OlVZl93R7jZL7rM9Azpn0NOkpqxL7IlMt0j4hPaTZFnYECg6eAZt5QsvzsB+ ftQf7S8drbQrSjKHzWZPwmSY8t4sI/m0/8KA3UI5UsmKFKI7RutU+YCVwNDFCgIzM3SL NuxA== X-Gm-Message-State: AOAM531oORX/15/oBf0hTW6bw1GOyOwQKHbSkzrXl3gNuLjDg5kPEoVj 5cg7Qs2ENcwAR6MLMd6MAu/MU7iDlwXzGw6HuXz1KXdl8MzGqVRyEOl4bu4Xg7DHwUtlFCu9+fz jYikSsfUBPrFFTG3q3a9G40g4grQKvKVycNn12Tr7lL5VisSqAqjkkaI8aM+f7F2CeblmwQ== X-Received: by 2002:ac8:5619:: with SMTP id 25mr12893344qtr.325.1633715811794; Fri, 08 Oct 2021 10:56:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJySBX6fwNn6mhHuGkYT8lrwg4NtbMe5WUzkV0BZP8x5SAAJU/6ruxPKf8F5HN/SvxpzF4SRKA== X-Received: by 2002:ac8:5619:: with SMTP id 25mr12893316qtr.325.1633715811545; Fri, 08 Oct 2021 10:56:51 -0700 (PDT) Received: from [192.168.0.102] ([104.219.123.55]) by smtp.gmail.com with ESMTPSA id n16sm2977033qta.51.2021.10.08.10.56.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 Oct 2021 10:56:51 -0700 (PDT) Subject: Re: [PATCH] Convert strlen pass from evrp to ranger. To: Martin Sebor , Aldy Hernandez , Jakub Jelinek Cc: Martin Sebor , GCC patches References: <20211008151222.37790-1-aldyh@redhat.com> From: Andrew MacLeod Message-ID: <979d0351-fcb8-a2b8-cb5b-c4910dc4c979@redhat.com> Date: Fri, 8 Oct 2021 13:56:49 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-CA X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, 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, 08 Oct 2021 17:56:55 -0000 On 10/8/21 12:51 PM, Martin Sebor via Gcc-patches wrote: > > > I.e., in the test: > > void g (char *s1, char *s2) > { >   char b[1025]; >   size_t n = __builtin_strlen (s1), d = __builtin_strlen (s2); >   if (n + d + 1 >= 1025) >     return; > >   sprintf (b, "%s.%s", s1, s2); // { dg-bogus "\\\[-Wformat-overflow" } > > the range of n and d is [0, INF] and so the sprintf call doesn't > trigger a warning.  With your change, because their range is > [0, 1023] each (and there's no way to express that their sum > is less than 1025), the warning triggers because it considers > the worst case scenario (the upper bounds of both). > So the warning operates on the assumption that no info is OK, but improved information causes them to break because it can't figure out what to do with it? Does this ever work when there is more than 1 string in the sprintf?  It seems that its the inherent lack of being able to associate an expression with a predicate that is the problem here.  If this is a single string, then an accurate  range should be able to come up with an accurate answer.  But as soon as there is a second string, this is bound to fail unless the strings are known to be 1/2 their size, and likewise if there were 3 strings, 1/3 their size... Should we even be attempting to warn for multiple strings if we aren't going to be able to calculate them accurately? It seems like a recipe for a lot of false positives.   And then once we figure out how to combine the range info with the appropriate predicates, turn it back on? Andrew