On Wed, Mar 8, 2023 at 4:01 PM Stanislav Fomichev <sdf@xxxxxxxxxx> wrote:
>
> On Wed, Mar 8, 2023 at 3:51 PM Jesus Sanchez-Palencia
> <jesussanp@xxxxxxxxxx> wrote:
> >
> > (+bpf folks, -perf folks)
> >
> > Please see below.
> >
> > On Wed, Mar 8, 2023 at 11:28 AM Jesus Sanchez-Palencia
> > <jesussanp@xxxxxxxxxx> wrote:
> > >
> > > Hi there,
> > >
> > > So commit 6d0c4b11e743("libbpf: Poison strlcpy()") added the pragma
> > > poison directive to libbpf_internal.h to protect against accidental
> > > usage of strlcpy. This has broken the build for some toolchains and
> > > the problem is that some libcs (e.g. uClibc-ng) provide the strlcpy()
> > > declaration from string.h, which leads to a problem with the following
> > > include order:
> > >
> > > string.h,
> > > from Iibbpf_common.h:12,
> > > from libbpf.h:20,
> > > from libbpf_internal.h:26,
> > > from strset.c:9:
> > >
>
> [..]
>
> > > If we patch libbpf_internal.h and move the #pragma GCC poison
> > > directive to after the include list, we fix the problem but at the
> > > expense of leaving libbpf.h unprotected (and libbpf_common.h as well,
> > > of course).
>
> Seems like a nice compromise? I'm assuming the original intent was to
> mostly protect the c files, not the headers. Andrii WDYT?
Let's drop the poisoning of strlcpy completely, if it's causing such
problems. It's unlikely to accidentally use this function. If someone
can please send a patch, I'd appreciate it. Thank you!
>
> > >We could duplicate the directive on all these other libbpf
> > > headers after the include list, but that's code duplication so I
> > > wanted to bring this up here before I send out a patch.
> > >
> > > Let me know what you think or if you have any other suggestions, please.
> > >
> > > Thanks,
> > > Jesus
