[dpdk-dev] [PATCH v2 1/7] eal: add wrappers for POSIX string functions
Dmitry Kozlyuk
dmitry.kozliuk at gmail.com
Mon Feb 22 23:57:50 CET 2021
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)?
More information about the dev
mailing list