p2c.man

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

Modula-2.  Based on Wirth's
.I Programming in Modula-2,
3rd edition.  Proper setting of the
.B Language
parameter is
.I not
optional.  Translation will be incomplete in most cases, but should be
good enough to work with.  Structure of local sub-modules is essentially
ignored; like-named identifiers may be confused.  Type WORD is translated
as an integer, but type ADDRESS is translated as char * or void *; this
may cause inconsistencies in the output code.
.IP
Modula-2 modules have two parts in separate files.  Suppose these are
called
.I foo.def
(definition part) and
.I foo.mod
(implementation part) for module
.I foo.
Then a pattern like
.B %s.def
must be included in the
.B ImportDir
list, and
.B LibraryFile
must be changed to refer to
.I system.m2
instead of
.I system.imp.
To translate the definition part, give the command
.IP
\ \ \ \ \ p2c foo.def
.IP
to translate the definition part into files
.I foo.h
and
.IR foo.c ;
the latter will usually be empty.  The command
.IP
\ \ \ \ \ p2c -s foo.def foo.mod
.IP
will translate the implementation part into file
.I foo.c.
.PP
Even if all language features are supported for a dialect, some
predefined functions may be omitted.  In these cases, the function call
will be translated literally into C with a warning.  Some hand modification
may be required.
.SH CONFIGURATION PARAMETERS
.I P2c
is highly configurable.  The defaults are suitable for most applications,
but customizing these parameters will help you get the best possible
translation.  Since the output of
.I p2c
is intended to be used as human-maintainable source code, there are many
parameters for describing the coding style and conventions you prefer.
Others give hints about your program that help
.I p2c
to generate more correct, efficient, or readable code.
.PP
The
.I p2crc
files contain a list of parameters, one per line.  The system
configuration file, which may be viewed using the
.B \-i
option to
.I p2c,
serves as an example of the proper format.  Parameter names are
case-insensitive.  If a parameter name occurs exactly once in the system
.I p2crc,
this indicates that it must have a unique value and the last value given to
it by the
configuration files is used.  Other parameters are written several times
in a row; these are lists to which each configuration line adds an entry.
.PP
Many
.I p2crc
options take a numeric value of 0 or 1, roughly corresponding to
"no" or "yes."  Sometimes a blank value or the value "\fBdef\fR"
corresponds to an intermediate "maybe" state.  For example, the stylistic
option
.B ExtraParens
switches between copious or minimal parentheses in expressions, with
the default being a nice compromise intended to be best for readers
with an average knowledge of C operator precedences.
.PP
Configuration options may also be embedded in the source file in the
form of Pascal comments:
.PP
\ \ \ \ \ {ShortOpt=0} {AvoidName=fred}
.br
\ \ \ \ \ {FuncMacro slope(x,y)=atan2(y,x)*RadDeg}
.PP
disables automatic short-circuiting of
.B and
and
.B or
expressions, adds "\fIfred\fR" to the list of names to avoid using in
generated C code, and defines a special translation for the Pascal
program's
.I slope
function 
using the standard C
.I atan2
function and a constant
.I RadDeg
presumably defined in the program.  Whitespace is generally not allowed
in embedded parameters.
The `=' sign is required for embedded parameters, though it is optional in
.I p2crc
files.  Comments within embedded parameters are delimited by `##'.
Numeric parameters may replace `=' with `+' or `-' to increase
or decrease the parameter; list-based parameters may use `-' to remove
a name from a list rather than adding it.  Also, the parameter name
by itself in comment braces means to restore the parameter's value
that was current before the last change:
.PP
\ \ \ \ \ {VarFiles=0  ## Pass FILE *'s params by value even if VAR}
.br
.I \ \ \ \ \ some declarations
.br
\ \ \ \ \ {VarFiles    ## Back to original FILE * passing}
.PP
causes the parameter
.B VarFiles
to have the value 0 for those few declarations, without affecting the
parameter's value elsewhere in the file.
.PP
If an embedded parameter appears in an include file or in interface text
for a module,
the effect of the assignment normally carries over to any programs that
included that file.  If the parameter name is preceded by a `*', then
the assignment is automatically undone after the source file that contains
it ends:
.PP
\ \ \ \ \ {IncludeFrom strings=<p2c/strings.h>}
.br
\ \ \ \ \ {*ExportSymbol=pascal_%s}
.br
\ \ \ \ \ module strings;
.PP
will record the location of the
.I strings
module's include file for the rest of the translation, but the assignment
of
.B ExportSymbol
pertains only to the module itself.
.PP
For the complete list of
.I p2crc
parameters, run
.I p2c
with the
.B \-i
option.  Here are some additional comments on selected parameters:
.TP 15
.B ImportAll
Because Turbo Pascal only allows one unit per source file,
.I p2c
normally stops reading past the word
.I implementation
in a file being scanned for interface text.  But HP Pascal allows several
modules per file and so this would not be safe to do.  The
.B ImportAll
option lets you override the default behavior for your Pascal dialect.
.TP
.B AnsiC
This parameter selects which dialect of C to use.  If 1, all conventions
of ANSI C such as prototypes,
.B void *
pointers, etc. are used.  If 0, only strict K&R (first edition) C is used.
The default is to use "traditional UNIX C," which includes
.B enum
and
.B void
but not
.B void *
or prototypes.  Once again there are a number of other parameters which
may be used to control the individual features if just setting
.B AnsiC
is not enough.
.TP
.B C++
This tells
.I p2c
to use a number of language extensions present in C++:  Specifically,
it enables the "//" format for comments, use of "anonymous unions" for
variant records, use of declarations within the function body, use of
references for VAR parameters, and use of "new" and "delete" instead
of "malloc" and "free".
.I P2c
will check for collisions with C++ reserved words unless you
explicitly set the C++ option to zero.
.TP
.B TurboObjects
.I P2c
recognizes two major dialects of object-oriented Pascal.  Turbo
Pascal 6.0
.B object
types translate fairly directly into C++ classes.  In Apple's
Object Pascal, the
.B object
type has similar syntax but represents a handle (a double pointer)
to an object rather than an object itself.  The
.B TurboObjects
option (whose default is determined by the
.B Language
setting) says whether objects should be direct or indirect
through pointers.
.RI ( P2c
uses pointers instead of handles;
.I p2c
is most often used to make programs more portable, and few systems
except the Mac use handles in this way.)
.TP
.B UseVExtern
Many non-UNIX linkers prohibit variables from being defined (not declared)
by more than one source file.  One module must declare, e.g., "int foo;",
and all others must declare "extern int foo;".
.I P2c
accomplishes this by declaring public variables "\fBvextern\fR"
in header files, and arranging for the macro
.B vextern
to expand to
.B extern
or to nothing when appropriate.  If you set
.BR UseVExtern =0
.I p2c
will instead declare variables in a simpler way that works only on
UNIX-style linkers.
.TP
.B UseAnyptrMacros
Certain C reserved words have meanings which may vary from one C
implementation to another.
.I P2c
uses special capitalized names for these words; these names are
defined as macros in the file
.I p2c.h
which all translated programs include.  You can set
.BR UseAnyptrMacros =0
to disable the use of these macros.  Note that the functions of many of
these macros can also be had directly using other parameters; for example,
.B UseConsts
allows you to specify whether your target language recognizes the word
.B const
in constant declarations.  The default is to use the
.B Const
macro instead, so that your code will be portable to either kind of
implementation.
.IP
.B Signed
expands to the reserved word
.B signed
if that word is available, otherwise it is given a null definition.
Similarly,
.B Const
expands to
.B const
if that feature is available.  The words
.B Volatile
and
.B Register
are also defined in
.I p2c.h,
although
.I p2c
does not use them at present.  The word
.B Char
expands to
.B char
by default, but might need to be redefined to
.B signed char
or
.B unsigned char
in a particular implementation.  This is used for the Pascal character
type; lowercase
.B char
is used when the desired meaning is "byte," not "character."
.IP
The word
.B Static
always expands to
.B static
by default.  This is used in situations where a function or variable is
declared static to make it local to the source file; lowercase
.B static
is used for static local variables.  Thus you can redefine
.B Static
to be null if you want to force private names to be public for purposes
of debugging.
.IP
The word
.B Void
expands to
.B void
in all cases; it is used when declaring a function with no return value.
The word
.B Anyptr
is a typedef for
.B void *
or
.B char *
as necessary; it represents a generic pointer.
.TP
.B UsePPMacros
The
.I p2c.h
header also declares two macros for function prototyping,
.BR PP (x)
and
.BR PV ().
These macros are used as follows:
.IP
\ \ \ \ \ Void foo  PP( (int x, int y, Char *z) );
.br
\ \ \ \ \ Char *bar PV( );
.IP
If prototypes are available, these macros will expand to
.IP
\ \ \ \ \ Void foo  (int x, int y, Char *z);
.br
\ \ \ \ \ Char *bar (void);
.IP
but if only old-style declarations are supported, you instead get
.IP
\ \ \ \ \ Void foo  ();
.br
\ \ \ \ \ Char *bar ();
.IP
By default,
.I p2c
uses these macros for all function declarations, but function
.I definitions
are written in old-style C.  The
.B UsePPMacros
parameter can be set to 0 to disable all use of
.B PP
and
.BR PV ,
or it can be set to 1 to use the macros even when defining a function.
(This is accomplished by preceding each old-style definition with a
.BR PP -style
declaration.)  If you know your code will always be
compiled on systems that support prototyping, it is prettier to set
.BR Prototypes =1
or simply
.BR AnsiC =1
to get true function prototypes.
.TP
.B EatNotes
Notes and warning messages containing any of these strings as sub-strings
are not emitted.  Each type of message includes an identifier like
.BR [145] ;
you can add this identifier to the
.B EatNotes
list to suppress that message.  Another useful form is to use a variable
name or other identifier to suppress warnings about that variable.  The
strings are a space-separated list, and thus may not contain embedded spaces.
To suppress notes around a section of code, use, e.g.,
.I {EatNotes+[145]}
and
.I {EatNotes-[145]}.
Most notes are generated during parsing, but to suppress those generated
during output the string may need to remain in the list far beyond the point
where it appears to be generated.  Use the string "1" or "0" to disable or
enable all notes, respectively.
.TP
.B ExpandIncludes
The default action is to expand Pascal include files in-line.  This
may not be desirable if include files are being used to simulate modules.
With
.BR ExpandIncludes =0,
.I p2c
attempts to convert include files containing only whole procedures and
global declarations into analogous C include files.  This may not always
work, though; if you get error messages, don't use this option.  By
combining this option with
.BR StaticFunctions =0,
then doing some fairly minor editing on the result, you can convert
a pseudo-modular Pascal program into a truly modular collection of C
source files.
.TP
.B ElimDeadCode
Some transformations that
.I p2c
does on the program may result in unreachable or "dead" code.  By
default
.I p2c
removes such code, but sometimes it removes more than it should.
If you have "if false" segments which you wish to retain in C, you
may have to set
.BR ElimDeadCode =0.
.TP
.B AnalyzeFlow
By default
.I p2c
does some basic dataflow analysis on the program in an attempt to
locate code that can be simplified due to knowledge about the
possible values of certain variables.  For example, a Pascal
.B rewrite
statement must translate to an
.B if
that either calls
.B fopen
on a formerly closed file variable, or
.B freopen
on an already-open file.  If flow analysis can prove that the
file was open or closed upon entry to the statement, a much
cleaner translation is possible.
.IP
It is possible that flow analysis will make simplifications
that are undesirable or buggy.  If this occurs, you can set
.B AnalyzeFlow
to 0 to disable this feature.
.TP
.B SkipIndices
Normally Pascal arrays not based at zero are "shifted" down for C,
preserving the total size of the array.  A Pascal array a[2..10] is
translated to a C array a[9] with references like "a[i]" changed to
"a[i-2]" everywhere.  If
.B SkipIndices
is set to a value of 2 or higher, this array would instead be translated
to a[11] with the first two elements never used.  This arrangement may
generate incorrect code, though, for tricky source programs.
.TP
.B FoldConstants
Pascal non-structured constants generally translate to
.BR #define 's
in C.  Set this to 1 to have constants instantiated directly into the