On Tue, Nov 9, 2021 at 1:40 PM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > On Mon, Nov 8, 2021 at 2:15 PM Andrii Nakryiko > <andrii.nakryiko@xxxxxxxxx> wrote: > > > > On Sat, Nov 6, 2021 at 4:20 PM Alexei Starovoitov > > <alexei.starovoitov@xxxxxxxxx> wrote: > > > > > > On Sat, Nov 6, 2021 at 1:02 PM Andrii Nakryiko > > > <andrii.nakryiko@xxxxxxxxx> wrote: > > > > > > > > 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. > > > > > > The kernel coding style is not white and black. > > > Certain style preferences are archaic to say the least. > > > It's not the right move to follow it blindly. > > > > Can we at least add -std=gnu89 for the libbpf? It's a library, so > > being conservative with compiler versions and language features makes > > sense there. I'll add a similar flag to Github's Makefile. I'd rather > > catch this at patch submission time rather than at the Github sync > > time. > > Sure. Applied Kumar's patch 3. > With CO-RE in the kernel the pieces of libbpf will be part > of the kernel for real, so for libbpf as a whole would make sense > to conform to the language standards as parts of libbpf have to do. > As far as other parts of kernel git the language standard > can be decided whichever way. > perf and libsubcmd (part of objtool) have no issue using 'for (int' > while being part of the kernel tree. > We can adopt strong gnu89 in bpftool, but I'd rather not rush > such a decision right now. > selftests are certainly not gnu89. > All bpf programs are written in C-2021 "standard". > Lots of C extensions in there. sgtm
