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 A3F73A0547; Thu, 29 Apr 2021 20:49:28 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2110E410DF; Thu, 29 Apr 2021 20:49:28 +0200 (CEST) Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com [209.85.208.181]) by mails.dpdk.org (Postfix) with ESMTP id 5EBA7410DD for ; Thu, 29 Apr 2021 20:49:26 +0200 (CEST) Received: by mail-lj1-f181.google.com with SMTP id u25so39373064ljg.7 for ; Thu, 29 Apr 2021 11:49:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=6lkwUs6DnwJ3Q3oo7qjUcI3m6g2gl9FSsvKbbkVCJHE=; b=eY2QP6bOgarvfwoyxw5R/mS7Vk/iazQp/qlBuD80haZEZhbzKXO0fKEoD0DAXaOgcr eAjBjaOkRhH6ybT0Ge5z2DYEleut34noi+imB1EyikcKABXylrGZNTIOOyrBi4zvf75E wQLvZBSERLOb4LCAUPZ9hlWMRbTRBMP2muEu/afd8KmyVb+2KaPx0nV+6gsskHAGh4MQ c+SzectVwa6T9VvZ7wdfwWR5U1h3XBb4Tiq71CXoxV8pJWd6OyYGg1XnWl3f/SXlwTIh Q4cTyY6i8MmLkdrWc58C2i6BSaAEiQf9KxBHcepNCyMAfkcpgvkyopiZOd4LM64YC8hf 096A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=6lkwUs6DnwJ3Q3oo7qjUcI3m6g2gl9FSsvKbbkVCJHE=; b=DX0zxe06jHyvKJ+afJn9IPpBc/a3rVMKYR0pIqgx4Fzv2ywMo7DGMPZCAfpb8eHu4h OMODrP/fdpy6LQmAGrqRdXJjp/LpSpEavpsZLPGc58ymCDgprMLbJq8RfKpUoTHAXzk0 CTy0+VDnuOS9UAs0hc9Emt6wYUaXVF/ALkhGW9FIN8VPXA44qeiUNZ0xB+0l7SDDhbM+ qPhYpHbY1jRTjol4dpfo7wKl3cdroGKxoYaKkVUwew/FEKvv6zJetaFhTV+Mg7eIhMMT e7QSEvBnv4mzEK2XrmpGOOgQEwR9tzhP4d/7BCnPyiYuIRusXxK+uauWX9hfIVaJdbLD zstw== X-Gm-Message-State: AOAM531/bUUmOD5dZLvdk+FkqXfOzWdNFAEf4919S8TeM0Qf0bB1ho5N Q8+HOEGLYhK+i935rM9TNkM= X-Google-Smtp-Source: ABdhPJx1ZlnxOV3Gx/X7oYX5WxORIC6HbXn91U9qkmmj/IUBB4Vw2mV6Y4HQbuLS5dqxiDIwzYJ6Bw== X-Received: by 2002:a05:651c:3c3:: with SMTP id f3mr812374ljp.302.1619722165934; Thu, 29 Apr 2021 11:49:25 -0700 (PDT) Received: from sovereign (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.gmail.com with ESMTPSA id t12sm56975lfe.33.2021.04.29.11.49.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Apr 2021 11:49:25 -0700 (PDT) Date: Thu, 29 Apr 2021 21:49:24 +0300 From: Dmitry Kozlyuk To: Tyler Retzlaff Cc: Ferruh Yigit , hemant.agrawal@nxp.com, Ajit Khaparde , Jerin Jacob , "Ananyev, Konstantin" , Thomas Monjalon , Andrew Rybchenko , "Min Hu (Connor)" , "dev@dpdk.org" , "olivier.matz@6wind.com" , "david.marchand@redhat.com" , "jerinj@marvell.com" , "Richardson, Bruce" Message-ID: <20210429214924.308a636b@sovereign> In-Reply-To: <20210429161645.GB21799@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <6114bde2-423a-da82-ac4d-608141235e39@huawei.com> <1672555.D3d3fyF7jD@thomas> <39bb5d09-9e95-db2d-929f-b0b3e922d921@oss.nxp.com> <68bb19fb-2d1a-677d-05f2-e2029d5095a5@intel.com> <20210429161645.GB21799@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> X-Mailer: Claws Mail 3.17.6 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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" 2021-04-29 09:16 (UTC-0700), Tyler Retzlaff: > 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. As library developers we can't assume stability requirements at call site. There may be temporary files to clean up, for example, or other threads in the middle of their work. As an application developer I'd hate to get a crash inside a library and having to debug it. Usually installed are release versions with assertions compiled away. Log formatting is the only point I agree with, but it's another huge topic.