Am 16.07.24 um 03:43 schrieb Jeff King: > 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"). > 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é
