On Mon, 24 Jan 2022 10:17:23 +0000 "Dumitrescu, Cristian" <cristian.dumitre...@intel.com> wrote:
> > -----Original Message----- > > From: Stephen Hemminger <step...@networkplumber.org> > > Sent: Monday, January 24, 2022 12:04 AM > > To: dev@dpdk.org > > Cc: Stephen Hemminger <step...@networkplumber.org>; Dumitrescu, > > Cristian <cristian.dumitre...@intel.com> > > Subject: [PATCH 05/82] examples/ip_pipeline: remove unnecessary NULL > > checks > > > > Remove redundant NULL pointer checks before free functions > > found by nullfree.cocci > > > > Signed-off-by: Stephen Hemminger <step...@networkplumber.org> > > --- > > examples/ip_pipeline/cli.c | 12 ++++-------- > > examples/ip_pipeline/cryptodev.c | 6 ++---- > > examples/ip_pipeline/thread.c | 6 ++---- > > 3 files changed, 8 insertions(+), 16 deletions(-) > > > > Hi Stephen, > > The rte_ring_free() and rte_mempool_free() do not state in their API > description that freeing a NULL pointer is harmless. Before pushing these > changes, please add the necessary note in the API header files for these > functions. Okay, will fix the documentation then. The implemeentation has always done the right thing. > In the absence of the clear note in their API description, the user is forced > to check for the NULL pointer. I agree that the implementation of these > functions does the right think and exits early when the input pointer is > NULL, but there is no guarantee that the implementation is not going to > change. Agree? No. I don't agree. All XXX_free() functions should accept NULL and handle it in the same way. Any inconsistency is an obvious source of bugs. > > The stdlib free() and the rte_free() do have the clear API description note > that freeing a NULL object is harmless, so removing the NULL check before > their call is indeed safe. Will add first patch to fix the documentation to match the current implementation.
