On Thu, Sep 03, 2026 at 02:46:37PM -0300, Fabiano Rosas wrote: > Peter Xu <[email protected]> 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
