Re: [PATCH v3 bpf-next 1/3] bpf: switch BPF UAPI #define constants used from BPF program side to enums

On 2020-06-02, Alexei Starovoitov wrote: > ISO C forbids zero-size arrays, unnamed struct/union, gcc extensions, > empty unions, etc > So ? So their use should be avoided in UAPI headers whenever possible. While the other extensions are simple and have clear semantics, enums with out-of-range val

Re: [PATCH v3 bpf-next 1/3] bpf: switch BPF UAPI #define constants used from BPF program side to enums

On 2020-06-02, Alexei Starovoitov wrote: > the enum definition of BPF_F_CTXLEN_MASK is certainly within standard. > I don't think kernel should adjust its headers because some compiler > is failing to understand C standard. This is not true. See C11 6.7.2.2p2: "The expression that defines the val

Re: [PATCH v3 bpf-next 1/3] bpf: switch BPF UAPI #define constants used from BPF program side to enums

On 2020-06-02, Alexei Starovoitov wrote: > It's possible, but I'm not sure what it will fix. > Your example is a bit misleading, since it's talking about B > which doesn't have type specifier, whereas enums in bpf.h have ULL > suffix where necessary. > And the one you pointed out BPF_F_CTXLEN_MASK

Re: [PATCH v3 bpf-next 1/3] bpf: switch BPF UAPI #define constants used from BPF program side to enums

Hi, On 2020-03-04, Daniel Borkmann wrote: > I was about to push the series out, but agree that there may be a risk for > #ifndefs > in the BPF C code. If we want to be on safe side, #define FOO FOO would be > needed. I did indeed hit some breakage due to this change, but not for the anticipated

[PATCH] ipmroute: Prevent overlapping storage of `filter` global

ommon from ipmroute.o Signed-off-by: Michael Forney --- I'm not sure if this causes any problems in practice, but it seems unintended. ip/ipmroute.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ip/ipmroute.c b/ip/ipmroute.c index 8b3c4c25..656ea0dc 100644 --- a/ip/ipmrou