For one thing, static_assert is C++, not C. There's still plenty of C around, and plenty more is being written.
The other problem with this approach is that it effectively defines lots of distinct subtly different pseudo-platforms, each a set of assumptions. And your average developer might not know which of those assumptions actually are "portable enough", and which are not. The point of defining such a profile would be for experts to provide a blessed set of assumptions that is, in fact, portable across all general-purpose platforms that are in active use.
For example, the fact that CHAR_BIT is 8, or that int32_t is defined, or that ints are two's complement, are all reasonable assumptions. But two's complement overflow for signed arithmetic is not, even today - even though in practice it works just fine on some platforms (more specifically, on some implementations).
Oops! Completely missed that we were talking about C.
I'll continue under the assumption that C is capable of equally powerful compile-time asserts.
> it effectively defines lots of distinct subtly different pseudo-platforms, each a set of assumptions
Indeed, but using this approach, all that's needed to define a new 'ordinary platform C' is a clearly defined set of requirements. No need for a whole new standard in the usual sense.
> experts to provide a blessed set of assumptions
Sure, and that's compatible with this approach. It could take the form of a header file.
I'm perfectly fine with the idea of code-as-specification like that. And you're right, a lot of these assumptions could probably be so encoded (some I'm not sure about - e.g. how would you static_assert for two's complement, without triggering UB?). But I think this sort of thing would need some official blessing to be widely adopted, regardless of whether it's a written spec or a header.
> how would you static_assert for two's complement, without triggering UB?
Good question, I'm not certain that's possible. A quick google turned up surprisingly little.
The ghastly hack alternative would be to detect which compiler/target we're dealing with and compare against a whitelist.
> I think this sort of thing would need some official blessing to be widely adopted, regardless of whether it's a written spec or a header.
It would certainly help to have it properly branded and given real credibility, yes. I'm reminded of MISRA C, which has a good deal of tooling and documentation.
The other problem with this approach is that it effectively defines lots of distinct subtly different pseudo-platforms, each a set of assumptions. And your average developer might not know which of those assumptions actually are "portable enough", and which are not. The point of defining such a profile would be for experts to provide a blessed set of assumptions that is, in fact, portable across all general-purpose platforms that are in active use.
For example, the fact that CHAR_BIT is 8, or that int32_t is defined, or that ints are two's complement, are all reasonable assumptions. But two's complement overflow for signed arithmetic is not, even today - even though in practice it works just fine on some platforms (more specifically, on some implementations).