513 lines
21 KiB
Plaintext
513 lines
21 KiB
Plaintext
TABLE OF CONTENTS
|
||
|
||
devtools.doc/cpp
|
||
devtools.doc/rpcgen
|
||
utilities/rcsrev
|
||
devtools.doc/cpp devtools.doc/cpp
|
||
|
||
NAME
|
||
cpp - C Pre-Processor
|
||
|
||
SYNOPSIS
|
||
cpp [-options] [infile [outfile]]
|
||
|
||
DESCRIPTION
|
||
CPP reads a C source file, expands macros and include files, and
|
||
writes an input file for the C compiler. If no file arguments are
|
||
given, CPP reads from stdin and writes to stdout. If one file
|
||
argument is given, it will define the input file, while two file
|
||
arguments define both input and output files. The file name "-" is
|
||
a synonym for stdin or stdout as appropriate.
|
||
|
||
The following options are supported. Options may be given in either
|
||
case.
|
||
|
||
-C If set, source-file comments are written to the
|
||
output file. This allows the output of CPP to be
|
||
used as the input to a program, such as lint, that
|
||
expects commands embedded in specially-formatted
|
||
comments.
|
||
|
||
-Dname=value Define the name as if the programmer wrote
|
||
|
||
#define name value
|
||
|
||
at the start of the first file. If "=value" is not
|
||
given, a value of "1" will be used.
|
||
|
||
On non-unix systems, all alphabetic text will be
|
||
forced to upper-case.
|
||
|
||
-E Always return "success" to the operating system, even
|
||
if errors were detected. Note that some fatal
|
||
errors, such as a missing #include file, will
|
||
terminate CPP, returning "failure" even if the -E
|
||
option is given.
|
||
|
||
-Idirectory Add this directory to the list of directories
|
||
searched for #include "..." and #include <...>
|
||
commands. Note that there is no space between the
|
||
"-I" and the directory string. More than one -I
|
||
command is permitted. On non-Unix systems
|
||
"directory" is forced to upper-case.
|
||
|
||
-N CPP normally predefines some symbols defining the
|
||
target computer and operating system. If -N is
|
||
specified, no symbols will be predefined. If -N -N
|
||
is specified, the "always present" symbols, __LINE__,
|
||
__FILE__, and __DATE__ are not defined.
|
||
|
||
-P Do not output #line directives.
|
||
|
||
-Stext CPP normally assumes that the size of the target
|
||
computer's basic variable types is the same as the
|
||
size of these types of the host computer. (This can
|
||
be overridden when CPP is compiled, however.) The -S
|
||
option allows dynamic respecification of these
|
||
values. "text" is a string of numbers, separated by
|
||
commas, that specifies correct sizes. The sizes must
|
||
be specified in the exact order:
|
||
|
||
char short int long float double
|
||
|
||
If you specify the option as "-S*text", pointers to
|
||
these types will be specified. -S* takes one
|
||
additional argument for pointer to function (e.g.
|
||
int (*)())
|
||
|
||
For example, to specify sizes appropriate for a
|
||
PDP-11, you would write:
|
||
|
||
c s i l f d func
|
||
-S1,2,2,2,4,8,
|
||
-S*2,2,2,2,2,2,2
|
||
|
||
Note that all values must be specified.
|
||
|
||
-Uname Undefine the name as if
|
||
|
||
#undef name
|
||
|
||
were given. On non-Unix systems, "name" will be
|
||
forced to upper-case.
|
||
|
||
-Xnumber Enable debugging code. If no value is given, a value
|
||
of 1 will be used. (For maintenence of CPP only.)
|
||
|
||
|
||
PRE-DEFINED VARIABLES
|
||
When CPP begins processing, the following variables will have been
|
||
defined (unless the -N option is specified):
|
||
|
||
Target computer (as appropriate):
|
||
|
||
pdp11, vax, M68000 m68000 m68k
|
||
|
||
Target operating system (as appropriate):
|
||
|
||
rsx, rt11, vms, unix
|
||
|
||
Target compiler (as appropriate):
|
||
|
||
decus, vax11c
|
||
|
||
The implementor may add definitions to this list. The default
|
||
definitions match the definition of the host computer, operating
|
||
system, and C compiler.
|
||
|
||
The following are always available unless undefined (or -N was
|
||
specified twice):
|
||
|
||
__FILE__ The input (or #include) file being compiled (as a
|
||
quoted string).
|
||
|
||
__LINE__ The line number being compiled.
|
||
|
||
__DATE__ The date and time of compilation as a Unix ctime
|
||
quoted string (the trailing newline is removed).
|
||
Thus,
|
||
|
||
printf("Bug at line %s,", __LINE__);
|
||
printf(" source file %s", __FILE__);
|
||
printf(" compiled on %s", __DATE__);
|
||
|
||
|
||
DRAFT PROPOSED ANSI STANDARD CONSIDERATIONS
|
||
The current version of the Draft Proposed Standard explicitly states
|
||
that "readers are requested not to specify or claim conformance to
|
||
this draft." Readers and users of Decus CPP should not assume that
|
||
Decus CPP conforms to the standard, or that it will conform to the
|
||
actual C Language Standard.
|
||
|
||
When CPP is itself compiled, many features of the Draft Proposed
|
||
Standard that are incompatible with existing preprocessors may be
|
||
disabled. See the comments in CPP's source for details.
|
||
|
||
The latest version of the Draft Proposed Standard (as reflected in
|
||
Decus CPP) is dated November 12, 1984.
|
||
|
||
Comments are removed from the input text. The comment is replaced
|
||
by a single space character. The -C option preserves comments,
|
||
writing them to the output file.
|
||
|
||
The '$' character is considered to be a letter. This is a permitted
|
||
extension.
|
||
|
||
The following new features of C are processed by CPP:
|
||
|
||
#elif expression (#else #if)
|
||
'\xNNN' (Hexadecimal constant)
|
||
'\a' (Ascii BELL)
|
||
'\v' (Ascii Vertical Tab)
|
||
#if defined NAME 1 if defined, 0 if not
|
||
#if defined (NAME) 1 if defined, 0 if not
|
||
#if sizeof (basic type)
|
||
unary +
|
||
123U, 123LU Unsigned ints and longs.
|
||
12.3L Long double numbers
|
||
token#token Token concatenation
|
||
#include token Expands to filename
|
||
|
||
The Draft Proposed Standard has extended C, adding a constant string
|
||
concatenation operator, where
|
||
|
||
"foo" "bar"
|
||
|
||
is regarded as the single string "foobar". (This does not affect
|
||
CPP's processing but does permit a limited form of macro argument
|
||
substitution into strings as will be discussed.)
|
||
|
||
The Standard Committee plans to add token concatenation to #define
|
||
command lines. One suggested implementation is as follows: the
|
||
sequence "Token1#Token2" is treated as if the programmer wrote
|
||
"Token1Token2". This could be used as follows:
|
||
|
||
#line 123
|
||
#define ATLINE foo#__LINE__
|
||
|
||
ATLINE would be defined as foo123.
|
||
|
||
Note that "Token2" must either have the format of an identifier or
|
||
be a string of digits. Thus, the string
|
||
|
||
#define ATLINE foo#1x3
|
||
|
||
generates two tokens: "foo1" and "x3".
|
||
|
||
If the tokens T1 and T2 are concatenated into T3, this
|
||
implementation operates as follows:
|
||
|
||
1. Expand T1 if it is a macro.
|
||
2. Expand T2 if it is a macro.
|
||
3. Join the tokens, forming T3.
|
||
4. Expand T3 if it is a macro.
|
||
|
||
A macro formal parameter will be substituted into a string or
|
||
character constant if it is the only component of that constant:
|
||
|
||
#define VECSIZE 123
|
||
#define vprint(name, size) \
|
||
printf("name" "[" "size" "] = {\n")
|
||
... vprint(vector, VECSIZE);
|
||
|
||
expands (effectively) to
|
||
|
||
vprint("vector[123] = {\n");
|
||
|
||
Note that this will be useful if your C compiler supports the new
|
||
string concatenation operation noted above. As implemented here, if
|
||
you write
|
||
|
||
#define string(arg) "arg"
|
||
... string("foo") ...
|
||
|
||
This implementation generates "foo", rather than the strictly
|
||
correct ""foo"" (which will probably generate an error message).
|
||
This is, strictly speaking, an error in CPP and may be removed from
|
||
future releases.
|
||
|
||
ERROR MESSAGES
|
||
Many. CPP prints warning or error messages if you try to use
|
||
multiple-byte character constants (non-transportable) if you #undef
|
||
a symbol that was not defined, or if your program has potentially
|
||
nested comments.
|
||
|
||
AUTHOR
|
||
Martin Minow
|
||
|
||
BUGS
|
||
The #if expression processor uses signed integers only. I.e,
|
||
#if 0xFFFFu < 0 may be TRUE.
|
||
|
||
devtools.doc/rpcgen devtools.doc/rpcgen
|
||
|
||
NAME
|
||
rpcgen - an RPC protocol compiler
|
||
|
||
SYNOPSIS
|
||
rpcgen infile
|
||
rpcgen [-Dname[=value]] [-T] [-K secs] infile
|
||
rpcgen -c|-h|-l|-m|-t [-o outfile ] infile
|
||
rpcgen [-I] -s nettype [-o outfile] infile
|
||
rpcgen -n netid [-o outfile] infile
|
||
|
||
DESCRIPTION
|
||
rpcgen is a tool that generates C code to implement an RPC protocol.
|
||
The input to rpcgen is a language similar to C known as RPC Language
|
||
(Remote Procedure Call Language).
|
||
|
||
rpcgen is normally used as in the first synopsis where it takes an
|
||
input file and generates up to four output files. If the infile is
|
||
named proto.x, then rpcgen will generate a header file in proto.h,
|
||
XDR routines in proto_xdr.c, server-side stubs in proto_svc.c, and
|
||
client-side stubs in proto_clnt.c. With the -T option, it will also
|
||
generate the RPC dispatch table in proto_tbl.i. With the -Sc
|
||
option, it will also generate sample code which would illustrate how
|
||
to use the remote procedures on the client side. This code would be
|
||
created in proto_client.c. With the -Ss option, it will also
|
||
generate a sample server code which would illustrate how to write
|
||
the remote procedures. This code would be created in proto_server.c.
|
||
|
||
The server created can be started both by the port monitors (for
|
||
example, inetd or listen) or by itself. When it is started by a
|
||
port monitor, it creates servers only for the transport for which
|
||
the file descriptor 0 was passed. The name of the transport must be
|
||
specified by setting up the environmental variable PM_TRANSPORT.
|
||
When the server generated by rpcgen is executed, it creates server
|
||
handles for all the transports specified in NETPATH environment
|
||
variable, or if it is unset, it creates server handles for all the
|
||
visible transports from /etc/netconfig file. Note: the transports
|
||
are chosen at run time and not at compile time. When the server is
|
||
self-started, it backgrounds itself by default. A special define
|
||
symbol RPC_SVC_FG can be used to run the server process in
|
||
foreground.
|
||
|
||
The second synopsis provides special features which allow for the
|
||
creation of more sophisticated RPC servers. These features include
|
||
support for user provided #defines and RPC dispatch tables. The
|
||
entries in the RPC dispatch table contain:
|
||
+ pointers to the service routine corresponding to that
|
||
procedure,
|
||
+ a pointer to the input and output arguments
|
||
+ the size of these routines
|
||
A server can use the dispatch table to check authorization and then
|
||
to execute the service routine; a client library may use it to deal
|
||
with the details of storage management and XDR data conversion.
|
||
|
||
The other three synopses shown above are used when one does not want
|
||
to generate all the output files, but only a particular one. Some
|
||
examples of their usage is described in the EXAMPLE section below.
|
||
When rpcgen is executed with the -s option, it creates servers for
|
||
that particular class of transports. When executed with the -n
|
||
option, it creates a server for the transport specified by netid.
|
||
If infile is not specified, rpcgen accepts the standard input.
|
||
|
||
The C preprocessor, ccp, is run on the input file before it is
|
||
actually interpreted by rpcgen. For each type of output file,
|
||
rpcgen defines a special preprocessor symbol for use by the rpcgen
|
||
programmer:
|
||
|
||
RPC_HDR defined when compiling into header files
|
||
RPC_XDR defined when compiling into XDR routines
|
||
RPC_SVC defined when compiling into server-side stubs
|
||
RPC_CLNT defined when compiling into client-side stubs
|
||
RPC_TBL defined when compiling into RPC dispatch tables
|
||
|
||
Any line beginning with `%' is passed directly into the output file,
|
||
uninterpreted by rpcgen.
|
||
|
||
For every data type referred to in infile, rpcgen assumes that there
|
||
exists a routine with the string xdr_ prepended to the name of the
|
||
data type. If this routine does not exist in the RPC/XDR library,
|
||
it must be provided. Providing an undefined data type allows
|
||
customization of XDR routines.
|
||
|
||
The following options are available:
|
||
|
||
-a Generate all the files including sample code for client and
|
||
server side.
|
||
|
||
-b This generates code for the SunOS4.1 style of rpc. It is for
|
||
backward compatibilty. This is the default.
|
||
|
||
-5 This generates code for the SysVr4 style of rpc. It is used by
|
||
the Transport Independent RPC that is in Svr4 systems. By
|
||
default rpcgen generates code for SunOS4.1 stype of rpc.
|
||
|
||
-c Compile into XDR routines.
|
||
|
||
-C Generate code in ANSI C. This option also generates code that
|
||
could be compiled with the C++ compiler. This is the default.
|
||
|
||
-k Generate code in K&R C. The default is ANSI C.
|
||
|
||
-Dname[=value]
|
||
Define a symbol name. Equivalent to the #define directive in the
|
||
source. If no value is given, value is defined as 1. This
|
||
option may be specified more than once.
|
||
|
||
-h Compile into C data-definitions (a header file). -T option can
|
||
be used in conjunction to produce a header file which supports
|
||
RPC dispatch tables.
|
||
|
||
-I Generate a service that can be started from inetd. The default
|
||
is to generate a static service that handles transports
|
||
selected with -s. Using -I allows starting a service by either
|
||
method.
|
||
|
||
-K secs
|
||
By default, services created using rpcgen wait 120 seconds
|
||
after servicing a request before exiting. That interval can be
|
||
changed using the -K flag. To create a server that exits
|
||
immediately upon servicing a request, -K 0 can be used. To
|
||
create a server that never exits, the appropriate argument is
|
||
-K -1.
|
||
|
||
When monitoring for a server, some portmonitors, like
|
||
listen(1M), always spawn a new process in response to a service
|
||
request. If it is known that a server will be used with such a
|
||
monitor, the server should exit immediately on completion. For
|
||
such servers, rpcgen should be used with -K -1.
|
||
|
||
-l Compile into client-side stubs.
|
||
|
||
-m Compile into server-side stubs, but do not generate a main
|
||
routine. This option is useful for doing callback-routines and
|
||
for users who need to write their own main routine to do
|
||
initialization.
|
||
|
||
-n netid
|
||
Compile into server-side stubs for the transport specified by
|
||
netid. There should be an entry for netid in the netconfig
|
||
database. This option may be specified more than once, so as
|
||
to compile a server that serves multiple transports.
|
||
|
||
-N Use the newstyle of rpcgen. This allows procedures to have
|
||
multiple arguments. It also uses the style of parameter passing
|
||
that closely resembles C. So, when passing an argument to a
|
||
remote procedure you do not have to pass a pointer to the
|
||
argument but the argument itself. This behaviour is different
|
||
from the oldstyle of rpcgen generated code. The newstyle is not
|
||
the default case because of backward compatibility.
|
||
|
||
-o outfile
|
||
Specify the name of the output file. If none is specified,
|
||
standard output is used (-c, -h, -l, -m, -n, -s, -sSc, -sSs and
|
||
-t modes only).
|
||
|
||
-s nettype
|
||
Compile into server-side stubs for all the transports belonging
|
||
to the class nettype. The supported classes are netpath,
|
||
visible, circuit_n, circuit_v, datagram_n, datagram_v, tcp, and
|
||
udp [see rpc(3N) for the meanings associated with these
|
||
classes]. This option may be specified more than once. Note:
|
||
the transports are chosen at run time and not at compile time.
|
||
|
||
-Sc Generate sample code to show the use of remote procedure and
|
||
how to bind to the server before calling the client side stubs
|
||
generated by rpcgen.
|
||
|
||
-Ss Generate skeleton code for the remote procedures on the server
|
||
side. You would need to fill in the actual code for the remote
|
||
procedures.
|
||
|
||
-t Compile into RPC dispatch table.
|
||
|
||
-T Generate the code to support RPC dispatch tables.
|
||
|
||
The options -c, -h, -l, -m, -s and -t are used exclusively to generate
|
||
a particular type of file, while the options -D and -T are global and
|
||
can be used with the other options.
|
||
|
||
NOTES
|
||
The RPC Language does not support nesting of structures. As a work-
|
||
around, structures can be declared at the top-level, and their name
|
||
used inside other structures in order to achieve the same effect.
|
||
|
||
Name clashes can occur when using program definitions, since the
|
||
apparent scoping does not really apply. Most of these can be
|
||
avoided by giving unique names for programs, versions, procedures
|
||
and types.
|
||
|
||
The server code generated with -n option refers to the transport
|
||
indicated by netid and hence is very site specific.
|
||
|
||
EXAMPLE
|
||
The following example:
|
||
|
||
$ rpcgen -T prot.x
|
||
|
||
generates the five files: prot.h, prot_clnt.c, prot_svc.c,
|
||
prot_xdr.c and prot_tbl.i.
|
||
|
||
The following example sends the C data-definitions (header file) to
|
||
the standard output.
|
||
|
||
$ rpcgen -h prot.x
|
||
|
||
To send the test version of the -DTEST, server side stubs for all
|
||
the transport belonging to the class datagram_n to standard output,
|
||
use:
|
||
|
||
$ rpcgen -s datagram_n -DTEST prot.x
|
||
|
||
To create the server side stubs for the transport indicated by netid
|
||
tcp, use:
|
||
|
||
$ rpcgen -n tcp -o prot_svc.c prot.x
|
||
|
||
SEE ALSO
|
||
devtools.doc/cpp
|
||
|
||
utilities/rcsrev utilities/rcsrev
|
||
|
||
NAME
|
||
RCSRev - Convert a RCS ID into #?_rev.? Files
|
||
|
||
VERSION
|
||
$Id: rcsrev.c,v 4.1 1994/09/30 00:50:36 jraja Exp $
|
||
|
||
TEMPLATE
|
||
RCSREV NAME/A SOURCE/A POSTFIX ASM=ASMINCLUDE/S DATE/K
|
||
|
||
FUNCTION
|
||
RCSRev is intended to generate a BumbRev-compatible revision
|
||
include files from RCS ID.
|
||
|
||
The arguments are used as follows:
|
||
|
||
NAME/A - name for program (generate file NAME_rev.h).
|
||
SOURCE/A - source file name
|
||
PREFIX/K - optional prefix to program name (eg. AmiTCP/IP_)
|
||
POSTFIX/K - optional string postfixed to revision string
|
||
ASMINCLUDE/S - create also an assembler include file (generate file
|
||
NAME_rev.i).
|
||
|
||
DATE/K - specify the date format used. The date formats
|
||
available are as follows:
|
||
CURRENT - use current date (default)
|
||
RCS - use date from RCS ID
|
||
SASC - use preprocessor macro __AMIGADATE__
|
||
DICE - use preprocessor macro __COMMODORE_DATE__
|
||
|
||
NOTES
|
||
The macro DATE is not defined in the revision file with SASC or
|
||
COMMODORE date formats. The macro VSTRING is not defined in
|
||
revision file with the SASC format. (See sources and macro
|
||
FIXED_AMIGADATE).
|
||
|
||
The SASC or DICE formats can not be used with the ASMINCLUDE option.
|
||
|
||
BUGS
|
||
RCSRev doesn't recognize other RCS ident string except Id.
|
||
|
||
Maximum allowed line length is fixed.
|
||
|
||
AUTHOR
|
||
ppessi <Pekka.Pessi@hut.fi>
|
||
|
||
COPYRIGHT
|
||
Copyright <20> 1994 AmiTCP/IP Group,
|
||
Network Solutions Development Inc., Finland.
|
||
|
||
|