git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v2] t-strvec: use test_msg()

From
René Scharfe <l.s.r@web.de>
Date
Jul 16, 2024, 16:43 UTC
Message-ID
<824ecb8b-b786-4220-a6b4-598a818bee52@web.de>
In-Reply-To
<20240716014330.GA639947@coredump.intra.peff.net>
Am 16.07.24 um 03:43 schrieb Jeff King:
Show 10 quoted lines
> On Sun, Jul 14, 2024 at 12:17:09PM +0200, René Scharfe wrote:
>
>>> Should we be using check_str_loc() in the post-image?
>>
>> Yes, and check_uint_loc() and check_pointer_eq_loc() as well.  Which
>> would be a pain.  Or we drag everything into the macro check_strvec and
>> get the caller's line number for free.
>
> Is it that big of a pain? It's mostly just passing "loc" along to the
> relative functions.

That part is bearable. The pain comes from the need to pass in arguments multiple times, for the stringified check description, as part of the check result and as separate values.

It could be mitigated by adding a new macro that takes loc, a, op, and b, perhaps called CHECK_UINT_LOC. That additional evaluation step doesn't work nicely with arguments that are themselves macros, though, like NULL for string or pointer checks, as those will be expanded, changing the message.

> Are the unit tests themselves multi-threaded within a single program?

No, and check_pointer_eq, check_int, check_uint, and check_char use shared global variables to store temporary values (comments rightly warn that "this is not thread safe").

Show 8 quoted lines
> I'd think not. In which case, I kind of wonder if a simpler pattern
> would be to just set a global "location" variable (probably as a stack
> of strings) that all of the individual check functions used. And then we
> could set it once at the top-level of the test which wants its location
> reported, and any helper functions that get called in the middle would
> not have to care. And existing check_foo() functions could use the
> current file/line location if the stack is empty (so code that isn't
> using helper functions can remain unaffected).

That doesn't sound simpler to me, quite the opposite actually. To the point that I don't dare to ask for a demo. o_O

Or perhaps I need to revisit it when I'm no longer tired and hungry.
René
Previous: Jeff KingNext: René Scharfe
Message 8 of 20 in “t-strvec: use test_msg()”
  1. t-strvec: use test_msg()René Scharfe, Jul 4, 2024
  2. Eric SunshineJul 4, 2024
  3. Phillip WoodJul 5, 2024
  4. t-strvec: use test_msg()René Scharfe, Jul 5, 2024
  5. Jeff KingJul 9, 2024
  6. René ScharfeJul 14, 2024
  7. Jeff KingJul 16, 2024
  8. René ScharfeJul 16, 2024
  9. 2/1 t-strvec: improve check_strvec() outputRené Scharfe, Jul 14, 2024
  10. Junio C HamanoJul 15, 2024
  11. 3/1 t-strvec: tighten .alloc check in check_strvecRené Scharfe, Jul 14, 2024
  12. Junio C HamanoJul 15, 2024
  13. René ScharfeJul 15, 2024
  14. Junio C HamanoJul 15, 2024
  15. t-strvec: improve check_strvec() outputRené Scharfe, Jul 14, 2024
  16. René ScharfeJul 14, 2024
  17. Jeff KingJul 16, 2024
  18. Junio C HamanoJul 16, 2024
  19. t-strvec: fix type mismatch in check_strvecRené Scharfe, Jul 16, 2024
  20. Junio C HamanoJul 16, 2024

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.