From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 188F4A0547;
	Thu, 29 Apr 2021 18:16:48 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 8E15C410F1;
	Thu, 29 Apr 2021 18:16:47 +0200 (CEST)
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
 by mails.dpdk.org (Postfix) with ESMTP id 06CBE410DD
 for <dev@dpdk.org>; Thu, 29 Apr 2021 18:16:45 +0200 (CEST)
Received: by linux.microsoft.com (Postfix, from userid 1086)
 id 2B54B20B8000; Thu, 29 Apr 2021 09:16:45 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 2B54B20B8000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
 s=default; t=1619713005;
 bh=/j4BBqBdxHwlZRvJVF012lSR417Iy2fdDR4Wa5GSOBw=;
 h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
 b=I3sXbfCVapMqkWZQoDivBM00aiCX52BtVLOmMuG7xc0RHRQUEQcuNqt+ox2Mg184F
 dk4CX+PSYfmW6wBFLeOaBEwXWZSUgwp3oajfQgjaPu2XXbdS5KI0qvn72MHt5JiqEd
 sF9YdipXO/Cp4vBAqpRG6tob8xWC8pxQGTO/EVdY=
Date: Thu, 29 Apr 2021 09:16:45 -0700
From: Tyler Retzlaff <roretzla@linux.microsoft.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>
Cc: hemant.agrawal@nxp.com, Ajit Khaparde <ajit.khaparde@broadcom.com>,
 Jerin Jacob <jerinjacobk@gmail.com>,
 "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
 Thomas Monjalon <thomas@monjalon.net>,
 Andrew Rybchenko <Andrew.Rybchenko@oktetlabs.ru>,
 "Min Hu (Connor)" <humin29@huawei.com>, "dev@dpdk.org" <dev@dpdk.org>,
 "olivier.matz@6wind.com" <olivier.matz@6wind.com>,
 "david.marchand@redhat.com" <david.marchand@redhat.com>,
 "jerinj@marvell.com" <jerinj@marvell.com>,
 "Richardson, Bruce" <bruce.richardson@intel.com>
Message-ID: <20210429161645.GB21799@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
References: <6114bde2-423a-da82-ac4d-608141235e39@huawei.com>
 <1672555.D3d3fyF7jD@thomas>
 <DM6PR11MB44917D38667EB1A6B2E5F0BA9A759@DM6PR11MB4491.namprd11.prod.outlook.com>
 <CALBAE1MY4ijoJqzCeaS+Ud-X0LQ1BzX8ypbVW043GJgcyUZEiQ@mail.gmail.com>
 <CACZ4nhuqA3g5UCKS=sDT34rK-r6yP4fOwtPC7NdFKwpUn8+FuQ@mail.gmail.com>
 <39bb5d09-9e95-db2d-929f-b0b3e922d921@oss.nxp.com>
 <68bb19fb-2d1a-677d-05f2-e2029d5095a5@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <68bb19fb-2d1a-677d-05f2-e2029d5095a5@intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On Wed, Apr 07, 2021 at 05:10:00PM +0100, Ferruh Yigit wrote:
> On 4/7/2021 4:25 PM, Hemant Agrawal wrote:
> >>+1
> >>But are we going to check all parameters?
> >
> >+1
> >
> >It may be better to limit the number of checks.
> >
> 
> +1 to verify input for APIs.
> 
> Why not do all, what is the downside of checking all input for control path APIs?

why not assert them then, what is the purpose of returning an error to a
caller for a api contract violation like a `parameter shall not be NULL`

* assert.h/cassert can be compiled away for those pundits who don't want
  to see extra branches in their code

* when not compiled away it gives you an immediate stack trace or dump to operate
  on immediately identifying the problem instead of having to troll
  through hoaky inconsistently formatted logging.

* it catches callers who don't bother to check for error from return of
  the function (debug builds) instead of some arbitrary failure at some
  unrelated part of the code where the corrupted program state is relied
  upon.

we aren't running in kernel, we can crash.