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 � 1994 AmiTCP/IP Group,
|
|
Network Solutions Development Inc., Finland.
|
|
|
|
|