p2c.man

把pascal程序转成C语言程序 把pascal程序转成C语言程序

.TP
.B StrlapFunction
Functions on this list are structured functions as above, but with the
ability to work in-place; that is, the same pointer may be passed as both the
return value area and a regular parameter.
.TP
.B Deterministic
Functions on this list have no side effects or side dependencies.
An example is the
.I sin
function in the standard math library; two calls with the same parameter
values produce the same result, and have no effects other than returning
a value.
.I P2c
can make use of this knowledge when optimizing code for efficiency or
readability.  Functions on this list are also assumed to be relatively
fast, so that it is acceptable to duplicate a call to the function.
.TP
.B LeaveAlone
Functions on this list are not subjected to the normal built-in translation
rules that
.I p2c
would otherwise use.  For example, adding
.I writeln
to this list would translate
.I writeln
statements blindly into calls to a C
.I writeln()
function, rather than being translated into equivalent
.I printf
calls.  The built-in translation is also suppressed if the function has a
.BR FuncMacro .
.TP
.B BufferedFile
.I P2c
normally assumes binary files will use
.I read/write,
not
.I get/put/^
notation.
A file buffer variable will only be created for a file if buffer notation
is used for it.  For global file variables this may be detected too late
(a declaration without buffers may already have been written).  Such files
can be listed in
.B BufferedFile
to force
.I p2c
to allocate buffers for them; do this if you get a warning
message that says it is necessary.  Set
.BR BufferedFile =1
to buffer all files, in which case
.B UnBufferedFile
allows you to force certain files
.I not
to have buffers.
.TP
.B StructFiles
If
.I p2c
still can't translate your file operations correctly, you can set
.BR StructFiles =1
to cause Pascal files to translate into structs which include the usual C
.I FILE
pointer, as well as file buffer and file name fields.  While the resulting
code doesn't look as much like native C, the file structs will allow
.I p2c
to do a correct translation in many more cases.
.TP
.B CheckFileEOF
Normally only file-open operations are checked for errors.  Additional
error checking, such as read-past-end-of-file, can be enabled with
parameters like
.BR CheckFileEOF .
These checks can make the code very ugly!  If I/O checking is enabled
by the program
.RB ( "$iocheck on$"
in HP Pascal;
.B {$I+}
in Turbo; this is always the default state),
these checks will generate fatal errors unless enclosed in an HP Pascal
.BR try - recover
construct.  If I/O checking is disabled, these will cause the global
variable
.I P_ioresult
to be set zero or nonzero according to the outcome.  The default for most
of these options is to check only when I/O checking is enabled.
.SH ISSUES
.B Integer size.
.I P2c
normally generates code to work with either 16 or 32 bit ints.
If you know your C integers will be 16 or 32 bits, set
.B IntSize
appropriately.  In particular setting
.BR IntSize =32
will generate much cleaner code:
.I p2c
no longer must carefully cast function arguments between int and long.
These casts also will be unnecessary if ANSI prototypes are available.
To disable int/long casting because you know at least one of these
cases will hold, set
.BR CastLongArgs =0.
(The
.B CastArgs
parameter similarly controls other types of casts, such as between ints
and doubles.)
The
.B Integer16
parameter controls whether Pascal integers are interpreted as 16 or 32
bits, or translated as native C integers.  The default value depends on the
.B Language
selected.
.PP
.B Signed/unsigned chars.
Pascal characters are normally "weakly" interpreted as unsigned; this
is controlled by
.BR UnsignedChar .
The default is "either," so that C's native
.B char
type may be used even if its signed-ness is unknown.  Code that uses
characters outside of the range 0-127 may need a different setting.
Alternatively, you can use the types
.B {SIGNED} char
and
.B {UNSIGNED} char
in the few cases where it really matters.  These comments are controlled
by the
.B SignedComment
and
.B UnsignedComment
parameters.  (The type
.B {UNSIGNED} integer
is also recognized.)  The
.B SignedChar
parameter tells whether C characters are signed or unsigned (default is
"unknown").  The
.B HasSignedChar
parameter tells whether the phrase "signed char" is legal in the output.
If it is not,
.I p2c
may have to translate Pascal signed bytes into C shorts.
.PP
.B Special types.
.I P2c
understands the following predefined Pascal type names:
.BR integer ,
signed integers depending on
.BR Integer16 ;
.BR longint ,
signed 32-bit integers;
.BR unsigned ,
unsigned 32-bit integers;
.BR sword ,
signed 16-bit integers;
.BR word ,
unsigned 16-bit integers;
.BR c_int ,
signed native C integers;
.BR c_uint ,
unsigned native C integers;
.BR sbyte ,
signed 8-bit integers;
.BR byte ,
unsigned 8-bit integers;
.BR real ,
floating-point numbers depending on
.BR DoubleReals ;
.BR single ,
single-precision floats;
.BR longreal ,
.BR double ,
and
.BR extended ,
double-precision floats;
.B pointer
and
.BR anyptr ,
generic pointers (assignment-compatible with any pointer type);
.BR string ,
generic string of length
.B StringDefault
(normally 255);
also, the usual Pascal types
.BR char ,
.BR boolean ,
and
.BR text .
(If your Pascal uses different names for these concepts, the
.B Synonym
option will come in handy.)
.PP
.B Embedded code.
It is possible to write a Pascal comment containing C code to
be embedded into the output.  See the descriptions of
.B EmbedComment
and its relatives in the system
.I p2crc
file.  These techniques are helpful if you plan to do repeated translations
of code that is still being maintained in Pascal.  See the description of
.B ReplaceBefore
for an example use of embedded code.
.PP
.B Comments and blank lines.
.I P2c
collects the comments in a procedure into a list.  All comments and statements
are stamped with serial numbers which are used to reattach comments to
statements even after code has been added, removed, or rearranged during
translation.  "Orphan" comments attached to statements that have been lost
are attached to nearby statements or emitted at the end of the procedure.
Blank lines are treated as a kind of comment, so
.I p2c
will also reproduce your usage of blank lines.  If the comment mechanism
goes awry, you can disable comments with
.B EatComments
or disable their being attached to code with
.BR SpitComments .
.PP
.B Indentation.
.I P2c
has a number of parameters to govern indentation of code.  The default
values produce the GNU Emacs standard indentation style, although
.I p2c
can do a better job since it knows more about the code it is indenting.
Indentation works by applying "indentation deltas," which are either
absolute numbers (which override the previous indentation), or signed
relative numbers (which augment the previous indentation).  A delta of
"+0" specifies no change in indentation.  All of the indentation
options are described in the standard
.I p2crc
file.
.PP
.B Line breaking.
.I P2c
uses an algorithm similar to the TeX typesetter's paragraph formatter
for breaking long statements into multiple lines.  A "penalty" is assigned
to various undesirable aspects of all possible line breaks; the "badness"
of a set of line breaks is approximately the sum of all the penalties.
Chief among these are serious penalties for overrunning the desired maximum
line length (default 78 columns),
an infinite penalty for overrunning the absolute
maximum line length (default 90), and progressively greater penalties for
breaking at operators deeply nested in expressions.  Parameters such as
.B OpBreakPenalty
control the relative weights of various choices.
.B BreakArith
and its neighbors control whether the operator at a line break should be
placed at the end of the previous line or at the beginning of the next.
If you don't want any oversize lines, define
.BR MaxLineWidth =78.
.PP
Unlike TeX,
.IR p2c 's
line breaker must actually try all possible sets of break points.  To
avoid excessive computation, the total penalty contributed at each decision
point must sum to a nonnegative value; negative values are clipped up to zero.
This allows
.I p2c
to prune away obviously undesirable alternatives in advance.  The
.B MaxLineBreakTries
parameter (default 5000) controls how many alternatives to try before
giving up and using the best so far.
.PP
.B PASCAL_MAIN.
.I P2c
generates a call to this function at the front of the main program.
In the (unmodified) run-time library all this does is save argc and argv
away because in both HP and Turbo these are accessed as global variables.
If you do not wish to use this feature, define
.B ArgCName
to be
.I argc,
.B ArgVName
to be
.I argv,
and
.B MainName
(normally "PASCAL_MAIN") to be blank.  This will work if argc and argv
are never accessed outside of your main program.
.SH BUGS
.I P2c
was designed with the idea that clean, readable output in most cases is
worth more than guaranteed correct output in extreme cases.
.I P2c
is
.I not
a compiler!  However, ideally the "extreme" cases would include only those
which never arise in real life.  Thus if
.I p2c
actually generates incorrect code I will consider it a bug, but I will not
apologize for it. :-)  Below are the major remaining cases where this is
known to occur.
.PP
Certain kinds of conformant array parameters (including multi-dimensional
conformant arrays) produce code that declares variable-length arrays in C.
Only a few C compilers, such as the GNU C compiler, support this language
extension.  Otherwise some hand re-coding will be required.
.PP
HP Pascal
.BR try - recover
structures are translated into calls to
.I TRY
and
.I RECOVER
macros, which are defined to simulate the construct using
.I setjmp
and
.I longjmp.
If this emulation does not work, define the symbol
.B FAKE_TRY
to cause these macros to become "inert."  (In cases where the
error is detected by code physically within the body of the
.B try
statement, a C
.B goto
to the
.B recover
section is always generated.)  Also, local file variables in scopes which
are destroyed by an
.B escape
are not closed.
.PP
Non-local GOTO's and
.BR try - recover
statements are each implemented, but may
conflict if both are used at once.  Non-local GOTO's are fairly careful
about closing files that go out of scope but may fail to do so in the presence
of recursion.
.PP
Arrays containing files are not initialized to NULL as other files are.
In some cases, such as file variables allocated by NEW, the file is
initialized but not automatically closed by DISPOSE.
.PP
LINK variables allowing sub-procedures access to their parents' variables
are occasionally omitted by mistake, if the access is too indirect for
.I p2c
to notice.  If this happens, you can add an explicit reference to a parent
variable in the sub-procedure.  A statement of the form "a:=a" will count
as a reference but then be optimized away by
.I p2c.
.PP
Many aspects of Modula-2 are translated only superficially.  For example,
the type-compatibility properties of the
.I WORD
and
.I ARRAY OF WORD
types are only roughly modelled, as are the scope rules concerning modules.
.PP
Parts of VAX Pascal are still untreated.  In particular, the
.I [UNSAFE]
attribute and a few others are not fully supported,
nor are the semantics of the
.I OPEN
procedure.
.PP
Turbo and VAX Pascal's
.I double, quadruple,
and
.I extended
real types all translate to the C
.B double
type.  Turbo's
.I computational
type is not supported at all.
.PP
Because Pascal strings (with length bytes) are translated into C strings
(with null terminators), certain Pascal string tricks will not work in
the translated code.  For example the assignment
.I s[0]:=chr(x)
is translated to
.I s[x]=0
on the assumption that the string is being shortened.  If
.I x
is actually greater than the current length, but not of a recognizable
form like
.I ord(s[0])+n,
then the generated code will not work.  In VAX Pascal this corresponds
to performing arithmetic on the
.I LENGTH
field of a varying-length string.
.PP
Turbo Pascal's automatic clipping of strings is not supported.  In
Turbo, if a ten character string is assigned to a
.I string[8]
variable, the last two characters are silently removed.  The code
produced by
.I p2c
generally will overrun the target string instead!  The
.B StringTruncLimit
parameter (80 by default if
.BR Language = Turbo )
specifies a string size which should be considered "short"; assignments
of potentially-long strings to short string variables will cause a warning
but will not automatically truncate.  The cure is to use
.I copy
in the Pascal source to truncate the strings explicitly.
.SH FILES
.ta \w'--INCDIR--/p2c.h 'u
file.\fIxxx\fR	Pascal source files
.br
file.c	resulting C source file
.br
module.h	resulting C header file
.br
p2crc	local configuration file
.br
\&.p2crc	alternate local configuration file
.br
--HOMEDIR--/p2crc	system-wide configuration file
.br
--HOMEDIR--/system.imp	declarations for predefined functions
.br
--HOMEDIR--/system.m2	analogous declarations for Modula-2
.br
--HOMEDIR--/*.imp	interface text for standard modules
.br
--INCDIR--/p2c.h	header file for translated programs
.br
--LIBDIR--/libp2c.a	run-time library
.SH AUTHOR
Dave Gillespie, [e-mail].
.PP
Many thanks to William Bader, Steven Levi, Rick Koshi, Eric Raymond,
Magne Haveraaen, Dirk Grunwald, David Barto, Paul Fisher, Tom Schneider,
Dick Heijne, Guenther Sawitzki,
and many others whose suggestions and bug reports have helped improve
.I p2c
in countless ways.