From 2d4933339e0d04db9829cebfcccede1d0254ab29 Mon Sep 17 00:00:00 2001 From: "W. Trevor King" Date: Wed, 14 Sep 2016 00:36:51 -0700 Subject: [PATCH] README: 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 ;). Also update the layer.md instance to use the C99 standard's hyphenated form. [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 --- README.md | 3 +++ layer.md | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 72c8fccd3..52ecc908e 100644 --- a/README.md +++ b/README.md @@ -9,6 +9,8 @@ The combination of the image manifest, image configuration, and one or more file The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC 2119](http://tools.ietf.org/html/rfc2119) (Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997). +The keywords "unspecified", "undefined", and "implementation-defined" are to be interpreted as described in the [rationale for the C99 standard][c99-unspecified]. + ![](img/build-diagram.png) Once built the OCI Image can then be discovered by name, downloaded, verified by hash, trusted through a signature, and unpacked into an [OCI Runtime Bundle](https://github.com/opencontainers/runtime-spec/blob/master/bundle.md). @@ -174,5 +176,6 @@ Read more on [How to Write a Git Commit Message](http://chris.beams.io/posts/git 8. When possible, one keyword to scope the change in the subject (i.e. "README: ...", "runtime: ...") +[c99-unspecified]: http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf#page=18 [UberConference]: https://www.uberconference.com/opencontainers [irc-logs]: http://ircbot.wl.linuxfoundation.org/eavesdrop/%23opencontainers/ diff --git a/layer.md b/layer.md index b441b8dba..6e771cc84 100644 --- a/layer.md +++ b/layer.md @@ -277,6 +277,6 @@ Typically, such layers are downloaded directly from a distributor but are never Layers that have these restrictions SHOULD be tagged with an alternative mediatype of `application/vnd.oci.image.layer.nondistributable.tar+gzip`. [Descriptors](descriptor.md) referencing these layers MAY include `urls` for downloading these layers. -It is implementation defined whether or not implementations upload layers tagged with this media type. +It is implementation-defined whether or not implementations upload layers tagged with this media type. [tar-archive]: https://en.wikipedia.org/wiki/Tar_(computing)