Proposa for new term: Optionally-Strictly-Conforming Program

The C Standard presently defines two levels of standards-conformance for programs:

    If any C implementation exists that can make a program yield desired behavior while complying with the Standard, the program is "conforming".

    If no possible C implementation could comply with the the Standard but fail to process the program so as to yield desired behavior, the program is "strictly conforming".

Unfortunately, the first definition is absurdly loose [even a program consisting of nothing but
two underscores and a newline could be made conforming if one wrote a compiler which, given
such a program, would produce desired behavior], but the second is so strict that it is impossible to express many algorithms using code which is strictly conforming without making the code inefficient, unreadable, or both.

I would suggest a new standard of conformance, and a couple of new vocabulary terms to go with it.  A program would be said to be "optionally strictly conforming" if it complies with both of the following arguments:

    - It must be possible for a Standard-compliant C implementation to exist that could process the program so as to yield desired behavior.
    - All possible C implementations which comply with the Standard must either process it the program so as to yield desired behavior, or reject it outright by yielding at least one diagnostic message as a consequence of the program's assertion of requirements the compiler cannot meet.

At present there is no mechanism for programs to assert their requirements, but I would propose that the Standard define a mechanism by which assertions be added, and do so in a way that could be supported by existing C compilers with nothing other than the addition of suitable header files.  Toward that end, I would propose adding two more new terms to the lexicon to extend the terms "Undefined Behavior" and "Implementation-Defined" behavior:

    - A program invokes Testably-Specified Behavior if it invokes an action that would be Implementation-Defined Behavior, but has made assertions regarding that action's behavior and the compiler has not rejected them.  For example, if a source file asserts that a conversion from an out-of-range int32_t to int16_t will be performed a mod-65536 two's-complement reduction, then the effects of code performing such conversion would no longer be Implementation-Defined within that source file [at present, nothing would forbid an implementation from documenting that such conversions will yield -32768 or +32767 when a program is invoked with a command line argument of "ovs", and two's-complement reduction elsewhere, nor would there be any mechanism by which a program which had not particularly prepared for such behavior to test for it, so a strictly-conforming program can't use any Implementation-Defined behaviors, no matter how consistent existing implementations happen to be].

    - A program involves Testably-Constrained Behavior if it invokes an action that would be Undefined Behavior, except that the program has made assertions regarding that action's behavior and the compiler has not rejected them.  For example, if a source file asserts that the use of a relational operator may return zero or one in arbitrary fashion, and a compiler does not reject such an assertion, then such comparisons within that source file would no longer invoke Undefined Behavior but would instead be required to meet the indicated requirements.