In D53975#1233980, @haraldei wrote:

In D53975#1233152, @fuz wrote:

For testing, the gold standard is to build the port and execute the test suite on as many platforms we support as possible, on all currently supported OS versions (that is, 13.5, 14.3, and 15.0).

Do I have access to, and can I use the ref*-machines for that?

I have run the tests on amd64, natively on my dev machine, and can probably get the aarch64 emulation up and running too soon. But it would be nice to be able to at least run the tests on real hardware too.

In D53831#1229909, @fuz wrote:

The point of this test is to check that I got the definitions right, as we do them manually. We could actually use compiler builtins for the various sys/$ARCH/include files to directly grab the types from the C compiler, but we don't.

But didn't you propose making exactly that change?

For testing, the gold standard is to build the port and execute the test suite on as many platforms we support as possible, on all currently supported OS versions (that is, 13.5, 14.3, and 15.0). If you don't have access to some architectures, you can skip testing there, but especially for an infrastructure port like this it is a good idea to be thorough.

LGTM.

Looks reasonable. Should do the same thing as before, literally.

Looks reasonable.

This looks reasonable. I can't say if the conflict is correct, that's for you to decide. What would go wrong with multiple flavours installed at once?

• fix INTPTR_WIDTH on arm64 and riscv

In D53830#1229971, @brooks wrote:

I don't feel super strongly about this, but I'm not entirely convinced we should be defining these from first principles. I believe that compilers we care about define __*_WIDTH__ macros we could use instead and things are likely to go very badly wrong if there's disagreement.

In D53831#1229841, @markj wrote:

This looks like it's really testing the host's (cross-)build environment. That seems useful, but it's not the same as testing the installation itself, e.g., a test could invoke cc to compile this file or something similar and verify that it succeeded. Should we do both? Is there some reason this test on its own is sufficient?

• etc/mtree: add stdbit directory to etc/mtree/BSD.tests.mk

Thanks, this is something I always forget about.

I like this, removes a minor annoyance from working with some ports.

• use _WIDTH macros from C23 <limits.h> in stdbit unit tests, see D53825

• use C23 *_WIDTH macros from <limits.h>, see D53825
• add descriptive comments to all static_assert uses

• fix formatting issues in stdbit unit tests

• add missing backslash in Makefile.inc

• use explicit unsigned int in <stdbit.h>
• use explicit unsigned int in stdbit source files
• add period to comment

Sounds reasonable.

• sort MAN entries alphabetically as requested by @kib