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.kozl...@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
