On 2019/04/12 11:28, Quentin Monnet wrote:
[...]
>
> > {
> > - int value_size = strlen(value);
> > - bool single_line, break_names;
> > + bool break_names;
> > - break_names = info->key_size > 16 || value_size > 16;
> > - single_line = info->key_size + value_size <= 24 && !break_names;
> > + break_names = info->key_size > 16;
> > + single_line = single_line && !break_names;
>
> If I understand correctly, this will also change formatting when error
> message is short (shorter than 16 characters: the "value" line will now be
> unconditionally split, even for short error messages (other than "<no
> entry>")). Why removing the condition on value_size > 16? (This is just a
> remark, I am not against changing it.)
>
With this patch, the error messages from bpftool ("<no entry>", "<cannot
read>"), which are chosen to be short, appear on the same line and the
messages from strerror appear on a separate line. Because those latter
messages are from a source external to bpftool and their length is
unknown ahead of time, I felt it led to a more predictable output to
consistently put them on their own line.
To be honest, I don't think the formatting in those print_entry_*
functions should change according to the length in any case. I think the
key and value for each entry should always be on the same line for ease
of grepping. A followup patch maybe...
