On Sat, Nov 6, 2021 at 9:34 AM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > On Fri, Nov 5, 2021 at 6:36 PM Kumar Kartikeya Dwivedi <memxor@xxxxxxxxx> wrote: > > > > Fix any remaining instances that fail the build in this mode. For selftests, we > > also need to separate CXXFLAGS from CFLAGS, since adding it to CFLAGS simply > > would generate a warning when used with g++. > > > > This also cherry-picks Andrii's patch to fix the instance in libbpf. Also tested > > introducing new invalid usage of C99 features. > > > > Andrii Nakryiko (1): > > libbpf: fix non-C89 loop variable declaration in gen_loader.c > > > > Kumar Kartikeya Dwivedi (5): > > bpftool: Compile using -std=gnu89 > > libbpf: Compile using -std=gnu89 > > selftests/bpf: Fix non-C89 loop variable declaration instances > > selftests/bpf: Switch to non-unicode character in output > > selftests/bpf: Compile using -std=gnu89 > > Please don't. > I'd rather go the other way and drop gnu89 from everywhere. > for (int i = 0 > is so much cleaner. I agree that for (int i) is better, but it's kernel code style which we followed so far pretty closely for libbpf and bpftool. So I think this is the right move for bpftool and libbpf. Selftests are less consistent in styling and lack of unicode character in bench is annoying, so I don't mind leaving selftest more permissive. And even with all that, we've managed to keep BPF program code consistently in C89 here in selftests and in bcc/libbpf-tools. The code style uniformity is nice. Whether to relax BCC compilation flags is a separate discussion (and I don't have any strong opinion). I'd still enforce -std=gnu89 for BPF source code for consistency across many BPF projects.
