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 AA54CA0579; Wed, 7 Apr 2021 16:40:57 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4A710406A3; Wed, 7 Apr 2021 16:40:57 +0200 (CEST) Received: from mail-qk1-f181.google.com (mail-qk1-f181.google.com [209.85.222.181]) by mails.dpdk.org (Postfix) with ESMTP id D9DC14013F for ; Wed, 7 Apr 2021 16:40:55 +0200 (CEST) Received: by mail-qk1-f181.google.com with SMTP id v70so18887128qkb.8 for ; Wed, 07 Apr 2021 07:40:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bpCXuL/IM4gGqwi9eTV4b24TVSZ5mqr3zDTQzpybXW8=; b=cx1iIt8S1OeoLAMz9w4x6hRdVpfWzT2RwGFmkxcPk8xjEc7vnAEFs6rfx/KDiQGuEZ 4BHFFFTgV4HnnaXwOruPamcs1K8Jr/jX2tagL5l1y8zOae2mYKPNqgn3Nd/04Uq8VgQ5 3FPEqP2FU1HQ3c8leo35DXw23mWMJ1WdwrXJo= 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=bpCXuL/IM4gGqwi9eTV4b24TVSZ5mqr3zDTQzpybXW8=; b=MsEhppAYtQbOioTTF8hgrFU+278OB0uVNXeF3c1P00wrcVpwZoU9nPF0nR2KKrNz40 EDnpjaEYUAnmKyX/2Yx3PFRaqK/l8jXNemY0c4NiaiyAoMU2koHXucvFXyd8lSq820MY 7+db8AONPGxej3a/0EvM8TSYd1wgblCeKf8Hs+ESPUgW3+1hTK2w7QJ5ChlpiBhnb1ah LA64j2Y741bU35gD0blAk5W5iN2UahXcedcJMzSF4zQWjVwM166PS6lSL71OJuwUQh5n /PebLmtnjTDw/UbKymEeTeuIZax68GyzKRdLMQKAWSmsb3umURnN4xnnqpGSZHg3GQqK CutQ== X-Gm-Message-State: AOAM532YcKlNgYjULSTNMKwPiIgmN/TjZIMc5T4Rd13Lk4LgcRGd6niV ZDMfKR6LGDUI5qXxroxsALBNB9ZQOGOmDADYEdjqdA== X-Google-Smtp-Source: ABdhPJzUnJliUWoePY+vZGlV9yOERYSzvjEPcnIccaG3BiSTfPoEmgGjDHoi/TDmBdfhF41hNOzfOTVGzBn1viJ8ZtA= X-Received: by 2002:a05:620a:14ac:: with SMTP id x12mr3418872qkj.409.1617806454959; Wed, 07 Apr 2021 07:40:54 -0700 (PDT) MIME-Version: 1.0 References: <6114bde2-423a-da82-ac4d-608141235e39@huawei.com> <1672555.D3d3fyF7jD@thomas> In-Reply-To: From: Ajit Khaparde Date: Wed, 7 Apr 2021 07:40:38 -0700 Message-ID: To: Jerin Jacob Cc: "Ananyev, Konstantin" , Thomas Monjalon , "Yigit, Ferruh" , Andrew Rybchenko , "Min Hu (Connor)" , "dev@dpdk.org" , "olivier.matz@6wind.com" , "david.marchand@redhat.com" , "jerinj@marvell.com" , "hemant.agrawal@nxp.com" , "Richardson, Bruce" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000018222c05bf62eb0b" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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" --00000000000018222c05bf62eb0b Content-Type: text/plain; charset="UTF-8" On Wed, Apr 7, 2021 at 6:20 AM Jerin Jacob wrote: > > 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 +1 But are we going to check all parameters? > > > > Konstantin > > > > --00000000000018222c05bf62eb0b--