From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id 8FFC83857025 for ; Sat, 3 Jul 2021 16:23:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8FFC83857025 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 163GMqEl022906; Sat, 3 Jul 2021 11:22:52 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 163GMqkS022905; Sat, 3 Jul 2021 11:22:52 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Sat, 3 Jul 2021 11:22:52 -0500 From: Segher Boessenkool To: Jonny Grant Cc: Xi Ruoyao , gcc-help Subject: Re: gcc warn when pointers not checked non-null before de-referencing. Message-ID: <20210703162252.GI1583@gate.crashing.org> References: <0a9ccbb7-135a-b342-e5cb-35b7c6a44a00@jguk.org> <97eb7315fd136ff8a818925b1704760a856ffe64.camel@mengyan1223.wang> <0770e060-6388-fc27-1178-205b867bfae2@jguk.org> <20210616175941.GJ5077@gate.crashing.org> <80eacded-aa7d-52c1-1fd4-6ec1a987c311@jguk.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80eacded-aa7d-52c1-1fd4-6ec1a987c311@jguk.org> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, TXREP, T_SPF_HELO_PERMERROR, T_SPF_PERMERROR autolearn=no 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: Sat, 03 Jul 2021 16:23:54 -0000 On Sat, Jul 03, 2021 at 03:14:21PM +0100, Jonny Grant wrote: > We'd rather have stability and logging of errors than a core dump. Especially on embedded systems that need to guarantee safety. It's easy enough to check for NULL and check the bounds of buffers etc before using. Asserts would trigger in a debug build. There *is* no generic way you can sanely and even safely handle null pointer dereferences at all. You *have to* separately write code for every place you want to do something special with null pointers (or any other special case for that matter). In case you are talking about a system with an event loop (or similar), where you can just abort the task you are doing, and get back to waiting for more work to do: you can just catch *all* fatal errors (which a null dereference normally is), log it, and go back to the main loop. But even then the null dereference could be caused by something that is not yet fixed. If you are lucky other tasks can still be done. OTOH, perhaps just as often nothing will work anymore. In any case, there is nothing the compiler can do for you here. If programming were a mechanical job, we wouldn't need all those pesky programmers :-) Segher