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

[Peter Xu <peterx@redhat.com>]

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?

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

-- 
Peter Xu