Messages in this thread | | | Date | Wed, 8 Mar 2023 16:30:55 -0800 | From | Boris Burkov <> | Subject | Re: [PATCH bpf-next] libbpf: poison strlcpy() |
| |
On Thu, Jan 05, 2023 at 10:47:15AM -0800, sdf@google.com wrote: > On 01/05, Rong Tao wrote: > > From: Rong Tao <rongtao@cestc.cn> > > > Since commit 9fc205b413b3("libbpf: Add sane strncpy alternative and use > > it internally") introduce libbpf_strlcpy(), thus add strlcpy() to a poison > > list to prevent accidental use of it. > > > Signed-off-by: Rong Tao <rongtao@cestc.cn> > > Acked-by: Stanislav Fomichev <sdf@google.com> > > > --- > > tools/lib/bpf/libbpf_internal.h | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > diff --git a/tools/lib/bpf/libbpf_internal.h > > b/tools/lib/bpf/libbpf_internal.h > > index 377642ff51fc..2d26ded383ca 100644 > > --- a/tools/lib/bpf/libbpf_internal.h > > +++ b/tools/lib/bpf/libbpf_internal.h > > @@ -20,8 +20,8 @@ > > /* make sure libbpf doesn't use kernel-only integer typedefs */ > > #pragma GCC poison u8 u16 u32 u64 s8 s16 s32 s64 > > > -/* prevent accidental re-addition of reallocarray() */ > > -#pragma GCC poison reallocarray > > +/* prevent accidental re-addition of reallocarray()/strlcpy() */ > > +#pragma GCC poison reallocarray strlcpy
On my musl system, I believe this broke compilation, as string.h defines strlcpy, and is included after this poisoning when compiling strset.c
FWIW, I could work around it by adding #include <string.h> above #include <libbpf_internal.h> in strset.c, since the poison doesn't apply to symbols that existed before it ran, but this feels like a kludge, and not in the spirit of the original poisoning patch..
I'm curious what the proper workaround should be for a libc that defines strlcpy.
Thanks, Boris
> > > #include "libbpf.h" > > #include "btf.h" > > -- > > 2.39.0 >
| |