Peter Xu <[email protected]> writes: > 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? >
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.
