On Wed, Apr 7, 2021 at 6:20 AM Jerin Jacob wrote: > > On Wed, Apr 7, 2021 at 5:23 PM Ananyev, Konstantin > wrote: > > > > > > > > > 07/04/2021 13:28, Min Hu (Connor): > > > > Hi, all, > > > > Many APIs in DPDK does not check if the pointer parameter is > > > > NULL or not. For example, in 'rte_ethdev.c': > > > > int > > > > rte_eth_rx_queue_setup(uint16_t port_id, uint16_t rx_queue_id, > > > > uint16_t nb_rx_desc, unsigned int socket_id, > > > > const struct rte_eth_rxconf *rx_conf, > > > > struct rte_mempool *mp) > > > > > > > > int > > > > rte_eth_link_get(uint16_t port_id, struct rte_eth_link *eth_link) > > > > > > > > int > > > > rte_eth_stats_get(uint16_t port_id, struct rte_eth_stats *stats) > > > > > > > > int > > > > rte_eth_dev_info_get(uint16_t port_id, struct rte_eth_dev_info *dev_info) > > > > > > > > As these APIs could be used by any APPs, if the APP give NULL as > > > > the pointer parameter, segmetation default will occur. > > > > > > > > So, my question is, should we add check in the API? like that, > > > > int rte_eth_stats_get(uint16_t port_id, struct rte_eth_stats *stats) > > > > { > > > > if (stats == NULL) > > > > return -EINVAL; > > > > ... > > > > } > > > > > > > > Or, that is redundant, the parameter correctness should be guaranteed by > > > > the APP? > > > > > > > > What's your opinion? Hope for your reply. > > > > > > I remember it has been discussed in the past (many years ago), > > > and the opinion was to not clutter the code for something that > > > is a basic fault from the app. > > > > > > I don't have a strong opinion. > > > What is your opinion? Others? > > > > As I can see these are control path functions. > > So some extra formal parameters check wouldn't hurt. > > +1 from me to add them. > > +1 to add more sanity checks in control path APIs +1 But are we going to check all parameters? > > > > Konstantin > > > >