From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 121A2A04AD; Mon, 24 Jan 2022 18:23:28 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 946FD41163; Mon, 24 Jan 2022 18:23:27 +0100 (CET) Received: from mail-pj1-f49.google.com (mail-pj1-f49.google.com [209.85.216.49]) by mails.dpdk.org (Postfix) with ESMTP id B32D240040 for ; Mon, 24 Jan 2022 18:23:26 +0100 (CET) Received: by mail-pj1-f49.google.com with SMTP id nn16-20020a17090b38d000b001b56b2bce31so459172pjb.3 for ; Mon, 24 Jan 2022 09:23:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=Y/d1PfcbGwF/glN80NH2I+nQEVaLVT9oxSK1eo69idA=; b=wBCLQV+jPiDamNdna5Kg54vzEQ8L36UJUV/JIoNYggGFUzJxnyfySV5j0fCcXC0iIe UXxaemx0YXhum7Z8NNweaWw0JyHlqeQcKpz8yDN2OK3ua4O6XKoXPkyOu+2km2DSIry3 SIoGpvhSFFCjNTO0dKzHfzbH8Nw2wEqCd8WYPbvia/8tY9FCAfdruQ8FfleLyJzDjGyr LZ84CorEfEVq0huh8b597CfrIpJ5CHrMnUk+mGkRiTEZLuZHNjucof7gJUxtrTn0g2nT KIntaJPYia7BRtBU8lwDxRqoNS7hXznFsOb5FFSA4CCf7domFOD+9HR0nFQzPUltuNjx sGXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=Y/d1PfcbGwF/glN80NH2I+nQEVaLVT9oxSK1eo69idA=; b=LxvSCNUmXpp0Qj/O0RUrjxpcVCaU6sLpxx/4GDvl4za+qTKiRn/RH7Sa46QbdAcf+t OooFJH3/MOjnn3kcMxcb4ytaWSXMczt+xrPbWtnSSMBxYQNs2CXp4Fj9C+X7zTVXcZr3 MuptpG9wWVQZW4T+DPTUg9jGFZq7GCfEkha+1zf6FrsXFpw7vp27G1f5OGAuHeSjAnxj OLHQqgWrX2/xdcXJZQGnld1mTzP+nCf7qxCeIfhRcSJw3FrjyuWjg2Y/lzCvn/oxP83K NKNMyzYL3fSBnkH34wHYiCqgc+kMSLn7vEcDJwUdrEROdBJwk8zDKPbxOtxfID77B0JX Vk8g== X-Gm-Message-State: AOAM531z0XscqjxEMmexd+1axDy1a6YNzRyORUIAoE2G/8rqDd/CyUS+ 6dkS4FG7mPCNJLRJlac5VXLCgEU7gRDN0w== X-Google-Smtp-Source: ABdhPJwdbRKGY9O6+PEpy+a9/lXz0lOLXSyfE0PgcbZI25ZAPSRhgeDL1/Ong+BhAA7MNtO5IvuCjg== X-Received: by 2002:a17:902:f54b:b0:14b:1651:58ca with SMTP id h11-20020a170902f54b00b0014b165158camr15624064plf.58.1643045005927; Mon, 24 Jan 2022 09:23:25 -0800 (PST) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id l12sm17860815pfc.182.2022.01.24.09.23.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Jan 2022 09:23:25 -0800 (PST) Date: Mon, 24 Jan 2022 09:23:23 -0800 From: Stephen Hemminger To: "Dumitrescu, Cristian" Cc: "dev@dpdk.org" Subject: Re: [PATCH 05/82] examples/ip_pipeline: remove unnecessary NULL checks Message-ID: <20220124092323.6e3efc2c@hermes.local> In-Reply-To: References: <20220124000518.319850-1-stephen@networkplumber.org> <20220124000518.319850-6-stephen@networkplumber.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Mon, 24 Jan 2022 10:17:23 +0000 "Dumitrescu, Cristian" wrote: > > -----Original Message----- > > From: Stephen Hemminger > > Sent: Monday, January 24, 2022 12:04 AM > > To: dev@dpdk.org > > Cc: Stephen Hemminger ; Dumitrescu, > > Cristian > > Subject: [PATCH 05/82] examples/ip_pipeline: remove unnecessary NULL > > checks > > > > Remove redundant NULL pointer checks before free functions > > found by nullfree.cocci > > > > Signed-off-by: Stephen Hemminger > > --- > > examples/ip_pipeline/cli.c | 12 ++++-------- > > examples/ip_pipeline/cryptodev.c | 6 ++---- > > examples/ip_pipeline/thread.c | 6 ++---- > > 3 files changed, 8 insertions(+), 16 deletions(-) > > > > Hi Stephen, > > The rte_ring_free() and rte_mempool_free() do not state in their API description that freeing a NULL pointer is harmless. Before pushing these changes, please add the necessary note in the API header files for these functions. Okay, will fix the documentation then. The implemeentation has always done the right thing. > In the absence of the clear note in their API description, the user is forced to check for the NULL pointer. I agree that the implementation of these functions does the right think and exits early when the input pointer is NULL, but there is no guarantee that the implementation is not going to change. Agree? No. I don't agree. All XXX_free() functions should accept NULL and handle it in the same way. Any inconsistency is an obvious source of bugs. > > The stdlib free() and the rte_free() do have the clear API description note that freeing a NULL object is harmless, so removing the NULL check before their call is indeed safe. Will add first patch to fix the documentation to match the current implementation.