Am 16.07.24 um 03:43 schrieb Jeff King:

On Sun, Jul 14, 2024 at 12:17:09PM +0200, René Scharfe wrote:

quoted

quoted

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

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é