osd@hou2d.UUCP (Orlando Sotomayor-Diaz) (05/15/86)
From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>
mod.std.c Digest Thu, 15 May 86 Volume 16 : Issue 11
Today's Topics:
Cover Letter for MORE C standard differences
MORE C standard differences Apr85-Feb86, part 1 of 9
----------------------------------------------------------------------
Date:
From: ihnp4!utzoo!lsuc!msb
Subject: Cover Letter for MORE C standard differences
To: utzoo!ihnp4!hou2d!osd
This is the continuation of my earlier posting enumerating signi-
ficant differences between the April 30, 1985, and February 14,
1986, drafts of the proposed ANSI C Standard. This posting cov-
ers Part D and part of Part E. It did not seem worthwhile doing
the rest of Part E.
As before, what you see here does not include ALL of the differ-
ences between the versions. I have generally suppressed changes
that appeared to provide only a clearer wording, or to move some
text to a more appropriate heading. Some of these changes are
actually fairly substantial in extent. On the other hand, I have
included all changes that affect either C itself or the terminol-
ogy for talking about it ... except, of course, any that I
missed.
The changes are cited in the order of their appearance in the new
version, with a few slight exceptions to group related text. 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 the description of ptrdiff_t in section
D.1.1 consists of the insertion of the word "signed". In such a
paragraph, the words not enclosed in braces may be unchanged from
April 1985 to February 1986, or they may have changed in a minor
way, as described above, in which case I am showing the new ver-
sion.
For larger changes, I give what are generally complete paragraphs
or blocks of paragraphs, showing old and new forms separately.
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 - ihnp4!utzoo!lsuc!msb
------------------------------
Date:
From: ihnp4!utzoo!lsuc!msb
Subject: MORE C standard differences Apr85-Feb86, part 1 of 9
To: utzoo!ihnp4!hou2d!osd
# D.1 INTRODUCTION {<stdefs.h> --> <stddef.h>}
# D.1.1 Terms and common definitions
N--> A "letter" is a character in the execution character set
N--> corresponding to any of the 52 required lower-case and upper-case
N--> letters in the source character set, listed in #B.2.1.
# D.1.1 Terms and common definitions
<--O A "null pointer" is a pointer of appropriate type whose value
<--O compares equal to that of an integral constant expression with
<--O the value 0.
# D.1.1 Terms and common definitions
The following types and macros ... are also defined in a common
* standard header, {<stdefs.h> --> <stddef.h>}.
The types are
ptrdiff_t
* which is the {--> signed} integral type of the result of sub-
tracting two pointers; and
size_t
* which is the {--> unsigned} integral type of the result of the
sizeof operator.
The macros are
NULL
* which expands to {a constant expression whose value compares
equal to that of an integral constant expression with the value
0, which can be assigned to a pointer or used as an argument to
represent the null pointer --> an implementation-defined null
pointer constant}; and
errno
* which expands to {an lvalue expression --> a modifiable lvalue}
* that designates {an int --> a volatile integer} which is set to a
positive error code by several library functions. ...
N--> The macro errno need not be the identifier of an object. It
N--> might be a modifiable lvalue resulting from a function call (for
N--> example, *_errno()).
# D.1.2 Headers
* Each library function {or object -->} is {associated with --> de-
clared in} a "header" ... made available via ... #include ...
* The header declares a set of related functions {and objects -->},
* plus any necessary types and additional {#define -->} macros
needed to facilitate their use.
Remark: The draft no longer refers to headers declaring any ob-
jects; this is a general change and will not be mentioned again.
# D.1.2 Headers
<--O An implementation may define macros whose names begin with two or
<--O more underscores, even if no headers are explicitly included.
# D.1.2 Headers
The standard headers are ...
N--> <float.h>
...
* {<stdefs.h> --> <stddef.h>}
# D.1.2 Headers
* Headers ... may be included more than once {--> in a given
scope}, with no effect different from being included only once.
# D.1.3 Use of library functions
Any function declared in a header may be implemented as a macro
defined in the header,
<--O so it is generally not safe to declare or take the address of a
<--O library function or object.
N--> so a library function should not be declared explicitly if its
N--> header is included. Any macro definition of a function can be
N--> suppressed locally by enclosing the name of the function in
N--> parentheses, because the name is then not followed by the left
N--> parenthesis that indicates expansion of a macro function name.
N--> For the same syntactic reason, it is permitted to take the ad-
N--> dress of a library function even if it is also defined as a mac-
N--> ro.
* The use of #undef to remove any macro definition will {--> also}
ensure that an actual function is referenced.
# D.1.3 Use of library functions
N--> If a function that accepts a variable number of arguments is not
N--> declared (explicitly or by including its associated header), the
N--> behavior is undefined.
# D.1.3 Use of library functions
... assuredly generating a true function reference ...
#include <stdlib.h>
#undef atoi
/*...*/
i = atoi(str);
N--> or
N--> #include <stdlib.h>
N--> /*...*/
N--> i = (atoi)(str);
# D.1.3 Use of library functions
... the appropriate header could specify
#define abs(x) _builtin_abs(x)
for a compiler whose code generator will accept it.
In this manner, a user desiring to guarantee that a given library
function such as abs will be a genuine function may write
#undef abs
whether the implementation's header provides a macro implementa-
* tion of abs or a builtin implementation. {--> The prototype for
the function, which precedes and is hidden by any macro defini-
tion, is thereby revealed also.}
------------------------------
End of mod.std.c Digest - Thu, 15 May 86 13:28:03 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.