Re: [dpdk-dev] [PATCH v2 1/7] eal: add wrappers for POSIX string functions

[Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>]

2021-02-22 14:26, Bruce Richardson:
> 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.

> 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)?