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 0DB633858C2F for ; Sun, 11 Sep 2022 08:40:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0DB633858C2F 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=1662885638; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lPP66SZjkXqzQ4ElXFxIwTMzdJhfAJNNP0E+pIoug/s=; b=g7SeIa7TbQO++2ITxhKuTdE1pTLx66U2GpQUEdus29maX+op9lWT0az7JjxDVCUUg6aOQ2 udU+YAQjUez9qWWt2UREHseOFwefutSZUY1iz+ISkR6S1ENu6ozIVVGn79XlV8mvAJt2w2 YctIF76K8dAImCw3f1/orLxNF/3sbO4= Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-402-8-pj5rEAMrqWu7HQ6KiClA-1; Sun, 11 Sep 2022 04:40:37 -0400 X-MC-Unique: 8-pj5rEAMrqWu7HQ6KiClA-1 Received: by mail-ed1-f71.google.com with SMTP id m3-20020a056402430300b004512f6268dbso3173008edc.23 for ; Sun, 11 Sep 2022 01:40:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:to:from:subject:message-id:x-gm-message-state:from :to:cc:subject:date; bh=lPP66SZjkXqzQ4ElXFxIwTMzdJhfAJNNP0E+pIoug/s=; b=d4WHOSY4/cqu7pPlujRjmM6XreAT20yXPBAMC8nLc2XZx18lu/Hsd+u9LN5yjeiMoc oGbwflaw+sQV7MjZx1SrAueZsFFByO2cE+xOn3tprEQzSrvvTP/npYADE8WKUGVSupFT nsnnH+gvVp4Fze50Pov9NeQ02t1JbYWgotuiN/r9Q6ZaYmZNVvV2XXP80QHhY6jnp+s1 zagYqXThE4TJJHx2XFruaYzC764V9iTX0nRBWFFZZ7f8YnEn6PTxO81TVaJOOkdVcJFW jAUkmvuF6qQ/mtefGGT1cDYtlUkoXIKjTu6ilgfPbRPY+/G2s0dXb9GGaUaKU/4CQxwI 6MWA== X-Gm-Message-State: ACgBeo3psnyM14oTr3wbD86ulndAHAK5i/Q3oE7GOvzhdfzSppNrs/er PafXWM8tla+0YuVaEW9w3v0ocOy7UtdeVY9rgEDuITOaYXl30eYGCPmajN+Nr94uOk6/DUAGtM0 hVY+4YGVrXmTKd2Sn+Q== X-Received: by 2002:a17:907:2724:b0:779:7545:5df6 with SMTP id d4-20020a170907272400b0077975455df6mr8419633ejl.325.1662885636461; Sun, 11 Sep 2022 01:40:36 -0700 (PDT) X-Google-Smtp-Source: AA6agR6dGdQXSbqu0NNE0x6m6p5VgLZXVuF5YzL/XMtlFfN8ZUkZmIvUVPm6nIs4TWzE5M4RYmrrcg== X-Received: by 2002:a17:907:2724:b0:779:7545:5df6 with SMTP id d4-20020a170907272400b0077975455df6mr8419622ejl.325.1662885636252; Sun, 11 Sep 2022 01:40:36 -0700 (PDT) Received: from t14s.localdomain ([82.141.252.179]) by smtp.gmail.com with ESMTPSA id e7-20020a170906314700b007708130c287sm2715832eje.40.2022.09.11.01.40.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 11 Sep 2022 01:40:35 -0700 (PDT) Message-ID: Subject: Re: [PATCH] analyzer: consider empty ranges and zero byte accesses [PR106845] From: David Malcolm To: Bernhard Reutner-Fischer , David Malcolm via Gcc-patches , Tim Lange Date: Sun, 11 Sep 2022 09:40:32 +0100 In-Reply-To: <2B5E71EE-0E60-4A19-9546-D0BA7377AD6D@gmail.com> References: <20220910221952.99541-1-mail@tim-lange.me> <359c4cd9b3afcaffd974883847073bc41aae3e4e.camel@redhat.com> <2B5E71EE-0E60-4A19-9546-D0BA7377AD6D@gmail.com> User-Agent: Evolution 3.44.4 (3.44.4-1.fc36) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-5.4 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,T_SCC_BODY_TEXT_LINE 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 Sun, 2022-09-11 at 10:21 +0200, Bernhard Reutner-Fischer wrote: > On 11 September 2022 10:04:51 CEST, David Malcolm via Gcc-patches > wrote: >=20 > > > +++ b/gcc/testsuite/gcc.dg/analyzer/pr106845.c > > > @@ -0,0 +1,11 @@ > > > +int buf_size; > > > + > > > +int > > > +main (void) > > > +{ > > > +=C2=A0 char buf[buf_size]; > > > + > > > +=C2=A0 __builtin_memset (&buf[1], 0, buf_size); > > > + > > > +=C2=A0 return 0; > > > +} > >=20 > > ...it took me a moment to realize that the analyzer "sees" that > > this is > > "main", and thus buf_size is 0. >=20 > Is this a valid assumption? Not always, but often. I suppose we could add an option for this. >=20 > What if I have a lib (preloaded maybe) that sets it to 42? ...or, say, a C++ ctor for a global object that runs before main, that has side-effects (see e.g. PR analyzer/97115). >=20 > BTW, do we handle -Wl,-init,youre_toast > where main isn't the entry point? The analyzer currently has no knowledge of this; it blithely assumes that no code runs before "main". It also doesn't report about "leaks" that happen when returning from main, whereas in theory someone could, say, implement the guts of their program in an atexit handler. I'm making assumptions in order to try to be more useful for the common cases, potentially at the expense of the less common ones. I'm not particularly familiar with the pre-main startup and post-main shutdown of a process; feel free to file a bug if you want -fanalyzer to be able to handle this kind of thing (links to pertinent docs would be helpful!) Thanks Dave >=20 > Just curious.. > thanks, >=20 > >=20 > > Interestingly, if I rename it to not be "main" (and thus buf_size > > could > > be non-zero), we still don't complain: > > =C2=A0https://godbolt.org/z/PezfTo9Mz > > Presumably this is a known limitation of the symbolic bounds > > checking? > >=20 > > Thanks > > Dave > >=20 >=20