Repository navigation
BOOST_TEST_EQ does not print C strings #91
Description
BOOST_TEST_EQ that involve C-style strings do not output string contents. For example, BOOST_TEST_EQ(*++itr, "foo"); shows this on failure:
libs\filesystem\test\path_test.cpp(341): test '*++itr == "foo"' ('"c:"' == '00007FF79AE87414') failed in function 'void __cdecl `anonymous-namespace'::iterator_tests(void)'
This seems to be caused by this test_output_impl overload:
core/include/boost/core/lightweight_test.hpp
Line 167 in e533933
Is this intended to return const void* instead of const char*?
If yes, then could we make this behavior optional?
Activity
Lastique commentedon Jun 3, 2021
There's also a similar overload for
char*.pdimov commentedon Jun 3, 2021
We have a separate macro for C strings, which is
BOOST_TEST_CSTR_EQ.BOOST_TEST_EQtests for equality using==, which forchar*compares addresses, so the output also prints addresses to match that.BOOST_TEST_CSTR_EQtest for equality withstrcmp, and prints the C strings to match.Lastique commentedon Jun 3, 2021
In Boost.Filesystem case we are comparing
pathwith string literals usingoperator==, which is intended.strcmpwouldn't work there.pdimov commentedon Jun 3, 2021
Yes, I understand that, but how are we supposed to distinguish the two cases? In general we have no idea what
==does. We could special-casestd::string, I suppose, and then it won't work forstring_view, so we'll have to special case that too?Lastique commentedon Jun 4, 2021
I think, the special case is comparing two pointers and the rest can be assumed to operate as intended (i.e. there must be a user-defined comparison or conversion operator for the comparison to compile).
Lastique commentedon Jun 4, 2021
Also, the comparison logic is unrelated to output formatting, which is what this issue about.
pdimov commentedon Jun 4, 2021
Not entirely unrelated; when the test fails the values need to tell us why.
This might be a good heuristic, yes (we also need to take arrays into account). Still a bit dangerous for my taste because misinterpreting a
char*that doesn't point to a C string would be bad... but it might be acceptable if we take care to quote the unprintable characters, which is a good thing to have anyway and something I've been thinking we need to do.glenfe commentedon Jun 4, 2021
I'd prefer not assuming (by default) that
char*means C string. If someone wants to test someoperator==(const X&, const char*)withBOOST_TEST_EQ(x, "y")then maybe we could provide some alternative macro that allows supplying a mechanism to control how the LHS and RHS arguments are formatted.Construct paths in BOOST_TEST_EQ macros from string literals.