From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) by sourceware.org (Postfix) with ESMTPS id E1418384F00B for ; Tue, 6 Jul 2021 10:33:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E1418384F00B 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-wm1-x331.google.com with SMTP id j39-20020a05600c1c27b029020028e48b8fso1368659wms.0 for ; Tue, 06 Jul 2021 03:33:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jguk.org; s=google; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=1pPMtDERun1N2Uv966HWOFozvrObPjD8154HQ97upl0=; b=GhkHxkEmroWKdeVSrn01jLtxoTcHIzVSF1y42rRsAHdLqNH1TNx0oQ8lEq0FUpn4NZ LQUHJXMqQA+fNZ5+aweF/N7a4YLgFMW62KpiuhuS75eiEbcUq6VokR5qXVqtbKZi+N54 wVazBHKJ9FRYDjgmywpnBf2oQIfUOaVqDBP3zlqIsh06jh3l8PKlpAH4/x5S+K+Em7hU pHOANgik3YgVQ4O4wJwWruXW2pZ7NLxTjFlHzXO6qRGxhf4Rn7WtY4TOE/TF4bmHDFop xkhGZlmnCeifVTkZG4JvJwWIAwUxTx6YMZlr5yw2iUDO4O/F8VmTU66bpY5n8ElkWobY aWSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=1pPMtDERun1N2Uv966HWOFozvrObPjD8154HQ97upl0=; b=DcoXa0Y/WK8/Hsvp05m8TyFQ4+LOxoPGCCUbuKu/S3xXtqayX/QVtlPxRPXcdMH3YH BvOyw/llG6rogi/VO6yd53xzODJBbbsmXrysLkQvdsbd5PYsm+/JmgQvklyeZ5+o3VAp p6IqDpeiI9BuWU9tqyDehXOB4p8tFAYnt52ELz1RVbNlsn/WsN64D5NuYH3u/4fTjbdy MAygDl9CkqKeBihGmklwv0ikuxEK2FJenkNmg1xdoQDvANtSDD4CvKvdLfSI1jiVAJqU 0iBFJV8UJHZY83EUqbc1aQlpcbnd8H+2KZZo/sbuqK21YUFktXC3ma8M7mmgP9q8zkPP hJ/Q== X-Gm-Message-State: AOAM530dJCnUcHvN4+ah45gAAq1OdlGEgC84h+J7SmpklwmFwOIhzCXd revecnSv6NjTUWJuT1paX8Qyl4VPKoC4ZA== X-Google-Smtp-Source: ABdhPJxM0dMpU/tulNk7EaYY0rw4clWeO05Jtd69g1ex1DDnzpDwX27SSeLsDpUoVoImqzqwU6e4+w== X-Received: by 2002:a05:600c:221a:: with SMTP id z26mr20201520wml.45.1625567601889; Tue, 06 Jul 2021 03:33:21 -0700 (PDT) Received: from [192.168.0.12] (cpc87345-slou4-2-0-cust172.17-4.cable.virginm.net. [81.101.252.173]) by smtp.gmail.com with ESMTPSA id n12sm18171974wmq.5.2021.07.06.03.33.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jul 2021 03:33:21 -0700 (PDT) From: Jonny Grant Subject: Re: gcc warn when pointers not checked non-null before de-referencing. To: Segher Boessenkool Cc: Xi Ruoyao , gcc-help 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> <20210703162252.GI1583@gate.crashing.org> Message-ID: Date: Tue, 6 Jul 2021 11:33:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210703162252.GI1583@gate.crashing.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, 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: Tue, 06 Jul 2021 10:33:24 -0000 On 03/07/2021 17:22, Segher Boessenkool wrote: > 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. Yes, you are quite right! The error could be handled by the calling code, or logged for later debugging use, and hopefully for a safety critical system it continues to run. In some instances we would restart that module after a recurring error, and use a watchdog thread to reboot if something severe that can't be recovered on an overall system. An example would be as follows sample function: int component_msg(unsigned int component, const char * msg) { if(NULL == msg) { log_msg("component_msg component %d called with NULL msg\n", component); return EFAULT; } else { log_msg("%s", msg); return 0; } } The calling code could also check the return of component_msg() and handle some appropriate way. Restarting the module, notifying another system, ignoring a faulty device etc > > 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 > Cheers, Jonny