On Tue, Feb 23, 2021 at 01:57:50AM +0300, Dmitry Kozlyuk wrote:

2021-02-22 14:26, Bruce Richardson:

quoted

As you say, though, the main issue will be whether we have instances in
public header files or not. I would hope that no static inline functions in
DPDK use any of the functions in question, but I'm not sure. Perhaps if
there are instances in public headers those could be reworked to not use
the problematic functions.

No instances of strdup(), strncasecmp(), or strtok_r() in any DPDK headers.

quoted

For any functions, such as strdup, which are not in a public header I would
suggest the following as a possible start point, based off what was done
for strlcpy.

* In DPDK (probably EAL), define an rte_strdup function for use as a
  fallback.
* Inside the meson build scripts, use "cc.has_function()" to check if the
  regular strdup function is available. If not, then add "-DRTE_NO_STRDUP"
  to the c_args for DPDK building
* Inside our DPDK header (rte_string_fns.h in the strdup case), we can add
  a conditional define such as:
   #ifdef RTE_NO_STRDUP
   #define strdup(s) rte_strdup(s)
   #endif

Thoughts on this?

Looks good to me, I can rework the patchset like so.

Policy considerations:
1. The approach only applies to platform-agnostic functions, like str*().
   Functions like sleep() still belong to librte_eal.
2. Deprecated functions, like index(3p), should be replaced
   with alternatives suggested by the standard.
3. If a standard C11 alternative is available, it should be used.
   This mostly applies to types, like u_int32 -> uint32_t
   (it's even in DPDK coding style already, isn't it?).

A nit: RTE_NO_XXX -> RTE_HAS_XXX (for consistency with existing macros)?

Sure, thanks.