puman3.n

早期freebsd实现

.I ops
in the example above or
.I color
in
.LS
\*btype\fP color = (red, green, blue)
.LE
For integers, the more explicit denotation
.I integer
is used.
Although it would be correct, in the context of the
.I "User Manual"
to refer to an integer variable as a
.I scalar
variable
.PI
prefers the more specific identification.
.SH
Function and procedure type errors
.PP
For built-in procedures and functions, two kinds of errors occur.
If the routines are called with the wrong number of arguments a message similar to:
.LS
.so sinout1
.LE
is given.
If the type of the argument is wrong, a message like
.LS
.so sinout2
.LE
is produced.
A few functions and procedures implemented in Pascal 6000-3.4 are
diagnosed as unimplemented in
Berkeley
Pascal, notably those related to
.B segmented 
files.
.SH
Can't read and write scalars, etc.
.PP
The messages which state that scalar (user-defined) types
cannot be written to and from files are often mysterious.
It is in fact the case that if you define
.LS
\*btype\fP color = (red, green, blue)
.LE
``standard'' Pascal does not associate these constants with the strings
`red', `green', and `blue' in any way.
An extension has been added which allows enumerated types
to be read and written, 
however if the program is to be portable,
you will have to write your own routines to perform these functions.
Standard Pascal only allows the reading of characters, integers and real
numbers from text files.
You cannot read strings or Booleans.
It is possible to make a
.LS
\*bfile of\fP color
.LE
but the representation is binary rather than string.
.SH
Expression diagnostics
.PP
The diagnostics for semantically ill-formed expressions are very explicit.
Consider this sample translation:
.LS
% \*bpi -l expr.p\fP
.so exprout
%
.LE
This example is admittedly far-fetched, but illustrates that the error
messages are sufficiently clear to allow easy determination of the
problem in the expressions.
.SH
Type equivalence
.PP
Several diagnostics produced by the Pascal translator complain about
`non-equivalent types'.
In general,
Berkeley
Pascal considers variables to have the same type only if they were
declared with the same constructed type or with the same type identifier.
Thus, the variables
.I x
and
.I y
declared as
.LS
\*bvar\fP
    x: ^ integer;
    y: ^ integer;
.LE
do not have the same type.
The assignment
.LS
x := y
.LE
thus produces the diagnostics:
.LS
.so typequout
.LE
Thus it is always necessary to declare a type such as
.LS
\*btype\fP intptr = ^ integer;
.LE
and use it to declare
.LS
\*bvar\fP x: intptr; y: intptr;
.LE
Note that if we had initially declared
.LS
\*bvar\fP x, y: ^ integer;
.LE
then the assignment statement would have worked.
The statement
.LS
x^ := y^
.LE
is allowed in either case.
Since the parameter to a
.B procedure
or
.B function
must be declared with a
type identifier rather than a constructed type,
it is always necessary, in practice,
to declare any type which will be used in this way.
.SH
Unreachable statements
.PP
Berkeley
Pascal flags unreachable statements.
Such statements usually correspond to errors in the program logic.
Note that a statement is considered to be reachable
if there is a potential path of control,
even if it can never be taken.
Thus, no diagnostic is produced for the statement:
.LS
\*bif\fP false \*bthen\fP
    writeln('impossible!')
.LE
.SH
Goto's into structured statements
.PP
The translator detects and complains about
.B goto
statements which transfer control into structured statements (\c
.B for ,
.B while ,
etc.)
It does not allow such jumps, nor does it allow branching from the
.B then
part of an
.B if
statement into the
.B else
part.
Such checks are made only within the body of a single procedure or
function.
.SH
Unused variables, never set variables
.PP
Although
.PI
always clears variables to 0 at
.B procedure
and
.B function
entry,
.PC
does not unless runtime checking is enabled using the
.B C
option.
It is
.B not
good programming practice to rely on this initialization.
To discourage this practice, and to help detect errors in program logic,
.PI
flags as a `w' warning error:
.IP
.RS
.HP 1)
Use of a variable which is never assigned a value.
.IP 2)
A variable which is declared but never used, distinguishing
between those variables for which values are computed but which are never
used, and those completely unused.
.RE
.LP
In fact, these diagnostics are applied to all declared items.
Thus a
.B const
or a
.B procedure
which is declared but never used is flagged.
The
.B w
option of
.PI
may be used to suppress these warnings;
see sections 5.1 and 5.2.
.NH 2
Translator panics, i/o errors
.SH
Panics
.PP
One class of error which rarely occurs, but which causes termination
of all processing when it does is a panic.
A panic indicates a translator-detected internal inconsistency.
A typical panic message is:
.LS
snark (rvalue) line=110 yyline=109
Snark in pi
.LE
If you receive such a message, the translation will be quickly and perhaps
ungracefully terminated.
You should contact a teaching assistant or a member of the system staff,
after saving a copy of your program for later inspection.
If you were making changes to an existing program when the problem
occurred, you may
be able to work around the problem by ascertaining which change caused the
.I snark
and making a different change or correcting an error in the program.
A small number of panics are possible in
.X .
All panics should be reported to a teaching assistant or systems
staff so that they can be fixed.
.SH
Out of memory
.PP
The only other error which will abort translation when no errors are
detected is running out of memory.
All tables in the translator, with the exception of the parse stack,
are dynamically allocated, and can grow to take up the full available
process space of 64000 bytes on the \s-2PDP\s0-11.  On the \s-2VAX\s0-11,
table sizes are extremely generous and very large (25000) line programs
have been easily accommodated.  For the \s-2PDP\s0\-11, it is
generally true that
the size of the largest translatable program is directly related to
.B procedure
and
.B function
size.
A number of non-trivial Pascal programs, including
some with more than 2000 lines and 2500 statements
have been translated and interpreted using
Berkeley
Pascal on \s-2PDP\s0-11's.
Notable among these are the Pascal-S
interpreter,
a large set of programs for automated generation of
code generators,
and a general context-free parsing program which has been used to
parse sentences with a grammar for a superset of English.
In general,
very large programs should be translated using
.PC
and the separate compilation facility.
.PP
If you receive an out of space message from the translator 
during translation of a large
.B procedure
or
.B function
or one containing a large number of string constants
you may yet be able
to translate your program if you break this one
.B procedure
or
.B function
into several routines.
.SH
I/O errors
.PP
Other errors which you may encounter when running
.PI
relate to input-output.
If
.PI
cannot open the file you specify,
or if the file is empty,
you will be so informed.
.NH 2
Run-time errors
.PP
We saw, in our second example, a run-time error.
We here give the general description of run-time errors.
The more unusual interpreter error messages are explained
briefly in the manual section for
.I px 
(1).
.SH
Start-up errors
.PP
These errors occur when the object file to be executed is not available
or appropriate.
Typical errors here are caused by the specified object file not existing,
not being a Pascal object, or being inaccessible to the user.
.SH
Program execution errors
.PP
These errors occur when the program interacts with the Pascal runtime
environment in an inappropriate way.
Typical errors are values or subscripts out of range,
bad arguments to built-in functions,
exceeding the statement limit because of an infinite loop,
or running out of memory\*(dd.
.FS
\*(ddThe checks for running out of memory are not foolproof and there
is a chance that the interpreter will fault, producing a core image
when it runs out of memory.
This situation occurs very rarely.
.FE
The interpreter will produce a backtrace after the error occurs,
showing all the active routine calls,
unless the
.B p
option was disabled when the program was translated.
Unfortunately, no variable values are given and no way of extracting them
is available.*
.FS
* On the \s-2VAX\s0-11, each variable
is restricted to allocate at most 65000 bytes of storage (this is a
\s-2PDP\s0-11ism that has survived to the \s-2VAX\s0.)
.FE
.PP
As an example of such an error, assume that we have accidentally
declared the constant
.I n1
to be 6, instead of 7
on line 2 of the program primes as given in section 2.6 above.
If we run this program we get the following response.
.LS
% \*bpix primes.p\fP
.so primeout3
%
.LE
.PP
Here the interpreter indicates that the program terminated
abnormally due to a subscript out of range near line 14,
which is eight lines into the body of the program primes.
.SH
Interrupts
.PP
If the program is interrupted while executing
and the
.B p
option was not specified,
then a backtrace will be printed.\*(dg
.FS
\*(dgOccasionally, the Pascal system will be in an inconsistent
state when this occurs,
e.g. when an interrupt terminates a
.B procedure
or
.B function
entry or exit.
In this case, the backtrace will only contain the current line.
A reverse call order list of procedures will not be given.
.FE
The file
.I pmon.out
of profile information will be written if the program was translated
with the
.B z
option enabled to
.PI
or
.IX .
.SH
I/O interaction errors
.PP
The final class of interpreter errors results from inappropriate
interactions with files, including the user's terminal.
Included here are bad formats for integer and real numbers (such as
no digits after the decimal point) when reading.