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

On Mon, Feb 22, 2021 at 12:48:39PM +0000, Nick Connolly wrote:

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.

   Hi Bruce,
   You're asking a really good question here that highlights a fundamental
   issue:
   Does the DPDK code base have an implied POSIX dependency, or should it
   only
   depend upon the standard C library and 'rte_ ' functions.  This hasn't
   been an
   issue before, but Windows isn't 'POSIX' based.
   Using "well-known" names for missing functions is ok where the
   definitions
   are in private header files, but if the headers are public, or the
   implementation
   is better done in a C file, then there can be a clash with the
   application which
   is likely dealing with the same issues.
   There seem to be two viable approaches to handling this:
    1. Expect the platform to provide POSIX semantic (through an external
       library
       such as Cygwin). That way it becomes "an 'external' problem" and
       the DPDK
       can use the "well-known" names and expected behaviour.
    2. Provide the missing functionality, but wrap it in 'internal' header
       files
       and 'rte_' versions to avoid link errors. This is the approach that
       Dmitry has
       taken based on the guidance we've received.

   For background, the approach I've taken with adding Windows support to
   SPDK
   is to create an 'external' library ([1]https://wpdk.github.io) with
   header files that
   provide the missing POSIX functionality and functions with a prefix to
   avoid link
   errors. As a result, the whole of SPDK can now build and run unchanged.
   Regards,
   Nick

Whatever about the specific implementation, I'd very much like to get to
the point where we don't have to do search-replace for a bunch of functions
like this, not to mention that we'd need to have checkpatch rules in place
to ensure that further instances are not re-introduced.
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.

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?
/Bruce