From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <xry111@mengyan1223.wang>
Received: from mengyan1223.wang (mengyan1223.wang [89.208.246.23])
 by sourceware.org (Postfix) with ESMTPS id 467F13850428
 for <gcc-help@gcc.gnu.org>; Wed, 16 Jun 2021 13:36:47 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 467F13850428
Received: from [192.168.124.4] (unknown [124.115.222.147])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest
 SHA384) (Client did not present a certificate)
 (Authenticated sender: xry111@mengyan1223.wang)
 by mengyan1223.wang (Postfix) with ESMTPSA id 00B496626D;
 Wed, 16 Jun 2021 09:36:44 -0400 (EDT)
Message-ID: <4dd0f2168668d9d3dd919df6088d0dea4cfe0bb5.camel@mengyan1223.wang>
Subject: Re: gcc warn when pointers not checked non-null before de-referencing.
From: Xi Ruoyao <xry111@mengyan1223.wang>
To: Jonny Grant <jg@jguk.org>, gcc-help <gcc-help@gcc.gnu.org>
Date: Wed, 16 Jun 2021 21:36:38 +0800
In-Reply-To: <0770e060-6388-fc27-1178-205b867bfae2@jguk.org>
References: <0a9ccbb7-135a-b342-e5cb-35b7c6a44a00@jguk.org>
 <97eb7315fd136ff8a818925b1704760a856ffe64.camel@mengyan1223.wang>
 <0770e060-6388-fc27-1178-205b867bfae2@jguk.org>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.40.2 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-3031.8 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, JMQ_SPF_NEUTRAL, SPF_HELO_PASS,
 SPF_PASS, TXREP autolearn=no 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-help@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-help mailing list <gcc-help.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-help>,
 <mailto:gcc-help-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-help/>
List-Post: <mailto:gcc-help@gcc.gnu.org>
List-Help: <mailto:gcc-help-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-help>,
 <mailto:gcc-help-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Jun 2021 13:36:48 -0000

On Wed, 2021-06-16 at 14:01 +0100, Jonny Grant wrote:

> Chris Latner also mentioned integer overflow being undefined, that
> crops up too. There's no easy solution right, we need to hand write
> code the checks?  It's human-error prone if we need to manually code
> each check. throwing in C++, or handling in C.
> 
> if(N >= INT_MAX)
> {
>     throw std::overflow_error("N >= INT_MAX would overflow in for
> loop");
> }
> 
> for (i = 0; i <= N; ++i)
> {
> // ...
>  }

For debugging use -fsanitize=undefined.

And this is buggy anyway, no matter if there is an UB:

for (unsigned i = 0; i <= N; i++)
    make_some_side_effect_without_any_undefined_behavior(i);

If N may be UINT_MAX, this is not UB, but a dead loop. Programming is
just human-error prone, even if you use "some programming language
claimed to be able to eliminate many human errors" (I'll not say its
name, to prevent a flame war).
-- 
Xi Ruoyao <xry111@mengyan1223.wang>
School of Aerospace Science and Technology, Xidian University