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 784A8A0579; Wed, 7 Apr 2021 15:20:06 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0782B406A3; Wed, 7 Apr 2021 15:20:06 +0200 (CEST) Received: from mail-io1-f47.google.com (mail-io1-f47.google.com [209.85.166.47]) by mails.dpdk.org (Postfix) with ESMTP id 951184013F for ; Wed, 7 Apr 2021 15:20:04 +0200 (CEST) Received: by mail-io1-f47.google.com with SMTP id b10so19297464iot.4 for ; Wed, 07 Apr 2021 06:20:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TXZAfxFuTSFLL0N0uO8PCRsGm3dLDjWMP0DpTCr2uh8=; b=qyhJz9Eev7TYbTdtPkxfaCLhtUMUhrp6//7HhqKZcNSTvpPNjdpRttRJ8GxVuTWWT6 zOypNSn3gbqV0St5LMtkFo6QjGCrbxDC7FHRaxolK8AaN4oC5j8Y1zaHYCOnaXne8+nG RIkVVRIPinrmXZ5OZ1NgSz9YmAj3Vyd5bHeb9ERdZtA4yiGyoJbO3SjFSHFtI9Alhw6t bI4fVjJDb4o5XCnT6YhDK9qwt9y66FBcL1G7TZVo62DIg5zhGjiatNQoECMDu7dGBEPD ej7NBkfUg0u3DG5HroNR7S7YVFQahBxuHFMhFNdurSOBH2eQKN+hljTr+biXwYsSam3J JQlg== 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=TXZAfxFuTSFLL0N0uO8PCRsGm3dLDjWMP0DpTCr2uh8=; b=DRHq/gvDQ+2IEUMaUj0ITY46AUaQkYzzGpiXavfUXes4A/HZrVoSG+NFCJivKGcgOj k10lUlM29rW2oBdFNi5+iei6JI+cYAZQPQujDzrCzW8uXcdVdIebKoBdZZo9B52ZV9Ir vVq+Kjx+G5H8fyrODLID130sHbFkUevWCfTpkqnbc8dGUvH+RxQyHp3k08XMHIx5NFCf Z66rhqTjeXIazzUGlCGdatRyls4SNluJaW667mhDFSZP0lGJ6b1N8cz9DX6xKzx2vEka LKGBwSOXNO6Tlb0vNwu/ymFUOjk1a1r/Q1arKrcmvKh3YnXLIg4MXoOfJHeqV1pRGsAZ VoDQ== X-Gm-Message-State: AOAM533PuEvSkzZll9ZoLr9hUY617RD54C/T0FHxWdd+EoodhuWEUaE2 YV6BTn1gEMBsC1FcwjgWBPzns3hXnGGIsURRmzE= X-Google-Smtp-Source: ABdhPJwwS5T27KqEl6AjdyfOkYKTFpx8nDcU3qVqq5glTOqKyRycwpa4MU11ZRLY6vARL37Gylx79eFIQ6Pl77Ok4PU= X-Received: by 2002:a5d:9e03:: with SMTP id h3mr2583732ioh.94.1617801603926; Wed, 07 Apr 2021 06:20:03 -0700 (PDT) MIME-Version: 1.0 References: <6114bde2-423a-da82-ac4d-608141235e39@huawei.com> <1672555.D3d3fyF7jD@thomas> In-Reply-To: From: Jerin Jacob Date: Wed, 7 Apr 2021 18:49:47 +0530 Message-ID: To: "Ananyev, Konstantin" Cc: Thomas Monjalon , "Yigit, Ferruh" , Andrew Rybchenko , "Min Hu (Connor)" , "dev@dpdk.org" , "olivier.matz@6wind.com" , "david.marchand@redhat.com" , "jerinj@marvell.com" , "ajit.khaparde@broadcom.com" , "hemant.agrawal@nxp.com" , "Richardson, Bruce" Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] Questions about API with no parameter check 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 Sender: "dev" On Wed, Apr 7, 2021 at 5:23 PM Ananyev, Konstantin wrote: > > > > > 07/04/2021 13:28, Min Hu (Connor): > > > Hi, all, > > > Many APIs in DPDK does not check if the pointer parameter is > > > NULL or not. For example, in 'rte_ethdev.c': > > > int > > > rte_eth_rx_queue_setup(uint16_t port_id, uint16_t rx_queue_id, > > > uint16_t nb_rx_desc, unsigned int socket_id, > > > const struct rte_eth_rxconf *rx_conf, > > > struct rte_mempool *mp) > > > > > > int > > > rte_eth_link_get(uint16_t port_id, struct rte_eth_link *eth_link) > > > > > > int > > > rte_eth_stats_get(uint16_t port_id, struct rte_eth_stats *stats) > > > > > > int > > > rte_eth_dev_info_get(uint16_t port_id, struct rte_eth_dev_info *dev_info) > > > > > > As these APIs could be used by any APPs, if the APP give NULL as > > > the pointer parameter, segmetation default will occur. > > > > > > So, my question is, should we add check in the API? like that, > > > int rte_eth_stats_get(uint16_t port_id, struct rte_eth_stats *stats) > > > { > > > if (stats == NULL) > > > return -EINVAL; > > > ... > > > } > > > > > > Or, that is redundant, the parameter correctness should be guaranteed by > > > the APP? > > > > > > What's your opinion? Hope for your reply. > > > > I remember it has been discussed in the past (many years ago), > > and the opinion was to not clutter the code for something that > > is a basic fault from the app. > > > > I don't have a strong opinion. > > What is your opinion? Others? > > As I can see these are control path functions. > So some extra formal parameters check wouldn't hurt. > +1 from me to add them. +1 to add more sanity checks in control path APIs > Konstantin > >