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).

IIRC static_assert is in C as well now (as _Static_assert).

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.

>Need to know that int is 32 bit? Not a problem.

I have 15 years of programming on 8but micros where that assumption/declaration is crazy. :)

Never use int. Always uint32_t. There! Problem of portability solved.

> I have 15 years of programming on 8but micros where that assumption/declaration is crazy. :)

Right, but that's the point here - we're discussing how to describe a stricter variant of C, which make exactly the kinds of guarantees that preclude exotic architecture targets. Ultra-portability isn't a goal for many codebases.

Then... make uint32_t the standard and this is never a problem ever again?

uint32_t is in the standard since C99. But it is conditionally present - it's only there if the platform can provide it. In practice, all platforms that most software cares about do so. But it's not actually codified everywhere, and that codification is what I was talking about.

uint32_t is already available on the platforms where it makes sense to support the type. It is a strength of the C language that it also supports exotic platforms.

By 'standard' do you just mean more widespread use? Some APIs already do something like this, such as Windows with its 'DWORD'.