c5

UNIX v6源代码 这几乎是最经典的unix版本 unix操作系统设计和莱昂氏unix源代码分析都是用的该版

specifier is ignored in external definitions.
.ul
12.  Compiler control lines
.et
When a line of a C program begins
with the character \fG#\fR, it is interpreted not by
the compiler itself, but by a preprocessor which is capable
of replacing instances of given identifiers
with arbitrary token-strings and of inserting
named files into the source program.
In order to cause this preprocessor to be invoked, it
is necessary that the very first line of the program
begin with \fG#\fR.
Since null lines are ignored by the preprocessor,
this line need contain no other information.
.ms
12.1  Token replacement
.et
A compiler-control line of the form
.dp 1
	\fG# define \fIidentifier token-string
.ed
(note: no trailing semicolon)
causes the preprocessor to replace subsequent instances
of the identifier with the given string of tokens
(except within compiler control lines).
The replacement token-string has comments removed from
it, and it is surrounded with blanks.
No rescanning of the replacement string is attempted.
This facility is most valuable for definition of ``manifest constants'',
as in
.sp .7
.nf
.bG
	# define tabsize 100
	.^.^.
	int table[tabsize];
.sp .7
.eG
.fi
.ms
12.2  File inclusion
.et
Large C programs
often contain many external data definitions.
Since the lexical scope of external definitions
extends to the end of the program file,
it is good practice
to put all the external definitions for
data at the start of the
program file, so that the functions defined within
the file need not repeat tedious and error-prone
declarations for each external identifier they use.
It is also useful to put a heavily used structure definition
at the start and use its structure tag to declare
the \fGauto\fR pointers to the structure
used within functions.
To further exploit
this technique when a large C program
consists of several files, a compiler control line of
the form
.dp 1
	\fG# include "\fIfilename^\fG"
.ed
results in the replacement of that
line by the entire contents of the file
\fIfilename\fR.
.pg
.ul
13.  Implicit declarations
.et
It is not always necessary to specify
both the storage class and the type
of identifiers in a declaration.
Sometimes the storage class is supplied by
the context: in external definitions,
and in declarations of formal parameters
and structure members.
In a declaration inside a function,
if a storage class but no type
is given, the identifier is assumed
to be \fGint\fR;
if a type but no storage class is indicated,
the identifier is assumed to
be \fGauto\fR.
An exception to the latter rule is made for
functions, since \fGauto\fR functions are mean$ing$less
(C being incapable of compiling code into the stack).
If the type of an identifier is ``function returning ...'',
it is implicitly declared to be \fGextern\fR.
.pg
In an expression, an identifier
followed by \fG(\fR and not currently declared
is contextually
declared to be ``function returning \fGint\fR''.
.pg
Undefined identifiers not followed by \fG(\fR
are assumed to be labels which
will be defined later in the function.
(Since a label is not an lvalue, this accounts
for the ``Lvalue required'' error
message
sometimes noticed when
an undeclared identifier is used.)
Naturally, appearance of
an identifier as a label declares it as such.
.pg
For some purposes it is best to consider formal
parameters as belonging to their own storage class.
In practice, C treats parameters as if they
were automatic (except that, as mentioned
above, formal parameter arrays and \fGfloat\fRs
are treated specially).
.ul
14.  Types revisited
.et
This section summarizes the operations
which can be performed on objects of certain types.
.ms
14.1  Structures
.et
There are only two things that can be done with
a structure:
pick out one of its members (by means of the
\fG^.^\fR or \fG\(mi>\fR operators); or take its address (by unary \fG&\fR).
Other operations, such as assigning from or to
it or passing it as a parameter, draw an
error message.
In the future, it is expected that
these operations, but not necessarily
others, will be allowed.
.ms
14.2  Functions
.et
There are only two things that
can be done with a function:
call it, or take its address.
If the name of a function appears in an
expression not in the function-name position of a call,
a pointer to the function is generated.
Thus, to pass one function to another, one
might say
.bG
.sp .7
.nf
	int f(^^);
	...
	g(^f^);
.sp .7
.eG
.ft R
Then the definition of \fIg \fRmight read
.sp .7
.bG
	g^(^funcp^)
	int (\**funcp)^(^^);
	{
		.^.^.
		(\**funcp)^(^^);
		.^.^.
	}
.sp .7
.eG
.fi
Notice that \fIf\fR was declared
explicitly in the calling routine since its first appearance
was not followed by \fG(\fR^.
.ms
14.3  Arrays, pointers, and subscripting
.et
Every time an identifier of array type appears
in an expression, it is converted into a pointer
to the first member of the array.
Because of this conversion, arrays are not
lvalues.
By definition, the subscript operator
\fG[^]\fR is interpreted
in such a way that
``E1[E2]'' is identical to
``\**(^(^E1)^+^(E2^)^)''.
Because of the conversion rules
which apply to \fG+\fR, if E1 is an array and E2 an integer,
then E1[E2] refers to the E2-th member of E1.
Therefore,
despite its asymmetric
appearance, subscripting is a commutative operation.
.pg
A consistent rule is followed in the case of
multi-dimensional arrays.
If E is an \fIn^\fR-dimensional
array
of rank
.ft I
i^\(mu^j^\(mu^.^.^.^\(muk,
.ft R
then E appearing in an expression is converted to
a pointer to an (\fIn\fR\(mi1)-dimensional
array with rank
.ft I
j^\(mu^.^.^.^\(muk.
.ft R
If the \fG\**\fR operator, either explicitly
or implicitly as a result of subscripting,
is applied to this pointer,
the result is the pointed-to (\fIn\fR\(mi1)-dimensional array,
which itself is immediately converted into a pointer.
.pg
For example, consider
.sp .7
.bG
	int x[3][5];
.sp .7
.eG
Here \fIx\fR is a 3\(mu5 array of integers.
When \fIx\fR appears in an expression, it is converted
to a pointer to (the first of three) 5-membered arrays of integers.
In the expression ``x[^i^]'',
which is equivalent to ``\**(x+i)'',
\fIx\fR is first converted to a pointer as described;
then \fIi\fR is converted to the type of \fIx\fR,
which involves multiplying \fIi\fR by the
length the object to which the pointer points,
namely 5 integer objects.
The results are added and indirection applied to
yield an array (of 5 integers) which in turn is converted to
a pointer to the first of the integers.
If there is another subscript the same argument applies
again; this time the result is an integer.
.pg
It follows from all this that arrays in C are stored
row-wise (last subscript varies fastest)
and that the first subscript in the declaration helps determine
the amount of storage consumed by an array
but plays no other part in subscript calculations.
.ms
14.4  Labels
.et
Labels do not
have a type of their own; they are
treated
as having type ``array of \fGint\fR''.
Label variables should be declared ``pointer
to \fGint\fR'';
before execution of a \fGgoto\fR referring to the
variable,
a label (or an expression
deriving from a label) should be assigned to the
variable.
.pg
Label variables are a bad idea in general;
the \fGswitch\fR statement makes them
almost always unnecessary.
.ul
15.  Constant expressions
.et
In several places C requires expressions which evaluate to
a constant:
after
.ft G
case,
.ft R
as array bounds, and in initializers.
In the first two cases, the expression can
involve only integer constants, character constants,
and
.ft G
sizeof
.ft R
expressions, possibly
connected by the binary operators
.tr ^^
.dp
	+   \(mi   \**   /   %   &   \(or   ^   <<   >>
.ed
or by the unary operators
.dp
	\(mi   \*~
.ed
.tr ^\|
Parentheses can be used for grouping,
but not for function calls.
.pg
A bit more latitude is permitted for initializers;
besides constant expressions as discussed above,
one can also apply the unary \fG&\fR
operator to external scalars,
and to external arrays subscripted
with a constant expression.
The unary \fG&\fR can also
be applied implicitly
by appearance of unsubscripted external arrays.
The rule here is that initializers must
evaluate either to a constant or to the address
of an external identifier plus or minus a constant.