From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) by sourceware.org (Postfix) with ESMTPS id E4E55384F03F for ; Mon, 19 Jul 2021 18:20:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E4E55384F03F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=jguk.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=jguk.org Received: by mail-lf1-x12b.google.com with SMTP id v6so31784640lfp.6 for ; Mon, 19 Jul 2021 11:20:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jguk.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0ajPFxVQKi/Y/aIXvNlRZ917rlRorl6Yh0H3R+RzUJQ=; b=a7j1g/FpOzD4oZ999Y0Jh8RHMmNMfpbe7dt95DYHItqYHlsHgS+eoaAh+9k/yqJ/iz koohv986zLkq4GuLilDkHL9cdSmlGDKDH7x/OCCdWpMPhHWlTCPo7QCR6Ffa+V+0m9m4 9ANub973qzQx8wA0H06Wxh8IDw8UgdamXC+vynBQu9hPftqb/9G2FM4x6uXLANCAZBDo B+dFL3ZisWXPOUEtb1rV5HgmixbIh9STTqzF6moJj0CzP/qUy7jroUPnQW8tMAIS+ARv ZplY0UiS5DVm1GiTbZtG5NKd2AOuU49gJDFQMiwwNsy6/MgeZ1/VNXgmlAQkxxHj8BGi 7oNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0ajPFxVQKi/Y/aIXvNlRZ917rlRorl6Yh0H3R+RzUJQ=; b=aZ+ncp8Pq+KSNj6eRUUZM8L1PC8dD7B5A2tS6rXgTAwqSN+3RuR0tzQkpcCzXNKDuy hxxdULgzf29apw1QoaOrmFjcnwLhzFCAvXmnuDvONIcfzr9lm1Ex3EZVw/MphCmOMVkt t9hHUvWTtqHIRDjBKdBGbUvBJlaOWkV+C6CI+kNzqex1TnhPP0pplwfApnQZkmkk/NSZ WnucYz3NWMiE6Nh/SZwNHqem6B/yWyKnDlxwupx2Pa2P5nzpyc89MCso3GE4DdFcSG91 DfkTgLEtW/xd1J4vtybEKk3IykDv+KtkIfZIDIS3+KtdZcCCpMSfCppcf7K721UkdFh4 79ug== X-Gm-Message-State: AOAM533Y+JTMnBADVzrf8FhgK1BKBiLAjbSf3Z6oz5vParzpC5wXmHhe wDibHAgNTc54chC+SvwG8Zk0ddDoXQNgpdm8+ixfQRPggZRx3A== X-Google-Smtp-Source: ABdhPJwrkijDa4eXROntLIUK1jQom38LMjXfsxJCFn53pxiAqEcqCKeOKK1aV3eDIyYJc69T+EWCdof5hJok5bxYW2o= X-Received: by 2002:a05:6512:143:: with SMTP id m3mr19375073lfo.241.1626718822437; Mon, 19 Jul 2021 11:20:22 -0700 (PDT) MIME-Version: 1.0 References: <0a9ccbb7-135a-b342-e5cb-35b7c6a44a00@jguk.org> <97eb7315fd136ff8a818925b1704760a856ffe64.camel@mengyan1223.wang> <0770e060-6388-fc27-1178-205b867bfae2@jguk.org> <4dd0f2168668d9d3dd919df6088d0dea4cfe0bb5.camel@mengyan1223.wang> <45a96f3c-5058-e8c4-08f0-d0c62fb27f1c@jguk.org> <1976cf6269261bb38cce5b3a8f59a681e0bc2444.camel@mengyan1223.wang> In-Reply-To: <1976cf6269261bb38cce5b3a8f59a681e0bc2444.camel@mengyan1223.wang> From: Jonny Grant Date: Mon, 19 Jul 2021 19:20:11 +0100 Message-ID: Subject: Re: gcc warn when pointers not checked non-null before de-referencing. To: Xi Ruoyao Cc: gcc-help Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, 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-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2021 18:20:25 -0000 On Tue, 6 Jul 2021 at 16:39, Xi Ruoyao wrote: > > On Sat, 2021-07-03 at 16:36 +0100, Jonny Grant wrote: > > > > > > On 16/06/2021 14:36, Xi Ruoyao wrote: > > > 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). > > > > > Hi Xi > > > > > > Checking the UINT_MAX would at least prevent the continual running of > > any such buggy loop where it increments right? and the code within the > > loop does not modify 'i' > > > > for (unsigned i = 0; (i <= N) && (i != UINT_MAX); i++) > > make_some_side_effect_without_any_undefined_behavior(i); > > Even if i is signed, it will still "work" if you modify the && > expression a little: > > for (int i = 0; i != UINT_MAX && i < N; i++) > make_some_side_effect_without_any_undefined_behavior(i); > > The problem is, now the behavior when N == UINT_MAX is same with when N > == (UINT_MAX - 1). This can really puzzle someone who will call your > function. > > If I'm designing this function I'd make it to interpret N as [0, N), > instead of [0, N]: > > // Do something for each integer in [0, N). > void do_something(int N) > { > for (int i = 0; i < N; i++) > do_something_once(i); > } That's good, specify the limit. > > > Is there any way to have a way to make loop variables like this 'i' > > const within the body of the loop, to avoid accidental changing of 'i' > > by the body of the loop > > I don't think there is one in C. Perhaps, maybe use some "nasty" > macros. Probably I could use this pattern to avoid the risk of code modifying the loop counter by accident. for (int loop_var = 0; loop_var < N; loop_var++) { const int i = loop_var; printf("i: %d\n", i); } Jonny