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

[Bruce Richardson]

On Sun, Feb 21, 2021 at 04:28:25AM +0300, Dmitry Kozlyuk wrote:
> POSIX strncasecmp(), strdup(), and strtok_r() have different names
> on Windows, respectively, strnicmp(), _strdup(), and strtok_s().
> 
> Add wrappers as inline functions, because they're used from librte_kvargs,
> and thus cannot be in librte_eal; besides, implementation is trivial.
> 
> Signed-off-by: Dmitry Kozlyuk <dmitry.kozliuk at gmail.com>
> ---
>  lib/librte_eal/common/eal_common_dev.c        |  6 +--
>  lib/librte_eal/common/eal_common_devargs.c    |  7 ++--
>  lib/librte_eal/common/eal_common_log.c        |  5 ++-
>  lib/librte_eal/common/eal_common_options.c    | 12 +++---
>  lib/librte_eal/common/eal_common_trace_ctf.c  |  2 +-
>  .../common/eal_common_trace_utils.c           |  2 +-
>  lib/librte_eal/include/rte_string_fns.h       | 42 +++++++++++++++++++
>  7 files changed, 60 insertions(+), 16 deletions(-)
> 
Rather than defining "rte_" versions of these functions, is it possible
just to provide the unprefixed definitions of them for internal use?
While this probably won't work for any functions used in public headers,
for any functions only used in C files, we can use meson to detect the
presence of the standard function and set a macro flag for the compatiblity
version if not present. This is something we already support for the
strlcpy/strlcat functions from libbsd, and it basically allows the
well-known (and loved?) functions to be used directly, and saves DPDK
developers having to worry about what "standard" functions can be used
directly, and which can't.

/Bruce