Re: [PATCH 01/18] checkpatch: Fix checking of newlines in error messages

[Fabiano Rosas <farosas@suse.de>]

Peter Xu <peterx@redhat.com> writes:

> On Thu, Sep 03, 2026 at 02:46:37PM -0300, Fabiano Rosas wrote:
>> Peter Xu <peterx@redhat.com> writes:
>> 
>> > On Wed, Sep 02, 2026 at 07:15:29PM -0300, Fabiano Rosas wrote:
>> >> Using newlines in the g_test_message is fine. It automatically adds
>> >> the '#' required by the TAP protocol to the start of each line.
>> >
>> > IIUC we have such check not because TAP, but because all these functions
>> > will append one newline at the end, hence it's not needed.  IOW, if it
>> > applies to g_test_message(), I don't see why it doesn't apply to the rest.
>> > But maybe there're other reasons?
>> >
>> > To make it simpler, maybe we just call a few times g_test_message()?
>> >
>> 
>> Not sure I understand your point, Peter. I want to be able to print nice
>> messages in patch 9:
>> 
>>  g_test_message("expected vs. found:\n\n%s\n---\n%s:%s", str, t2[match], t2[match + 1]);
>> 
>>  # HMP output mismatch for entry at line 55:
>>  # expected vs. found:
>>  #
>>  # max-bandwidth: 10356305952768 bytes/hour
>>  # ---
>>  # max-bandwidth: 10356305952768 bytes/second
>> 
>> What would be the issue of having newlines here?
>
> No issue here that I can see.  My question was, why you moved
> g_test_message() out only, but not all?
>

Ah, I see. I didn't want to touch the others because they are
considerably more important than the tests' messages.

> My gut feeling is we check this because people forget that all these
> functions includes a newline.
>
> So if your point stands here that "newlines can be in the middle", they
> should apply to all, not one.
>
> But still, I also don't see why we can't invoke g_test_message() a few
> times here too, if we want to avoid any global touch like this to land the
> whole thing faster..

Hopefully this patch is uncontroversial. Otherwise I can do what you
suggest.