>>> The format specifier of "unsigned int" in printf() should be "%u", not >>> "%d". >> >> * Please improve the change description with imperative wordings. >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.10#n94 > > The wording is fine. I find it improvable. > The commit subject does use imperative. Yes. The requirement for “imperative mood” affects mostly the commit message, doesn't it? >> … >>> --- >>> Changes: >> … >>> v4: >>> Thanks! But unsigned seems relevant here, … >> >> Please adjust the representation of information from a patch review by Quentin Monnet. >> https://lore.kernel.org/linux-kernel/2d6875dd-6050-4f57-9a6d-9168634aa6c4@xxxxxxxxxx/ >> https://lkml.org/lkml/2024/7/24/378 > > > I'm not sure what you mean here. Should quoted information be marked better anyhow in version descriptions? > I'm not sure what you mean here. This part won't be kept in the commit > description anyway. > > Zhu, for future patches I'd recommend keeping the history above the > comment delimiter (so that it makes it into the final patch description), … Please reconsider such a suggestion once more. >> … >>> +++ b/tools/bpf/bpftool/xlated_dumper.c >>> @@ -349,7 +349,7 @@ void dump_xlated_plain(struct dump_data *dd, void *buf, unsigned int len, >>> >>> double_insn = insn[i].code == (BPF_LD | BPF_IMM | BPF_DW); >>> >>> - printf("% 4d: ", i); >>> + printf("%4u: ", i); >>> print_bpf_insn(&cbs, insn + i, true); >> … >> >> How do you think about to care more also for the return value from such a function call? >> https://wiki.sei.cmu.edu/confluence/display/c/ERR33-C.+Detect+and+handle+standard+library+errors > > Apologies, I'm afraid I don't understand what you're asking here, can > you please rephrase? Various source code analysis tools can point further programming concerns out for some implementation details. https://cwe.mitre.org/data/definitions/252.html How will development interests evolve further? Regards, Markus
