The thing I'd most like to see would be a recognition of whether the Standard is intended to recognize all the semantics necessary to accommodate the common uses to which the language is put, or is intended solely to describe a core language which implementations intended for various purposes would be expected to extend--typically by defining behaviors in cases where the Standard would otherwise impose no requirements--uphold the Spirit of C, including such principles as "Don't prevent [or needlessly impede] the programmer from doing what needs to be done". Either purpose could be fine and useful, but the lack of clarity as to what the Standard is supposed to be simultaneously leads to the Committee deciding that behaviors which are needed for low-level programming need not be addressed by the Standard if implementations would be allowed to support them without being ordered to do so, and compiler writers deciding that behaviors needed for low-level programming need not be supported if the Standard doesn't require them.
If one regards the job of a standard as defining categories of things, such that things from different categories can be expected to interact usefully (e.g. any standard M6 male thread will fit any standard M6 female thread) the C Standard fails utterly. The Standard would allow a Conforming C Implementation to behave arbitrarily when given any useful programs (the ability to correctly process one contrived and useless program would suffice for conformance), nor is there any requirement that Strictly Conforming Program be capable of being processed in defined fashion by any non-contrived C implementations (a Strictly Conforming Program could, for example, nest function calls a trillion levels deep). The only situation where the Standard actually guarantees anything useful is when programs contain a `#error` directive. The guarantee that such programs will not be processed is useful, even though outside some really weird contrived circumstances the programs themselves wouldn't be.
I would like to see the Standard adopt the following categories of programs and implementations, whose interactions would be useful.
1. A Safely Conforming Implementation (or an implementation configured to be Safely Conforming) must define a set of environmental requirements, and guarantee that unless a program invokes UB or those requirements are violated, it will not do anything other than process the program in Standard-defined fashion or indicate failure in Implementation-Defined fashion (spending arbitrarily long--even forever--deciding on a course of action would not be considered "doing anything").
2. A Selectively Conforming Program would include sufficient directives to ensure that any Safely Conforming Implementation receiving it would be required to indicate failure if it could not process the program in defined fashion. Such directives could specify things like behavioral requirements for actions which would invoke UB in their absence, such as integer overflow. If a program contains a directive specifying that it needs integer overflow to wrap in two's-complement fashion, implementations would be allowed to reject the program entirely, or process it with the specified semantics, but in the presence of that directive integer overflow would no longer invoke UB.
3. A Full Conforming Implementation would be a Safely Conforming Implementation which supports many common features, such as `int` type that is either `int32_t` or `int64_t`, wrapping two's-complement and loose type-punning semantics (in the presence of a directive demanding them), linear conversions between pointers and `uintptr_t`, etc. and will make a bona fide effort to process Strictly Conforming Programs when possible; the inability to run some Strictly Conforming Programs would be a Quality of Implementation issue rather than a conformance one.
4. A Strictly Conforming Program is a Selectively Conforming Program that does not make use of any features that are not required of Full Conforming Implementations, and is designed to be run usefully on any good-quality Full Conforming Implementation given sufficient memory.
5. A Limited Safely Conforming Implementation would be an implementation which does not claim to meet all the requirements of a Full Conforming Implementation, but meets the requirements of a Safely Conforming Implementation by rejecting programs it cannot handle.
There are many situations where a behavioral behavioral guarantee would be useful or essential for some but not all kinds of programs, but would needlessly impair optimizations when processing programs that don't need it. The way to resolve that is not to choose between saying that all implementations must always offer the guarantee, nor that programs requiring the guarantee are "broken", but instead recognize that programs that would benefit from the guarantee should have a way of specifying that they need it,
No comments:
Post a Comment