On 4/7/2021 8:10 PM, Ajit Khaparde wrote:
On Wed, Apr 7, 2021 at 6:20 AM Jerin Jacob <jerinjac...@gmail.com> wrote:
On Wed, Apr 7, 2021 at 5:23 PM Ananyev, Konstantin
<konstantin.anan...@intel.com> 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?
+1
It may be better to limit the number of checks.
Konstantin
