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

[Dmitry Kozlyuk]

2021-03-01 21:31, Nick Connolly:
> > There's a meson issue with `cc.has_function()`:
> > https://github.com/mesonbuild/meson/issues/5628
> >
> > What if we just define RTE_INTERNAL for librte_eal/windows/include/rte_os.h
> > (and other public headers if need be) to distinguish the case when it's used
> > from within DPDK?  
> It's a pragmatic solution to the problem, but sadly it's not quite as 
> clean as letting the build system determine if each 'wrapper' is needed. 
> DPDK supports a variety of platforms and toolsets and my experience with 
> SPDK suggests that we'll end up with compiler specific ifdef's.

I'd argue they are inevitable. Consider POSIX close(): if it's missing, what
would be a correct fallback? It depends on the execution environment (OS).
String function fallbacks, of course, are easily implemented from scratch.

> It's all 
> protected by RTE_INTERNAL so it's not really a problem, but I wonder if 
> it makes it easier for someone to accidentally introduce definitions 
> outside of the #ifdef RTE_INTERNAL?

Public functions without rte_ prefix shall not be introduced at all.

Remember the issue this patchset targets: export of POSIX symbols from EAL.
They are already defined in a way DPDK consumes successfully. RTE_INTERNAL
is a straightforward way to ensure symbols affect to other consumers.
(I'm talking about macros; asprintf should be moved inside EAL in any case.)