osd@hou2d.UUCP (Orlando Sotomayor-Diaz) (05/13/86)
From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>
mod.std.c Digest Tue, 13 May 86 Volume 16 : Issue 8
Today's Topics:
Differences from April 1985 to February 1986 Draft Standard, Part 7
----------------------------------------------------------------------
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 7
To: cbosgd!std-c%utcsri
# C.4 CONSTANT EXPRESSIONS
An expression that evaluates to a constant is required in several
* contexts ... More latitude is permitted for initializers {of ob-
jects that have static storage duration -->}.
# C.5 DECLARATIONS
<--O As discussed later, a declaration without a declarator may be
<--O used to declare a structure, union, or enumeration tag. Any oth-
<--O er kind of declaration without a declarator is also permitted,
<--O though without effect.
N--> A declaration shall declare at least a declarator, a tag, or the
N--> members of an enumeration.
# C.5.1 Storage-class specifiers
A declaration with storage-class specifier extern indicates that
* {-->, if the identifier declared is in fact referred to, then}
somewhere in the set of source files that constitutes the entire
* program there exists an "external {data --> object} definition"
* for the given identifier (a definition with file scope). {--> If
the declaration with storage-class specifier extern occurs out-
side a function, the identifier is declared with file scope and
external linkage, and may itself serve as the required defini-
tion, as discussed later.}
# C.5.1 Storage-class specifiers
<--O Invalid or excess register declarations are treated as auto de-
<--O clarations.
N--> The implementation may treat any register declaration simply as
N--> an auto declaration.
# C.5.2.1 Structure and union specifiers
N--> The presence of a struct-declaration-list in a struct-or-union-
N--> specifier declares a new type.
# C.5.2.1 Structure and union specifiers
In addition, a member may be declared to consist of a specified
* number of bits {--> (including a sign bit, if any)}. Such a
member is called a "bit-field" ...
* ... {--> An implementation may allocate any addressable storage
unit large enough to hold a bit-field.} If enough space remains,
* a bit-field that follows another bit-field {is --> shall be}
* packed into adjacent bits of the same {int --> unit}. {An imple-
mentation may refuse to permit a bit-field to straddle an int
boundary, in which case a bit-field that does not fit into the
space remaining in an int is put into the next int. --> If insuf-
ficient space remains, whether a bit-field that does not fit is
put into the next unit is implementation-defined.} The order of
* allocation of bit-fields within {an int --> a unit} (high-order
to low-order or low-order to high-order) is implementation-
defined.
# C.5.2.1 Structure and union specifiers
N--> A pointer to a structure object, suitably cast, points to its in-
N--> itial member or, if it is a bit-field, to the unit in which it
N--> resides.
N--> ... A pointer to a union object, suitably cast, points to each
N--> of its members or, if a member is a bit-field, to the unit in
N--> which it resides.
# C.5.2.1 Structure and union specifiers
N--> There may therefore be unnamed holes within a structure, but not
N--> at its beginning {-->, nor more than necessary to achieve the ap-
N--> propriate alignment}.
# C.5.2.3 Enumeration specifiers
* The scope of an enumeration constant {is the same as that of -->
begins after its declaration and ends with the scope of} the
enumeration of which it is a member.
# C.5.2.3 Enumeration specifiers
* {--> An object that has an enumeration type behaves like an int
in an expression.} The implementation may use the set of values
in the enumeration to determine whether to make the effective
* type of an enum object a shorter {signed -->} integral type that
will promote to int ...
# C.5.3 Declarators
Remark: Again, the notation [opt] below represents a subscript
opt, which means optional. The [] characters not part of [opt]
are real [] characters. The {} characters are the usual differ-
ence notation of this article.
declarator:
pointer[opt] declarator2
declarator2:
identifier
( declarator )
declarator2 [ constant-expression[opt] ]
* declarator2 ( parameter-type-list {[opt] -->} )
* declarator2 ( {parameter-identifier-list[opt]
--> identifier-list[opt]} )
<--O ... parameter-identifier-list:
<--O identifier-list
<--O identifier-list , ...
# C.5.3 Declarators
* The implementation shall allow at least {six --> 12} pointer, ar-
ray, and function declarators (in any combinations) modifying a
basic type, either directly or via typedefs.
# C.5.3.3 Function declarators {--> (including prototypes)}
<--O A parameter identifier list declares only the identifiers of the
<--O formal parameters of the function, and may be present in the de-
<--O clarator only in a function declaration (#C.7.1). If the list is
<--O empty, the function has no parameters.
N--> An identifier list declares only the identifiers of the formal
N--> parameters of the function. If the list is empty in a function
N--> declaration that is not part of a function definition, no infor-
N--> mation about the number or types of the parameters is supplied.
N--> If the list is empty in a function declaration that is part of a
N--> function definition, the function has no parameters.
# C.5.4 Type names
N--> Empty parentheses in a type name are interpreted as "function
N--> with no parameter type information", rather than redundant
N--> parentheses around the omitted identifier.
# C.5.5 Type definitions and type equivalence
<--O In the program fragment
<--O typedef float length;
<--O /*...*/
<--O {
<--O static int length;
<--O /*...*/
<--O if the int type specifier were omitted from the second declara-
<--O tion, it would be taken to be a (semantically vacuous) declara-
<--O tion with type length and no declarators.
------------------------------
End of mod.std.c Digest - Tue, 13 May 86 09:05:58 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.