Re: [dpdk-dev] Questions about API with no parameter check

[Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>]

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.