> They can be compile time if the compiler can verify them statically (where they become a noop)

This only happens during constant evaluation. For example, the following could be determined statically, but compiles w/o error on gcc

int add_nums(int x, int y)

    pre(x >= 0)

    pre(y >= 0)

{

    return x + y;

}

int result_rt = add_nums(-1,-1); // no compile error

▲ bluGill 6 hours ago | parent [-]

It compilers on the current gcc version (or at least the one you tested). Future gcc can make it an error.

▲

nickorlow 6 hours ago | parent | next [-]

Yes, though that wouldn't be consistent w/ the standard

▲

bluGill 6 hours ago | parent [-]

The standard doesn't require compilers find all such cases. The standard allows it, but doesn't require it. There are many known cases where the compiler cannot find a case (at least not in a reasonable amount of time)

	▲	nickorlow 6 hours ago \| parent [-]
		The consequence of not being required in the standard is that compilers may not implement it and if they do, they will likely have different implementations/functionality

▲

cyberax 4 hours ago | parent | prev [-]

That's like compiling with -Wall. Stuff will keep breaking randomly, so people will just disable it.

	▲	bluGill 3 hours ago \| parent [-]
		Some people. Most projects I know of build -Wall and fix all the errors. Developers all run - Error. 30 years ago this was madness but compilers are good about fixing false positives and so it is reasonable. It isn't reasonable to expect downstream (i.e. Debian) to fix warnings but developers generally do for code they maintain.