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 BA63EA0A0C; Wed, 7 Apr 2021 13:48:56 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9DF55140E7E; Wed, 7 Apr 2021 13:48:56 +0200 (CEST) Received: from sender11-of-o51.zoho.eu (sender11-of-o51.zoho.eu [31.186.226.237]) by mails.dpdk.org (Postfix) with ESMTP id 684DE407FF for ; Wed, 7 Apr 2021 13:48:54 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; t=1617796121; cv=none; d=zohomail.eu; s=zohoarc; b=eUjtGh56R3RonoftYuwpEPLKhDVZRs76zvyL5CXpTS5dGtOGBTGYn2HbGdF3mQljvVV/jTQqs7FfFATMM/SH4xW7JvpZDPRA0prggflKNO9cK/cQ2BQpUXnoLYKhnpfuncaf64P8phe5+FDPEEGEFa48AlejxqU4QVdbnFhp/YA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.eu; s=zohoarc; t=1617796121; h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=j4/FSqo+BFq//D0Ch0Ql57qA2C9womZEarEYMkG3HUs=; b=iwbteru+e7zbP0A0eJ9TAyRARS3goBwyMV/7y0vKNY3Y4ObeH8auN8v/yUUKVtL6PHkKXXIw7xcAjGubDNLb004dY+ay1fQyma6KOV6HWhYCS/tKNqtg1wXgq99HB/O7Xbktn6lF5aX1ZUPujBJ4TSdDoUXMM6Aq7H7UJJqAJFQ= ARC-Authentication-Results: i=1; mx.zohomail.eu; spf=pass smtp.mailfrom=liangma@liangbit.com; dmarc=pass header.from= header.from= Received: from C02F33EJML85 (47.254.128.112 [47.254.128.112]) by mx.zoho.eu with SMTPS id 1617796118785616.8609662241547; Wed, 7 Apr 2021 13:48:38 +0200 (CEST) Date: Wed, 7 Apr 2021 12:48:36 +0100 From: Liang Ma To: Thomas Monjalon Cc: Ferruh Yigit , 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, bruce.richardson@intel.com Message-ID: References: <6114bde2-423a-da82-ac4d-608141235e39@huawei.com> <1672555.D3d3fyF7jD@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1672555.D3d3fyF7jD@thomas> X-ZohoMailClient: External 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 07, 2021 at 01:40:32PM +0200, Thomas Monjalon 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? Sure. Application control the lifetime cycle of the memory region. API impl can check it but everyone pay penalty(branch) as default. Let App developer make the decision is the best choice IMO.