On Wed, 27 Sep 2023 10:28:55 PDT (-0700), jeffreya...@gmail.com wrote:
On 9/25/23 15:17, Maciej W. Rozycki wrote:
On Mon, 25 Sep 2023, Maciej W. Rozycki wrote:
NB the use of this specific <assert.h> header, still in place elsewhere,
seems gratuitous to me. We don't need or indeed want to print anything in
the test cases (unless verifying something specific to the print facility)
and if we want to avoid minor code duplication (i.e. not to have explicit:
if (...)
__builtin_abort ();
replicated across test cases), we can easily implement this via a local
header, there's no need to pull in a complex system facility.
Overall we ought not to require any system headers in compile tests and
then link and run tests need a functional target environment anyway. So
maybe the use of <assert.h> in run tests isn't as bad after all if not for
the -DNDEBUG peculiarity. However I still think the less we depend in
verification on external components the better, that's one variable to
exclude.
Certainly we don't want extraneous #includes. We can often avoid them
with a few judicious prototypes, like for abort ().
But we also need to get to the point where we can run tests which have
#include directives that reference system headers. Many tests in the
various GCC testsuites have those directives and we don't want to be
continually trying to eradicate #includes from those tests.
The standard way to deal with this is single tree builds which are
deprecated or to have an install tree with the suitable multilib headers
and libraries. The latter seems like the only viable solution to me.
IMO this is one of those places where we should just be as normal as
possible. So if the other big ports allow system headers then we
should, otherwise we should move everyone over to testing in some way
we'll catch these before commit.
jeff
