libc/tests: add test for *_MAX, *_MIN, and *_WIDTH

[fuz]

Summary

This file checks the correctness of the various _MAX, _MIN, and
_WIDTH macros defined for the libc types. It assumes that none
of the types have padding bits.

Test Plan

this is the test for D53830

[markj]

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?

[fuz]

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?

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. So the point is to check if what I added to the headers matches what the compiler thinks the type sizes and ranges should be. As we use the same compiler for cross-building as we install on the target, I don't see why adding another set of tests would add more certainty.

[kib]

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?

But why does it matter? Both cross and native compilers must agree on the target properties, and there we test the target parameters. So IMO adding compilation in the host == target env would only add more overhead. I do not see much sense in testing the compiler itself in the FreeBSD test suite.

By itself, the tests verify that the header is aligned with the compiler ideas of the types layout, which seems to be the motivation for the tests.

[markj]

In D53831#1232699, @kib wrote:

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?

But why does it matter? Both cross and native compilers must agree on the target properties, and there we test the target parameters. So IMO adding compilation in the host == target env would only add more overhead. I do not see much sense in testing the compiler itself in the FreeBSD test suite.

Why not? The compiler is a component that we ship, why shouldn't there be tests for it?

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?

So the point is to check if what I added to the headers matches what the compiler thinks the type sizes and ranges should be. As we use the same compiler for cross-building as we install on the target, I don't see why adding another set of tests would add more certainty.

That's not always true though. If I build the base system with CROSS_TOOLCHAIN=, then AFAIU this test is exercising the external toolchain, not the one that we're actually building.

Anyway, I think the change is ok, I just want to be clear about what it's actually testing. I'm not really convinced that we shouldn't have a runtime variant of this test. Please consider it approved.

[fuz]

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?

Yes, that is one proposal I had floated in D53830. It seems to be a good idea, but I think it's easier to first get the *_WIDTH macros in as a feature and to then refactor all these macros to be based on compiler builtins as a separate thing.