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

[Bruce Richardson <bruce.richardson@intel.com>]

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