From b7c30c72b7138433e6ec16dc98f95b080402649e Mon Sep 17 00:00:00 2001 From: "W. Trevor King" Date: Thu, 9 Feb 2017 16:15:09 -0800 Subject: [PATCH] runtime: Define "unspecified", "undefined", and "implementation-defined" I had been unaware of formal distinctions between these terms until Stephen Walli called it out [1] in the context of his suggestion to use "implementation defined" for uploading application/vnd.oci.image.layer.nondistributable.tar+gzip [2]. I couldn't find anything as compact as RFC 2119 around this idea, but linking to a section of the C99 rationale seems reasonable enough. The PDF I'm linking is "Rationale for International Standard - Programming Languages - C Revision 5.10 April-2003" and the referenced content appears in section 3: The terms *unspecified behavior*, *undefined behavior*, and *implementation-defined behavior* are used to categorize the result of writing programs whose properties the Standard does not, or cannot, completely describe. The goal of adopting this categorization is to allow a certain variety among implementations which permits *quality of implementation* to be an active force in the marketplace as well as to allow certain popular extensions, without removing the cachet of *conformance to the Standard*. Informative Annex J of the Standard catalogs those behaviors which fall into one of these three categories. *Unspecified behavior* gives the implementor some latitude in translating programs. This latitude does not extend as far as failing to translate the program, however, because all possible behaviors are "correct" in the sense that they don't cause undefined behavior in *any* implementation. *Undefined behavior* gives the implementor license not to catch certain program errors that are difficult to diagnose. It also identifies areas of possible conforming language extension: the implementor may augment the language by providing a definition of the officially undefined behavior. *Implementation-defined behavior* gives an implementor the freedom to choose the appropriate approach, but requires that this choice be explained to the user. Behaviors designated as implementation-defined are generally those in which a user could make meaningful coding decisions based on the implementation's definition. Implementors should bear in mind this criterion when deciding how extensive an implementation definition ought to be. As with unspecified behavior, simply failing to translate the source containing the implementation-defined behavior is not an adequate response. The "rationale for the C99 standard" link text seems pretty informal, but that's what WG14 uses to refer to the document [3]. And I've got the full title, revision, date, and referenced text in here in case the link dies and there is any ambiguity about the particular revision intended ;). [1]: https://github.com/opencontainers/image-spec/pull/233#issuecomment-245416276 [2]: https://github.com/opencontainers/image-spec/pull/233#issuecomment-245354663 [3]: http://www.open-std.org/jtc1/sc22/wg14/ Signed-off-by: W. Trevor King --- runtime.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/runtime.md b/runtime.md index 74c0a06..629555d 100644 --- a/runtime.md +++ b/runtime.md @@ -6,6 +6,8 @@ This file defines the OCI Runtime Command Line Interface version 1.0.0. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119][rfc2199]. +The key words "unspecified", "undefined", and "implementation-defined" are to be interpreted as described in the [rationale for the C99 standard][c99-unspecified]. + ## Versioning The command line interface is versioned with [SemVer v2.0.0][semver]. @@ -230,6 +232,7 @@ $ echo $? See [create](#example) for an example. [bundle]: https://github.com/opencontainers/runtime-spec/blob/v1.0.0-rc4/bundle.md +[c99-unspecified]: http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf#page=18 [capabilities.7]: http://man7.org/linux/man-pages/man7/capabilities.7.html [controlling-terminal]: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap11.html#tag_11_01_03 [create]: https://github.com/opencontainers/runtime-spec/blob/v1.0.0-rc4/runtime.md#create