Re: [v4] tools/bpf: Fix the wrong format specifier

From: Markus Elfring
Date: Wed Jul 24 2024 - 12:26:51 EST


>>> 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