osd@hou2d.UUCP (Orlando Sotomayor-Diaz) (05/11/86)
From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>
mod.std.c Digest Sat, 10 May 86 Volume 16 : Issue 2
Today's Topics:
Differences from April 1985 to February 1986 Draft Standard, Explanation
Differences from April 1985 to February 1986 Draft Standard, Part 1
----------------------------------------------------------------------
Date: Sun, 27 Apr 86 01:17:06 est
From: <ihnp4!utcsri!lsuc!msb%utcsri>
Subject: Differences from April 1985 to February 1986 Draft Standard, Explanation
To: cbosgd!std-c%utcsri
The preliminary draft proposed ANSI C Standard of April 30, 1985,
has been generally available for some time. However, the X3J11
committee has produced since produced further drafts, dated Au-
gust 11, 1985; November 11, 1985; and February 14, 1986. The
last I heard another draft was going to be printed shortly.
This posting is intended for readers who have some familiarity
with the April 1985 draft, to bring them up to date on what has
happened since then up to the February 1986 version. It exists
because I sent mail to Larry Rosler suggesting that it would be a
good idea, and he replied that he didn't have time to do it and
offered to send me all the versions if I did.
That mail exchange, incidentally, happened about Christmas time,
and referred to changes up to the November draft only. Much of
the delay since then is attributable to some combination of
AT&T's mailroom in Summit, NJ; the US Postal Service; and Canada
Post. The rest is attributable to my shortage of spare time to
do this in; if I'd known how long it was going to take, I would
not have volunteered.
This posting covers parts A-C of the document; that is, there is
nothing about the libraries. I hope to do another one covering
the rest of the document shortly.
Now, what you see here does not include all of the differences
between the versions. I have generally suppressed changes that
appeared to provide only a clearer wording. Some of these are
fairly substantial in extent, with sentences and paragraphs being
rearranged. On the other hand, I have included all changes to
the language and to the terminology for talking about it ... un-
less, of course, I missed some.
The changes are cited in the order of their appearance in the new
version, with a few slight exceptions to group related matter. I
don't give a lot of context for each one, to keep the length of
this document manageable. Never assume that you are seeing a
complete paragraph. However, where I have elided important text
I have placed an ellipsis (...).
For changes that affect a small part of a paragraph, I have
adopted the notation {old text --> new text}, which is simply run
in line. Each line containing the start of at least one such
change is starred in the left margin. The old or new text may be
null: thus, the change to section A.1 consists of the deletion of
the word "preliminary". In such a paragraph, the words not en-
closed in braces may be unchanged from April 1985 to February
1986, or they have have changed in a minor way in which case I am
showing the new version.
For larger changes, I give complete paragraphs or blocks of para-
graphs in old and new forms. The notation "<--O" in the left
margin means that this paragraph has been deleted or replaced;
"N-->" refers to its replacement or an added paragraph.
Since the typographical changes of the actual document are not
available here, I have rendered some of them in punctuation and
omitted others. (In particular, "quotation marks" in this arti-
cle more often than not represent italics in the original and
thus a definition of a term.)
Paragraphs marked Remark are mine.
Mark Brader
------------------------------
Date: Sun, 27 Apr 86 01:17:06 est
From: <ihnp4!utcsri!lsuc!msb%utcsri>
Subject: Differences from April 1985 to February 1986 Draft Standard, Part 1
To: cbosgd!std-c%utcsri
# Title
N--> Draft Proposed American National Standard for Information Systems
N--> -- Programming Language C
# A.1 Foreword
* This {preliminary -->} draft proposed American National Standard
describes the C programming language.
# A.6 Definitions of terms
<--O Object -- something that has a value.
N--> Object -- a region of storage, the contents of which can
N--> represent values.
# A.6 Definitions of terms
It need not be possible to express the address of each individual
* bit {--> of an object}.
* ... It {must --> shall} be possible to express the address of
* each individual byte {--> of an object} uniquely.
Remark: The word "must" seems to have been banished from the do-
cument. Further instances of this substitution will not be indi-
cated, even if the sentence is being cited for another change.
# A.6 Definitions of terms
N--> Terms explicitly defined in this Standard are not to be presumed
N--> to refer implicitly to similar terms defined elsewhere.
# A.7 Compliance
* A "comforming freestanding implementation" {must --> shall} ...
* provide the standard headers <limits.h> {--> and <float.h>}
specified in Section D (library).
<--O A conforming implementation may have extensions, which must not
<--O alter the behavior of a strictly conforming program (except
<--O perhaps by requiring the replacement of identifiers that conflict
<--O with new keywords or library symbols).
N--> A conforming implementation may have extensions (including addi-
N--> tional library functions), provided they do not alter the
N--> behavior of a strictly conforming program.
# {--> A.8 Future directions}
N--> With the introduction of new devices and extended character sets,
N--> new features may be added to the Standard. Sections in the
N--> Language and Library parts warn implementors and programmers of
N--> usages which, though valid in themselves, may conflict with fu-
N--> ture additions.
N--> Certain features are "deprecated", which means that their use in
N--> new programming is discouraged. They are retained in the Stan-
N--> dard because of their widespread use in existing programs.
N--> Deprecated features may be withdrawn in future revisions of the
N--> Standard.
Remark: With a new section A.8, the old A.8 (Difference marks)
becomes A.9.
# B.1.1.2 Translation phases
Remark: I'm showing the entire section this time.
The precedence among the syntax rules of translation is specified
by the following stages. An implementation is not required to
* mimic this separation into phases. {Each phase requires a com-
plete parse at its level, that is, it may not terminate with a
partial non-terminal. -->}
1. Physical source text file characters are mapped to the source
character set (introducing new-line characters for end-of-line
indicators) if necessary. Trigraph sequences are replaced by
corresponding single-character internal representations.
2. Each instance of a new-line character and an immediately
preceding backslash character is deleted, splicing physical
* source lines to form logical source lines. {--> A file shall not
end in a backslash character immediately followed by a new-line
character.}
3. Character constants, string literals, and the arguments to
#include preprocessing directives are tokenized. Each comment is
* replaced by one space character. {--> A file may not end in a
partial token.}
4. The source text is completely tokenized. New-line characters
* {become new-line tokens --> are retained}. {Each sequence of
other white-space characters becomes a single white-space token;
alternatively, each other white-space character becomes a unique
token. --> Whether each sequence of other white-space characters
is retained or is replaced by one space character is implementa-
tion defined.}
* 5. {The source text is preprocessed. --> Preprocessing directives
are executed.} A #include preprocessing directive causes the
* named file to be processed from phase 1, recursively. {Prepro-
cessing interprets new-line tokens as --> New-line characters
are} syntactically significant; "left-parenthesis not preceded by
white-space" is syntactically significant to the #define grammar.
<--O 6. The preprocessing concatenation operation is applied, and the
<--O full source is retokenized. Adjacent string literals are con-
<--O catenated. New-line characters are treated the same as other
<--O white-space characters.
N--> 6. White-space characters separating tokens are no longer signi-
N--> ficant. The preprocessing concatenation operator ## is applied.
N--> Adjacent string literals are concatenated.
7. The remaining tokens are syntactically and semantically
analyzed and translated.
* 8. All external {data --> object} and function references are
resolved. Library components may be linked to satisfy external
references to functions and objects not defined in the current
translation. All such translator output is collected into a pro-
gram image which contains information needed for execution in its
execution environment.
Remark: "Data" is another word that seems to have been banished
throughout the document.
------------------------------
End of mod.std.c Digest - Sat, 10 May 86 18:09:59 EDT
******************************
USENET -> posting only through cbosgd!std-c.
ARPA -> ... through cbosgd!std-c@BERKELEY.ARPA (NOT to INFO-C)
In all cases, you may also reply to the author(s) above.