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

["Ananyev, Konstantin" <konstantin.ananyev@intel.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.

I agree with Dmitry summary above.
Asserting inside the library calls is bad programming practice,
please keep it away from the project. 

> 
> Log formatting is the only point I agree with, but it's another huge topic.