summaryrefslogtreecommitdiffstats
path: root/lib
diff options
context:
space:
mode:
Diffstat (limited to 'lib')
-rw-r--r--lib/libalias/alias_nbt.c2
-rw-r--r--lib/libalias/alias_proxy.c2
-rw-r--r--lib/libc/db/btree/bt_utils.c2
-rw-r--r--lib/libc/gen/nlist.c4
-rw-r--r--lib/libc/i386/string/swab.S2
-rw-r--r--lib/libc/ia64/gen/__moddi3.S2
-rw-r--r--lib/libc/ia64/gen/__umoddi3.S2
-rw-r--r--lib/libc/locale/wcstoimax.c2
-rw-r--r--lib/libc/net/inet_neta.c2
-rw-r--r--lib/libc/net/ns_name.c2
-rw-r--r--lib/libc/rpc/PSD.doc/rpc.prog.ms490
-rw-r--r--lib/libc/rpc/PSD.doc/xdr.nts.ms522
-rw-r--r--lib/libc/rpc/rpc_svc_calls.32
-rw-r--r--lib/libc/stdlib/strtoimax.c2
-rw-r--r--lib/libc/sys/socket.22
-rw-r--r--lib/libdisk/libdisk.h2
-rw-r--r--lib/libedit/chared.h2
-rw-r--r--lib/libedit/common.c2
-rw-r--r--lib/libedit/emacs.c2
-rw-r--r--lib/libedit/vi.c2
-rw-r--r--lib/libipsec/ipsec_set_policy.32
-rw-r--r--lib/libnetgraph/sock.c2
-rw-r--r--lib/libvgl/vgl.34
-rw-r--r--lib/msun/bsdsrc/b_log.c2
-rw-r--r--lib/msun/src/k_tan.c2
25 files changed, 531 insertions, 531 deletions
diff --git a/lib/libalias/alias_nbt.c b/lib/libalias/alias_nbt.c
index 4bc41bc..508bf51 100644
--- a/lib/libalias/alias_nbt.c
+++ b/lib/libalias/alias_nbt.c
@@ -239,7 +239,7 @@ int AliasHandleUdpNbt(
#ifdef DEBUG
printf("%s:%d-->", inet_ntoa(ndh->source_ip), ntohs(ndh->source_port) );
#endif
- /* Doing a IP address and Port number Translation */
+ /* Doing an IP address and Port number Translation */
if ( uh->uh_sum != 0 ) {
int acc;
u_short *sptr;
diff --git a/lib/libalias/alias_proxy.c b/lib/libalias/alias_proxy.c
index 6c95ea9..b9a9798 100644
--- a/lib/libalias/alias_proxy.c
+++ b/lib/libalias/alias_proxy.c
@@ -37,7 +37,7 @@ __FBSDID("$FreeBSD$");
modified. In certain cases, it is necessary to somehow encode
the original address/port info into the packet. Two methods are
presently supported: addition of a [DEST addr port] string at the
- beginning a of tcp stream, or inclusion of an optional field
+ beginning of a tcp stream, or inclusion of an optional field
in the IP header.
There is one public API function:
diff --git a/lib/libc/db/btree/bt_utils.c b/lib/libc/db/btree/bt_utils.c
index 8bbfade..0f8ef34 100644
--- a/lib/libc/db/btree/bt_utils.c
+++ b/lib/libc/db/btree/bt_utils.c
@@ -224,7 +224,7 @@ __bt_defcmp(a, b)
/*
* XXX
* If a size_t doesn't fit in an int, this routine can lose.
- * What we need is a integral type which is guaranteed to be
+ * What we need is an integral type which is guaranteed to be
* larger than a size_t, and there is no such thing.
*/
len = MIN(a->size, b->size);
diff --git a/lib/libc/gen/nlist.c b/lib/libc/gen/nlist.c
index 8464ac3..9e6d52f 100644
--- a/lib/libc/gen/nlist.c
+++ b/lib/libc/gen/nlist.c
@@ -208,8 +208,8 @@ static void elf_sym_to_nlist(struct nlist *, Elf_Sym *, Elf_Shdr *, int);
* __elf_is_okay__ - Determine if ehdr really
* is ELF and valid for the target platform.
*
- * WARNING: This is NOT a ELF ABI function and
- * as such it's use should be restricted.
+ * WARNING: This is NOT an ELF ABI function and
+ * as such its use should be restricted.
*/
int
__elf_is_okay__(ehdr)
diff --git a/lib/libc/i386/string/swab.S b/lib/libc/i386/string/swab.S
index 11967f6..80b2f3c 100644
--- a/lib/libc/i386/string/swab.S
+++ b/lib/libc/i386/string/swab.S
@@ -38,7 +38,7 @@ __FBSDID("$FreeBSD$");
*
* On the i486, this code is negligibly faster than the code generated
* by gcc at about half the size. If my i386 databook is correct, it
- * should be considerably faster than the gcc code on a i386.
+ * should be considerably faster than the gcc code on an i386.
*
* Written by:
* J.T. Conklin (jtc@wimsey.com), Winning Strategies, Inc.
diff --git a/lib/libc/ia64/gen/__moddi3.S b/lib/libc/ia64/gen/__moddi3.S
index bc2cc61..897066c 100644
--- a/lib/libc/ia64/gen/__moddi3.S
+++ b/lib/libc/ia64/gen/__moddi3.S
@@ -55,7 +55,7 @@ __moddi3:
// floating-point registers used: f6, f7, f8, f9, f10, f11, f12
// predicate registers used: p6
- setf.sig f12=r32 // holds a in integer form
+ setf.sig f12=r32 // holds an in integer form
setf.sig f7=r33
nop.b 0
} { .mlx
diff --git a/lib/libc/ia64/gen/__umoddi3.S b/lib/libc/ia64/gen/__umoddi3.S
index 84991b0..05a0304 100644
--- a/lib/libc/ia64/gen/__umoddi3.S
+++ b/lib/libc/ia64/gen/__umoddi3.S
@@ -54,7 +54,7 @@ __umoddi3:
// floating-point registers used: f6, f7, f8, f9, f10, f11, f12
// predicate registers used: p6
- setf.sig f12=r32 // holds a in integer form
+ setf.sig f12=r32 // holds an in integer form
setf.sig f7=r33
nop.b 0;;
} { .mfi
diff --git a/lib/libc/locale/wcstoimax.c b/lib/libc/locale/wcstoimax.c
index f145f54..0dadd5a 100644
--- a/lib/libc/locale/wcstoimax.c
+++ b/lib/libc/locale/wcstoimax.c
@@ -47,7 +47,7 @@ __FBSDID("$FreeBSD$");
#include <wctype.h>
/*
- * Convert a wide character string to a intmax_t integer.
+ * Convert a wide character string to an intmax_t integer.
*/
intmax_t
wcstoimax(const wchar_t * __restrict nptr, wchar_t ** __restrict endptr,
diff --git a/lib/libc/net/inet_neta.c b/lib/libc/net/inet_neta.c
index f7c7ded..c918962 100644
--- a/lib/libc/net/inet_neta.c
+++ b/lib/libc/net/inet_neta.c
@@ -39,7 +39,7 @@ __FBSDID("$FreeBSD$");
/*
* char *
* inet_neta(src, dst, size)
- * format a in_addr_t network number into presentation format.
+ * format an in_addr_t network number into presentation format.
* return:
* pointer to dst, or NULL if an error occurred (check errno).
* note:
diff --git a/lib/libc/net/ns_name.c b/lib/libc/net/ns_name.c
index 0183fdf..ae238b0 100644
--- a/lib/libc/net/ns_name.c
+++ b/lib/libc/net/ns_name.c
@@ -122,7 +122,7 @@ ns_name_ntop(const u_char *src, char *dst, size_t dstsiz) {
/*
* ns_name_pton(src, dst, dstsiz)
- * Convert a ascii string into an encoded domain name as per RFC1035.
+ * Convert an ascii string into an encoded domain name as per RFC1035.
* return:
* -1 if it fails
* 1 if string was fully qualified
diff --git a/lib/libc/rpc/PSD.doc/rpc.prog.ms b/lib/libc/rpc/PSD.doc/rpc.prog.ms
index 290f99b..8b79130 100644
--- a/lib/libc/rpc/PSD.doc/rpc.prog.ms
+++ b/lib/libc/rpc/PSD.doc/rpc.prog.ms
@@ -23,9 +23,9 @@ This document assumes a working knowledge of network theory. It is
intended for programmers who wish to write network applications using
remote procedure calls (explained below), and who want to understand
the RPC mechanisms usually hidden by the
-.I rpcgen(1)
+.I rpcgen(1)
protocol compiler.
-.I rpcgen
+.I rpcgen
is described in detail in the previous chapter, the
.I "\fBrpcgen\fP \fIProgramming Guide\fP".
.SH
@@ -41,7 +41,7 @@ The
.I "Generating XDR Routines"
section of that chapter contains the complete source for a working RPC
service\(ema remote directory listing service which uses
-.I rpcgen
+.I rpcgen
to generate XDR routines as well as client and server stubs.
.LP
.LP
@@ -64,36 +64,36 @@ The RPC interface can be seen as being divided into three layers.\**
.FS
For a complete specification of the routines in the remote procedure
call Library, see the
-.I rpc(3N)
+.I rpc(3N)
manual page.
.FE
.LP
.I "The Highest Layer:"
.IX RPC "The Highest Layer"
-The highest layer is totally transparent to the operating system,
-machine and network upon which is is run. It's probably best to
+The highest layer is totally transparent to the operating system,
+machine and network upon which is is run. It's probably best to
think of this level as a way of
.I using
RPC, rather than as
-a \fIpart of\fP RPC proper. Programmers who write RPC routines
-should (almost) always make this layer available to others by way
+a \fIpart of\fP RPC proper. Programmers who write RPC routines
+should (almost) always make this layer available to others by way
of a simple C front end that entirely hides the networking.
-.LP
+.LP
To illustrate, at this level a program can simply make a call to
.I rnusers (),
a C routine which returns the number of users on a remote machine.
-The user is not explicitly aware of using RPC \(em they simply
+The user is not explicitly aware of using RPC \(em they simply
call a procedure, just as they would call
.I malloc() .
.LP
.I "The Middle Layer:"
.IX RPC "The Middle Layer"
The middle layer is really \*QRPC proper.\*U Here, the user doesn't
-need to consider details about sockets, the UNIX system, or other low-level
+need to consider details about sockets, the UNIX system, or other low-level
implementation mechanisms. They simply make remote procedure calls
-to routines on other machines. The selling point here is simplicity.
+to routines on other machines. The selling point here is simplicity.
It's this layer that allows RPC to pass the \*Qhello world\*U test \(em
-simple things should be simple. The middle-layer routines are used
+simple things should be simple. The middle-layer routines are used
for most applications.
.LP
RPC calls are made with the system routines
@@ -102,27 +102,27 @@ RPC calls are made with the system routines
and
.I svc_run ().
The first two of these are the most fundamental:
-.I registerrpc()
+.I registerrpc()
obtains a unique system-wide procedure-identification number, and
-.I callrpc()
-actually executes a remote procedure call. At the middle level, a
-call to
+.I callrpc()
+actually executes a remote procedure call. At the middle level, a
+call to
.I rnusers()
is implemented by way of these two routines.
.LP
-The middle layer is unfortunately rarely used in serious programming
-due to its inflexibility (simplicity). It does not allow timeout
+The middle layer is unfortunately rarely used in serious programming
+due to its inflexibility (simplicity). It does not allow timeout
specifications or the choice of transport. It allows no UNIX
process control or flexibility in case of errors. It doesn't support
-multiple kinds of call authentication. The programmer rarely needs
+multiple kinds of call authentication. The programmer rarely needs
all these kinds of control, but one or two of them is often necessary.
.LP
.I "The Lowest Layer:"
.IX RPC "The Lowest Layer"
-The lowest layer does allow these details to be controlled by the
-programmer, and for that reason it is often necessary. Programs
+The lowest layer does allow these details to be controlled by the
+programmer, and for that reason it is often necessary. Programs
written at this level are also most efficient, but this is rarely a
-real issue \(em since RPC clients and servers rarely generate
+real issue \(em since RPC clients and servers rarely generate
heavy network loads.
.LP
Although this document only discusses the interface to C,
@@ -203,7 +203,7 @@ main(argc, argv)
.DE
.KE
RPC library routines such as
-.I rnusers()
+.I rnusers()
are in the RPC services library
.I librpcsvc.a
Thus, the program above should be compiled with
@@ -212,17 +212,17 @@ Thus, the program above should be compiled with
% cc \fIprogram.c -lrpcsvc\fP
.DE
.I rnusers (),
-like the other RPC library routines, is documented in section 3R
+like the other RPC library routines, is documented in section 3R
of the
.I "System Interface Manual for the Sun Workstation" ,
-the same section which documents the standard Sun RPC services.
+the same section which documents the standard Sun RPC services.
.IX "RPC Services"
-See the
-.I intro(3R)
-manual page for an explanation of the documentation strategy
+See the
+.I intro(3R)
+manual page for an explanation of the documentation strategy
for these services and their RPC protocols.
.LP
-Here are some of the RPC service library routines available to the
+Here are some of the RPC service library routines available to the
C programmer:
.LP
\fBTable 3-3\fI RPC Service Library Routines\fR
@@ -251,18 +251,18 @@ and
They do, however,
have RPC program numbers so they can be invoked with
.I callrpc()
-which will be discussed in the next section. Most of them also
-have compilable
-.I rpcgen(1)
+which will be discussed in the next section. Most of them also
+have compilable
+.I rpcgen(1)
protocol description files. (The
.I rpcgen
protocol compiler radically simplifies the process of developing
-network applications.
+network applications.
See the \fBrpcgen\fI Programming Guide\fR
-for detailed information about
-.I rpcgen
-and
-.I rpcgen
+for detailed information about
+.I rpcgen
+and
+.I rpcgen
protocol description files).
.KS
.NH 2
@@ -270,7 +270,7 @@ protocol description files).
.IX "intermediate layer of RPC"
.IX "RPC" "intermediate layer"
.LP
-The simplest interface, which explicitly makes RPC calls, uses the
+The simplest interface, which explicitly makes RPC calls, uses the
functions
.I callrpc()
and
@@ -305,63 +305,63 @@ main(argc, argv)
}
.DE
.KE
-Each RPC procedure is uniquely defined by a program number,
-version number, and procedure number. The program number
-specifies a group of related remote procedures, each of
-which has a different procedure number. Each program also
-has a version number, so when a minor change is made to a
-remote service (adding a new procedure, for example), a new
-program number doesn't have to be assigned. When you want
-to call a procedure to find the number of remote users, you
+Each RPC procedure is uniquely defined by a program number,
+version number, and procedure number. The program number
+specifies a group of related remote procedures, each of
+which has a different procedure number. Each program also
+has a version number, so when a minor change is made to a
+remote service (adding a new procedure, for example), a new
+program number doesn't have to be assigned. When you want
+to call a procedure to find the number of remote users, you
look up the appropriate program, version and procedure numbers
-in a manual, just as you look up the name of a memory allocator
+in a manual, just as you look up the name of a memory allocator
when you want to allocate memory.
.LP
-The simplest way of making remote procedure calls is with the the RPC
+The simplest way of making remote procedure calls is with the the RPC
library routine
.I callrpc()
-It has eight parameters. The first is the name of the remote server
-machine. The next three parameters are the program, version, and procedure
+It has eight parameters. The first is the name of the remote server
+machine. The next three parameters are the program, version, and procedure
numbers\(emtogether they identify the procedure to be called.
The fifth and sixth parameters are an XDR filter and an argument to
-be encoded and passed to the remote procedure.
-The final two parameters are a filter for decoding the results
-returned by the remote procedure and a pointer to the place where
+be encoded and passed to the remote procedure.
+The final two parameters are a filter for decoding the results
+returned by the remote procedure and a pointer to the place where
the procedure's results are to be stored. Multiple arguments and
-results are handled by embedding them in structures. If
-.I callrpc()
-completes successfully, it returns zero; else it returns a nonzero
+results are handled by embedding them in structures. If
+.I callrpc()
+completes successfully, it returns zero; else it returns a nonzero
value. The return codes (of type
.IX "enum clnt_stat (in RPC programming)" "" "\fIenum clnt_stat\fP (in RPC programming)"
-cast into an integer) are found in
+cast into an integer) are found in
.I <rpc/clnt.h> .
.LP
Since data types may be represented differently on different machines,
-.I callrpc()
+.I callrpc()
needs both the type of the RPC argument, as well as
a pointer to the argument itself (and similarly for the result). For
.I RUSERSPROC_NUM ,
the return value is an
.I "unsigned long"
so
-.I callrpc()
+.I callrpc()
has
-.I xdr_u_long()
+.I xdr_u_long()
as its first return parameter, which says
that the result is of type
.I "unsigned long"
and
-.I &nusers
+.I &nusers
as its second return parameter,
which is a pointer to where the long result will be placed. Since
-.I RUSERSPROC_NUM
+.I RUSERSPROC_NUM
takes no argument, the argument parameter of
-.I callrpc()
+.I callrpc()
is
.I xdr_void ().
.LP
After trying several times to deliver a message, if
-.I callrpc()
+.I callrpc()
gets no answer, it returns with an error code.
The delivery mechanism is UDP,
which stands for User Datagram Protocol.
@@ -429,15 +429,15 @@ given RPC procedure number. The first three parameters,
.I RUSERPROG ,
.I RUSERSVERS ,
and
-.I RUSERSPROC_NUM
+.I RUSERSPROC_NUM
are the program, version, and procedure numbers
of the remote procedure to be registered;
-.I nuser()
+.I nuser()
is the name of the local procedure that implements the remote
procedure; and
-.I xdr_void()
+.I xdr_void()
and
-.I xdr_u_long()
+.I xdr_u_long()
are the XDR filters for the remote procedure's arguments and
results, respectively. (Multiple arguments or multiple results
are passed as structures).
@@ -455,7 +455,7 @@ arguments and results less than 8K bytes in length.
After registering the local procedure, the server program's
main procedure calls
.I svc_run (),
-the RPC library's remote procedure dispatcher. It is this
+the RPC library's remote procedure dispatcher. It is this
function that calls the remote procedures in response to RPC
call messages. Note that the dispatcher takes care of decoding
remote procedure arguments and encoding results, using the XDR
@@ -465,8 +465,8 @@ filters specified when the remote procedure was registered.
.IX "program number assignment"
.IX "assigning program numbers"
.LP
-Program numbers are assigned in groups of
-.I 0x20000000
+Program numbers are assigned in groups of
+.I 0x20000000
according to the following chart:
.DS
.ft CW
@@ -491,7 +491,7 @@ applications that generate program numbers dynamically. The
final groups are reserved for future use, and should not be
used.
.LP
-To register a protocol specification, send a request by network
+To register a protocol specification, send a request by network
mail to
.I rpc@sun
or write to:
@@ -501,20 +501,20 @@ Sun Microsystems
2550 Garcia Ave.
Mountain View, CA 94043
.DE
-Please include a compilable
-.I rpcgen
+Please include a compilable
+.I rpcgen
\*Q.x\*U file describing your protocol.
You will be given a unique program number in return.
.IX RPC administration
.IX administration "of RPC"
.LP
-The RPC program numbers and protocol specifications
+The RPC program numbers and protocol specifications
of standard Sun RPC services can be
-found in the include files in
+found in the include files in
.I "/usr/include/rpcsvc" .
-These services, however, constitute only a small subset
-of those which have been registered. The complete list of
-registered programs, as of the time when this manual was
+These services, however, constitute only a small subset
+of those which have been registered. The complete list of
+registered programs, as of the time when this manual was
printed, is:
.LP
\fBTable 3-2\fI RPC Registered Programs\fR
@@ -527,53 +527,53 @@ _
.TH
.sp .5
100000&PMAPPROG&portmapper
-100001&RSTATPROG&remote stats
-100002&RUSERSPROG&remote users
-100003&NFSPROG&nfs
-100004&YPPROG&Yellow Pages
-100005&MOUNTPROG&mount daemon
-100006&DBXPROG&remote dbx
-100007&YPBINDPROG&yp binder
-100008&WALLPROG&shutdown msg
-100009&YPPASSWDPROG&yppasswd server
-100010&ETHERSTATPROG&ether stats
-100011&RQUOTAPROG&disk quotas
-100012&SPRAYPROG&spray packets
-100013&IBM3270PROG&3270 mapper
-100014&IBMRJEPROG&RJE mapper
-100015&SELNSVCPROG&selection service
-100016&RDATABASEPROG&remote database access
-100017&REXECPROG&remote execution
-100018&ALICEPROG&Alice Office Automation
-100019&SCHEDPROG&scheduling service
-100020&LOCKPROG&local lock manager
-100021&NETLOCKPROG&network lock manager
-100022&X25PROG&x.25 inr protocol
-100023&STATMON1PROG&status monitor 1
-100024&STATMON2PROG&status monitor 2
-100025&SELNLIBPROG&selection library
-100026&BOOTPARAMPROG&boot parameters service
-100027&MAZEPROG&mazewars game
-100028&YPUPDATEPROG&yp update
-100029&KEYSERVEPROG&key server
-100030&SECURECMDPROG&secure login
-100031&NETFWDIPROG&nfs net forwarder init
-100032&NETFWDTPROG&nfs net forwarder trans
-100033&SUNLINKMAP_PROG&sunlink MAP
-100034&NETMONPROG&network monitor
-100035&DBASEPROG&lightweight database
-100036&PWDAUTHPROG&password authorization
-100037&TFSPROG&translucent file svc
-100038&NSEPROG&nse server
-100039&NSE_ACTIVATE_PROG&nse activate daemon
+100001&RSTATPROG&remote stats
+100002&RUSERSPROG&remote users
+100003&NFSPROG&nfs
+100004&YPPROG&Yellow Pages
+100005&MOUNTPROG&mount daemon
+100006&DBXPROG&remote dbx
+100007&YPBINDPROG&yp binder
+100008&WALLPROG&shutdown msg
+100009&YPPASSWDPROG&yppasswd server
+100010&ETHERSTATPROG&ether stats
+100011&RQUOTAPROG&disk quotas
+100012&SPRAYPROG&spray packets
+100013&IBM3270PROG&3270 mapper
+100014&IBMRJEPROG&RJE mapper
+100015&SELNSVCPROG&selection service
+100016&RDATABASEPROG&remote database access
+100017&REXECPROG&remote execution
+100018&ALICEPROG&Alice Office Automation
+100019&SCHEDPROG&scheduling service
+100020&LOCKPROG&local lock manager
+100021&NETLOCKPROG&network lock manager
+100022&X25PROG&x.25 inr protocol
+100023&STATMON1PROG&status monitor 1
+100024&STATMON2PROG&status monitor 2
+100025&SELNLIBPROG&selection library
+100026&BOOTPARAMPROG&boot parameters service
+100027&MAZEPROG&mazewars game
+100028&YPUPDATEPROG&yp update
+100029&KEYSERVEPROG&key server
+100030&SECURECMDPROG&secure login
+100031&NETFWDIPROG&nfs net forwarder init
+100032&NETFWDTPROG&nfs net forwarder trans
+100033&SUNLINKMAP_PROG&sunlink MAP
+100034&NETMONPROG&network monitor
+100035&DBASEPROG&lightweight database
+100036&PWDAUTHPROG&password authorization
+100037&TFSPROG&translucent file svc
+100038&NSEPROG&nse server
+100039&NSE_ACTIVATE_PROG&nse activate daemon
.sp .2i
-150001&PCNFSDPROG&pc passwd authorization
+150001&PCNFSDPROG&pc passwd authorization
.sp .2i
-200000&PYRAMIDLOCKINGPROG&Pyramid-locking
-200001&PYRAMIDSYS5&Pyramid-sys5
-200002&CADDS_IMAGE&CV cadds_image
+200000&PYRAMIDLOCKINGPROG&Pyramid-locking
+200001&PYRAMIDSYS5&Pyramid-sys5
+200002&CADDS_IMAGE&CV cadds_image
.sp .2i
-300001&ADT_RFLOCKPROG&ADT file locking
+300001&ADT_RFLOCKPROG&ADT file locking
.TE
.NH 2
\&Passing Arbitrary Data Types
@@ -593,11 +593,11 @@ to XDR format is called
and the reverse process is called
.I deserializing .
The type field parameters of
-.I callrpc()
+.I callrpc()
and
-.I registerrpc()
+.I registerrpc()
can be a built-in procedure like
-.I xdr_u_long()
+.I xdr_u_long()
in the previous example, or a user supplied one.
XDR has these built-in type routines:
.IX RPC "built-in routines"
@@ -609,14 +609,14 @@ xdr_short() xdr_u_short() xdr_wrapstring()
xdr_char() xdr_u_char()
.DE
Note that the routine
-.I xdr_string()
-exists, but cannot be used with
-.I callrpc()
+.I xdr_string()
+exists, but cannot be used with
+.I callrpc()
and
.I registerrpc (),
which only pass two parameters to their XDR routines.
-.I xdr_wrapstring()
-has only two parameters, and is thus OK. It calls
+.I xdr_wrapstring()
+has only two parameters, and is thus OK. It calls
.I xdr_string ().
.LP
As an example of a user-defined type routine,
@@ -629,7 +629,7 @@ struct simple {
} simple;
.DE
then you would call
-.I callrpc()
+.I callrpc()
as
.DS
.ft CW
@@ -637,7 +637,7 @@ callrpc(hostname, PROGNUM, VERSNUM, PROCNUM,
xdr_simple, &simple ...);
.DE
where
-.I xdr_simple()
+.I xdr_simple()
is written as:
.ie t .DS
.el .DS L
@@ -656,11 +656,11 @@ xdr_simple(xdrsp, simplep)
}
.DE
.LP
-An XDR routine returns nonzero (true in the sense of C) if it
+An XDR routine returns nonzero (true in the sense of C) if it
completes successfully, and zero otherwise.
A complete description of XDR is in the
-.I "XDR Protocol Specification"
-section of this manual, only few implementation examples are
+.I "XDR Protocol Specification"
+section of this manual, only few implementation examples are
given here.
.LP
In addition to the built-in primitives,
@@ -687,7 +687,7 @@ callrpc(hostname, PROGNUM, VERSNUM, PROCNUM,
xdr_varintarr, &arr...);
.DE
with
-.I xdr_varintarr()
+.I xdr_varintarr()
defined as:
.ie t .DS
.el .DS L
@@ -696,7 +696,7 @@ xdr_varintarr(xdrsp, arrp)
XDR *xdrsp;
struct varintarr *arrp;
{
- return (xdr_array(xdrsp, &arrp->data, &arrp->arrlnth,
+ return (xdr_array(xdrsp, &arrp->data, &arrp->arrlnth,
MAXLEN, sizeof(int), xdr_int));
}
.DE
@@ -735,22 +735,22 @@ That is the reason for the XDR routine
which is like
.I xdr_array()
except that it packs characters;
-.I xdr_bytes()
+.I xdr_bytes()
has four parameters, similar to the first four parameters of
.I xdr_array ().
For null-terminated strings, there is also the
.I xdr_string()
routine, which is the same as
-.I xdr_bytes()
+.I xdr_bytes()
without the length parameter.
On serializing it gets the string length from
.I strlen (),
and on deserializing it creates a null-terminated string.
.LP
Here is a final example that calls the previously written
-.I xdr_simple()
+.I xdr_simple()
as well as the built-in functions
-.I xdr_string()
+.I xdr_string()
and
.I xdr_reference (),
which chases pointers:
@@ -776,7 +776,7 @@ xdr_finalexample(xdrsp, finalp)
}
.DE
Note that we could as easily call
-.I xdr_simple()
+.I xdr_simple()
here instead of
.I xdr_reference ().
.NH 1
@@ -791,23 +791,23 @@ by using lower layers of the RPC library.
It is assumed that you are familiar with sockets
and the system calls for dealing with them.
.LP
-There are several occasions when you may need to use lower layers of
-RPC. First, you may need to use TCP, since the higher layer uses UDP,
-which restricts RPC calls to 8K bytes of data. Using TCP permits calls
-to send long streams of data.
+There are several occasions when you may need to use lower layers of
+RPC. First, you may need to use TCP, since the higher layer uses UDP,
+which restricts RPC calls to 8K bytes of data. Using TCP permits calls
+to send long streams of data.
For an example, see the
.I TCP
section below. Second, you may want to allocate and free memory
-while serializing or deserializing with XDR routines.
-There is no call at the higher level to let
-you free memory explicitly.
+while serializing or deserializing with XDR routines.
+There is no call at the higher level to let
+you free memory explicitly.
For more explanation, see the
.I "Memory Allocation with XDR"
-section below.
-Third, you may need to perform authentication
-on either the client or server side, by supplying
+section below.
+Third, you may need to perform authentication
+on either the client or server side, by supplying
credentials or verifying them.
-See the explanation in the
+See the explanation in the
.I Authentication
section below.
.NH 2
@@ -815,9 +815,9 @@ section below.
.IX RPC "server side"
.LP
The server for the
-.I nusers()
+.I nusers()
program shown below does the same thing as the one using
-.I registerrpc()
+.I registerrpc()
above, but is written using a lower layer of the RPC package:
.ie t .DS
.el .DS L
@@ -865,7 +865,7 @@ nuser(rqstp, transp)
* and assign it to the variable \fInusers\fP
*/
.ft CW
- if (!svc_sendreply(transp, xdr_u_long, &nusers))
+ if (!svc_sendreply(transp, xdr_u_long, &nusers))
fprintf(stderr, "can't reply to RPC call\en");
return;
default:
@@ -877,7 +877,7 @@ nuser(rqstp, transp)
.LP
First, the server gets a transport handle, which is used
for receiving and replying to RPC messages.
-.I registerrpc()
+.I registerrpc()
uses
.I svcudp_create()
to get a UDP handle.
@@ -885,39 +885,39 @@ If you require a more reliable protocol, call
.I svctcp_create()
instead.
If the argument to
-.I svcudp_create()
+.I svcudp_create()
is
.I RPC_ANYSOCK
the RPC library creates a socket
on which to receive and reply to RPC calls. Otherwise,
-.I svcudp_create()
+.I svcudp_create()
expects its argument to be a valid socket number.
If you specify your own socket, it can be bound or unbound.
If it is bound to a port by the user, the port numbers of
-.I svcudp_create()
+.I svcudp_create()
and
.I clnttcp_create()
(the low-level client routine) must match.
.LP
If the user specifies the
-.I RPC_ANYSOCK
+.I RPC_ANYSOCK
argument, the RPC library routines will open sockets.
Otherwise they will expect the user to do so. The routines
-.I svcudp_create()
-and
+.I svcudp_create()
+and
.I clntudp_create()
will cause the RPC library routines to
-.I bind()
+.I bind()
their socket if it is not bound already.
.LP
A service may choose to register its port number with the
local portmapper service. This is done is done by specifying
a non-zero protocol number in
.I svc_register ().
-Incidently, a client can discover the server's port number by
-consulting the portmapper on their server's machine. This can
-be done automatically by specifying a zero port number in
-.I clntudp_create()
+Incidently, a client can discover the server's port number by
+consulting the portmapper on their server's machine. This can
+be done automatically by specifying a zero port number in
+.I clntudp_create()
or
.I clnttcp_create ().
.LP
@@ -926,21 +926,21 @@ After creating an
the next step is to call
.I pmap_unset()
so that if the
-.I nusers()
+.I nusers()
server crashed earlier,
any previous trace of it is erased before restarting.
More precisely,
-.I pmap_unset()
+.I pmap_unset()
erases the entry for
.I RUSERSPROG
from the port mapper's tables.
.LP
Finally, we associate the program number for
-.I nusers()
+.I nusers()
with the procedure
.I nuser ().
The final argument to
-.I svc_register()
+.I svc_register()
is normally the protocol being used,
which, in this case, is
.I IPPROTO_UDP
@@ -952,14 +952,14 @@ Also, registration is done on the program,
rather than procedure, level.
.LP
The user routine
-.I nuser()
+.I nuser()
must call and dispatch the appropriate XDR routines
based on the procedure number.
Note that
two things are handled by
-.I nuser()
+.I nuser()
that
-.I registerrpc()
+.I registerrpc()
handles automatically.
The first is that procedure
.I NULLPROC
@@ -986,9 +986,9 @@ As an example, we can add a procedure
which has an argument
.I nusers (),
and returns
-.I TRUE
+.I TRUE
or
-.I FALSE
+.I FALSE
depending on whether there are nusers logged on.
It would look like this:
.ie t .DS
@@ -1103,13 +1103,13 @@ svc_freeargs(transp, xdr_chararr2, &arrptr);
.DE
Note that, after being used, the character array can be freed with
.I svc_freeargs()
-.I svc_freeargs()
-will not attempt to free any memory if the variable indicating it
-is NULL. For example, in the the routine
+.I svc_freeargs()
+will not attempt to free any memory if the variable indicating it
+is NULL. For example, in the the routine
.I xdr_finalexample (),
given earlier, if
-.I finalp->string
-was NULL, then it would not be freed. The same is true for
+.I finalp->string
+was NULL, then it would not be freed. The same is true for
.I finalp->simplep .
.LP
To summarize, each XDR routine is responsible
@@ -1123,11 +1123,11 @@ the deserializer is used.
And when called from
.I svc_freeargs()
the memory deallocator is used. When building simple examples like those
-in this section, a user doesn't have to worry
-about the three modes.
+in this section, a user doesn't have to worry
+about the three modes.
See the
.I "External Data Representation: Sun Technical Notes"
-for examples of more sophisticated XDR routines that determine
+for examples of more sophisticated XDR routines that determine
which of the three modes they are in and adjust their behavior accordingly.
.KS
.NH 2
@@ -1207,9 +1207,9 @@ is
which takes a
.I CLIENT
pointer rather than a host name. The parameters to
-.I clnt_call()
+.I clnt_call()
are a
-.I CLIENT
+.I CLIENT
pointer, the procedure number,
the XDR routine for serializing the argument,
a pointer to the argument,
@@ -1218,36 +1218,36 @@ a pointer to where the return value will be placed,
and the time in seconds to wait for a reply.
.LP
The
-.I CLIENT
+.I CLIENT
pointer is encoded with the transport mechanism.
.I callrpc()
uses UDP, thus it calls
-.I clntudp_create()
+.I clntudp_create()
to get a
-.I CLIENT
+.I CLIENT
pointer. To get TCP (Transmission Control Protocol), you would use
.I clnttcp_create() .
.LP
The parameters to
-.I clntudp_create()
+.I clntudp_create()
are the server address, the program number, the version number,
a timeout value (between tries), and a pointer to a socket.
The final argument to
-.I clnt_call()
+.I clnt_call()
is the total time to wait for a response.
Thus, the number of tries is the
-.I clnt_call()
+.I clnt_call()
timeout divided by the
-.I clntudp_create()
+.I clntudp_create()
timeout.
.LP
Note that the
.I clnt_destroy()
call
always deallocates the space associated with the
-.I CLIENT
+.I CLIENT
handle. It closes the socket associated with the
-.I CLIENT
+.I CLIENT
handle, however, only if the RPC library opened it. It the
socket was opened by the user, it stays open. This makes it
possible, in cases where there are multiple client handles
@@ -1255,7 +1255,7 @@ using the same socket, to destroy one handle without closing
the socket that other handles are using.
.LP
To make a stream connection, the call to
-.I clntudp_create()
+.I clntudp_create()
is replaced with a call to
.I clnttcp_create() .
.DS
@@ -1265,10 +1265,10 @@ clnttcp_create(&server_addr, prognum, versnum, &sock,
.DE
There is no timeout argument; instead, the receive and send buffer
sizes must be specified. When the
-.I clnttcp_create()
+.I clnttcp_create()
call is made, a TCP connection is established.
All RPC calls using that
-.I CLIENT
+.I CLIENT
handle would use this connection.
The server side of an RPC call using TCP has
.I svcudp_create()
@@ -1278,9 +1278,9 @@ replaced by
.ft CW
transp = svctcp_create(RPC_ANYSOCK, 0, 0);
.DE
-The last two arguments to
-.I svctcp_create()
-are send and receive sizes respectively. If `0' is specified for
+The last two arguments to
+.I svctcp_create()
+are send and receive sizes respectively. If `0' is specified for
either of these, the system chooses a reasonable default.
.KS
.NH 1
@@ -1301,7 +1301,7 @@ If the other activity involves periodically updating a data structure,
the process can set an alarm signal before calling
.I svc_run()
But if the other activity
-involves waiting on a a file descriptor, the
+involves waiting on a file descriptor, the
.I svc_run()
call won't work.
The code for
@@ -1345,15 +1345,15 @@ yourself.
All you need to know are the file descriptors
of the socket(s) associated with the programs you are waiting on.
Thus you can have your own
-.I select()
+.I select()
.IX select() "" \fIselect()\fP
that waits on both the RPC socket,
and your own descriptors. Note that
-.I svc_fds()
-is a bit mask of all the file descriptors that RPC is using for
+.I svc_fds()
+is a bit mask of all the file descriptors that RPC is using for
services. It can change everytime that
.I any
-RPC library routine is called, because descriptors are constantly
+RPC library routine is called, because descriptors are constantly
being opened and closed, for example for TCP connections.
.NH 2
\&Broadcast RPC
@@ -1364,7 +1364,7 @@ The
.I portmapper
is a daemon that converts RPC program numbers
into DARPA protocol port numbers; see the
-.I portmap
+.I portmap
man page. You can't do broadcast RPC without the portmapper.
Here are the main differences between
broadcast RPC and normal RPC calls:
@@ -1421,7 +1421,7 @@ whether or not the user wants more responses.
.el .DS L
.ft CW
bool_t done;
- . . .
+ . . .
done = eachresult(resultsp, raddr)
caddr_t resultsp;
struct sockaddr_in *raddr; /* \fIAddr of responding machine\fP */
@@ -1518,7 +1518,7 @@ windowdispatch(rqstp, transp)
switch (rqstp->rq_proc) {
case NULLPROC:
- if (!svc_sendreply(transp, xdr_void, 0))
+ if (!svc_sendreply(transp, xdr_void, 0))
fprintf(stderr, "can't reply to RPC call\en");
return;
case RENDERSTRING:
@@ -1537,7 +1537,7 @@ windowdispatch(rqstp, transp)
* Code here to render the string \fIs\fP
*/
.ft CW
- if (!svc_sendreply(transp, xdr_void, NULL))
+ if (!svc_sendreply(transp, xdr_void, NULL))
fprintf(stderr, "can't reply to RPC call\en");
break;
case RENDERSTRING_BATCHED:
@@ -1795,7 +1795,7 @@ if the style is not one of the styles supported by the RPC package.
That the request's
.I rq_clntcred
field is either
-.I NULL
+.I NULL
or points to a well formed structure
that corresponds to a supported style of authentication credentials.
Remember that only
@@ -1846,7 +1846,7 @@ nuser(rqstp, transp)
.ft CW
switch (rqstp->rq_cred.oa_flavor) {
case AUTH_UNIX:
- unix_cred =
+ unix_cred =
(struct authunix_parms *)rqstp->rq_clntcred;
uid = unix_cred->aup_uid;
break;
@@ -1900,9 +1900,9 @@ instead.
.LP
The last point underscores the relation between
the RPC authentication package and the services;
-RPC deals only with
-.I authentication
-and not with individual services'
+RPC deals only with
+.I authentication
+and not with individual services'
.I "access control" .
The services themselves must implement their own access control policies
and reflect these policies as return statuses in their protocols.
@@ -1914,24 +1914,24 @@ and reflect these policies as return statuses in their protocols.
UNIX authentication is quite easy to defeat. Instead of using
.I authunix_create_default (),
one can call
-.I authunix_create()
+.I authunix_create()
and then modify the RPC authentication handle it returns by filling in
whatever user ID and hostname they wish the server to think they have.
DES authentication is thus recommended for people who want more security
than UNIX authentication offers.
.LP
The details of the DES authentication protocol are complicated and
-are not explained here.
+are not explained here.
See
.I "Remote Procedure Calls: Protocol Specification"
for the details.
.LP
In order for DES authentication to work, the
-.I keyserv(8c)
+.I keyserv(8c)
daemon must be running on both the server and client machines. The
users on these machines need public keys assigned by the network
administrator in the
-.I publickey(5)
+.I publickey(5)
database. And, they need to have decrypted their secret keys
using their login password. This automatically happens when one
logs in using
@@ -1963,12 +1963,12 @@ host2netname(servername, rhostname, NULL);
Here,
.I rhostname
is the hostname of the machine the server process is running on.
-.I host2netname()
+.I host2netname()
fills in
.I servername
to contain this root process's netname. If the
server process was run by a regular user, one could use the call
-.I user2netname()
+.I user2netname()
instead. Here is an example for a server process with the same user
ID as the client:
.DS
@@ -1977,15 +1977,15 @@ char servername[MAXNETNAMELEN];
user2netname(servername, getuid(), NULL);
.DE
The last argument to both of these calls,
-.I user2netname()
+.I user2netname()
and
.I host2netname (),
is the name of the naming domain where the server is located. The
-.I NULL
+.I NULL
used here means \*Quse the local domain name.\*U
.LP
The second argument to
-.I authdes_create()
+.I authdes_create()
is a lifetime for the credential. Here it is set to sixty
seconds. What that means is that the credential will expire 60
seconds from now. If some mischievous user tries to reuse the
@@ -1997,7 +1997,7 @@ remembers which credentials it has already seen in the near past,
and will not grant requests to duplicates.
.LP
The third argument to
-.I authdes_create()
+.I authdes_create()
is the address of the host to synchronize with. In order for DES
authentication to work, the server and client must agree upon the
time. Here we pass the address of the server itself, so the
@@ -2008,13 +2008,13 @@ which means \*Qdon't bother synchronizing.\*U You should only do this
if you are sure the client and server are already synchronized.
.LP
The final argument to
-.I authdes_create()
+.I authdes_create()
is the address of a DES encryption key to use for encrypting
timestamps and data. If this argument is
.I NULL ,
as it is in this example, a random key will be chosen. The client
may find out the encryption key being used by consulting the
-.I ah_key
+.I ah_key
field of the authentication handle.
.sp
.IP "\fIServer Side\fP"
@@ -2047,7 +2047,7 @@ nuser(rqstp, transp)
*/
.ft CW
- if (rqstp->rq_proc == NULLPROC) {
+ if (rqstp->rq_proc == NULLPROC) {
/* \fIsame as before\fP */
}
@@ -2078,7 +2078,7 @@ nuser(rqstp, transp)
.ft I
/*
* The rest is the same as before
- */
+ */
.ft CW
.vs
.DE
@@ -2087,7 +2087,7 @@ Note the use of the routine
the inverse of
.I user2netname ():
it takes a network ID and converts to a unix ID.
-.I netname2user ()
+.I netname2user ()
also supplies the group IDs which we don't use in this example,
but which may be useful to other UNIX programs.
.NH 2
@@ -2126,8 +2126,8 @@ you need to explicitly exit, since
.I svc_run()
never returns.
.LP
-The format of entries in
-.I /etc/inetd.conf
+The format of entries in
+.I /etc/inetd.conf
for RPC services is in one of the following two forms:
.ie t .DS
.el .DS L
@@ -2224,13 +2224,13 @@ nuser(rqstp, transp)
nusers2 = nusers;
switch (rqstp->rq_vers) {
case RUSERSVERS_ORIG:
- if (!svc_sendreply(transp, xdr_u_long,
+ if (!svc_sendreply(transp, xdr_u_long,
&nusers)) {
fprintf(stderr,"can't reply to RPC call\en");
}
break;
case RUSERSVERS_SHORT:
- if (!svc_sendreply(transp, xdr_u_short,
+ if (!svc_sendreply(transp, xdr_u_short,
&nusers2)) {
fprintf(stderr,"can't reply to RPC call\en");
}
@@ -2387,7 +2387,7 @@ callrpctcp(host, prognum, procnum, versnum,
main()
{
register SVCXPRT *transp;
- int rcp_service(), xdr_rcp();
+ int rcp_service(), xdr_rcp();
if ((transp = svctcp_create(RPC_ANYSOCK,
BUFSIZ, BUFSIZ)) == NULL) {
@@ -2524,7 +2524,7 @@ gettransient(proto, vers, sockp)
perror("getsockname");
return (0);
}
- while (!pmap_set(prognum++, vers, proto,
+ while (!pmap_set(prognum++, vers, proto,
ntohs(addr.sin_port))) continue;
return (prognum-1);
}
@@ -2534,17 +2534,17 @@ gettransient(proto, vers, sockp)
Note:
.I
The call to
-.I ntohs()
+.I ntohs()
is necessary to ensure that the port number in
.I "addr.sin_port" ,
-which is in
-.I network
-byte order, is passed in
+which is in
+.I network
+byte order, is passed in
.I host
byte order (as
-.I pmap_set()
+.I pmap_set()
expects). See the
-.I byteorder(3N)
+.I byteorder(3N)
man page for more details on the conversion of network
addresses from network to host byte order.
.KS
diff --git a/lib/libc/rpc/PSD.doc/xdr.nts.ms b/lib/libc/rpc/PSD.doc/xdr.nts.ms
index 0c573e9..260c7f3 100644
--- a/lib/libc/rpc/PSD.doc/xdr.nts.ms
+++ b/lib/libc/rpc/PSD.doc/xdr.nts.ms
@@ -23,33 +23,33 @@ delim $$
This chapter contains technical notes on Sun's implementation of the
External Data Representation (XDR) standard, a set of library routines
that allow a C programmer to describe arbitrary data structures in a
-machinex-independent fashion.
+machinex-independent fashion.
For a formal specification of the XDR
standard, see the
.I "External Data Representation Standard: Protocol Specification".
-XDR is the backbone of Sun's Remote Procedure Call package, in the
-sense that data for remote procedure calls is transmitted using the
+XDR is the backbone of Sun's Remote Procedure Call package, in the
+sense that data for remote procedure calls is transmitted using the
standard. XDR library routines should be used to transmit data
that is accessed (read or written) by more than one type of machine.\**
.FS
.IX XDR "system routines"
For a compete specification of the system External Data Representation
-routines, see the
-.I xdr(3N)
+routines, see the
+.I xdr(3N)
manual page.
.FE
.LP
-This chapter contains a short tutorial overview of the XDR library
+This chapter contains a short tutorial overview of the XDR library
routines, a guide to accessing currently available XDR streams, and
information on defining new streams and data types. XDR was designed
-to work across different languages, operating systems, and machine
+to work across different languages, operating systems, and machine
architectures. Most users (particularly RPC users) will only need
the information in the
.I "Number Filters",
.I "Floating Point Filters",
and
.I "Enumeration Filters"
-sections.
+sections.
Programmers wishing to implement RPC and XDR on new machines
will be interested in the rest of the chapter, as well as the
.I "External Data Representaiton Standard: Protocol Specification",
@@ -57,7 +57,7 @@ which will be their primary reference.
.SH
Note:
.I
-.I rpcgen
+.I rpcgen
can be used to write XDR routines even in cases where no RPC calls are
being made.
.LP
@@ -126,9 +126,9 @@ checking, and (b) they exhibit the same behavior when executed
on two different hardware architectures, a Sun and a VAX.
.LP
Piping the output of the
-.I writer
+.I writer
program to the
-.I reader
+.I reader
program gives identical results on a Sun or a VAX.
.DS
.ft CW
@@ -141,11 +141,11 @@ vax% \fBwriter | reader\fP
0 1 2 3 4 5 6 7
vax%
.DE
-With the advent of local area networks and 4.2BSD came the concept
+With the advent of local area networks and 4.2BSD came the concept
of \*Qnetwork pipes\*U \(em a process produces data on one machine,
and a second process consumes data on another machine.
A network pipe can be constructed with
-.I writer
+.I writer
and
.I reader .
Here are the results if the first produces data on a Sun,
@@ -158,9 +158,9 @@ sun% \fBwriter | rsh vax reader\fP
sun%
.DE
Identical results can be obtained by executing
-.I writer
+.I writer
on the VAX and
-.I reader
+.I reader
on the Sun. These results occur because the byte ordering
of long integers differs between the VAX and the Sun,
even though word size is the same.
@@ -170,9 +170,9 @@ when four bytes are reversed, the 1 winds up in the 24th bit.
Whenever data is shared by two or more machine types, there is
a need for portable data. Programs can be made data-portable by
replacing the
-.I read()
+.I read()
and
-.I write()
+.I write()
calls with calls to an XDR library routine
.I xdr_long() ,
a filter that knows the standard representation
@@ -257,7 +257,7 @@ outside the machine where they are defined.
\&A Canonical Standard
.IX XDR "canonical standard"
.LP
-XDR's approach to standardizing data representations is
+XDR's approach to standardizing data representations is
.I canonical .
That is, XDR defines a single byte order (Big Endian), a single
floating-point representation (IEEE), and so on. Any program running on
@@ -278,38 +278,38 @@ canonical standards that they already understand.
.LP
There are strong precedents for XDR's canonical approach. For example,
TCP/IP, UDP/IP, XNS, Ethernet, and, indeed, all protocols below layer five
-of the ISO model, are canonical protocols. The advantage of any canonical
-approach is simplicity; in the case of XDR, a single set of conversion
-routines is written once and is never touched again. The canonical approach
-has a disadvantage, but it is unimportant in real-world data transfer
+of the ISO model, are canonical protocols. The advantage of any canonical
+approach is simplicity; in the case of XDR, a single set of conversion
+routines is written once and is never touched again. The canonical approach
+has a disadvantage, but it is unimportant in real-world data transfer
applications. Suppose two Little-Endian machines are transferring integers
-according to the XDR standard. The sending machine converts the integers
+according to the XDR standard. The sending machine converts the integers
from Little-Endian byte order to XDR (Big-Endian) byte order; the receiving
machine performs the reverse conversion. Because both machines observe the
same byte order, their conversions are unnecessary. The point, however, is
not necessity, but cost as compared to the alternative.
.LP
The time spent converting to and from a canonical representation is
-insignificant, especially in networking applications. Most of the time
-required to prepare a data structure for transfer is not spent in conversion
-but in traversing the elements of the data structure. To transmit a tree,
+insignificant, especially in networking applications. Most of the time
+required to prepare a data structure for transfer is not spent in conversion
+but in traversing the elements of the data structure. To transmit a tree,
for example, each leaf must be visited and each element in a leaf record must
be copied to a buffer and aligned there; storage for the leaf may have to be
-deallocated as well. Similarly, to receive a tree, storage must be
+deallocated as well. Similarly, to receive a tree, storage must be
allocated for each leaf, data must be moved from the buffer to the leaf and
-properly aligned, and pointers must be constructed to link the leaves
+properly aligned, and pointers must be constructed to link the leaves
together. Every machine pays the cost of traversing and copying data
-structures whether or not conversion is required. In networking
+structures whether or not conversion is required. In networking
applications, communications overhead\(emthe time required to move the data
-down through the sender's protocol layers, across the network and up through
+down through the sender's protocol layers, across the network and up through
the receiver's protocol layers\(emdwarfs conversion overhead.
.NH 1
\&The XDR Library
.IX "XDR" "library"
.LP
The XDR library not only solves data portability problems, it also
-allows you to write and read arbitrary C constructs in a consistent,
-specified, well-documented manner. Thus, it can make sense to use the
+allows you to write and read arbitrary C constructs in a consistent,
+specified, well-documented manner. Thus, it can make sense to use the
library even when the data is not shared among machines on a network.
.LP
The XDR library has filter routines for
@@ -333,19 +333,19 @@ so we use
The parameters to XDR stream creation routines
vary according to their function.
In our example,
-.I xdrstdio_create()
+.I xdrstdio_create()
takes a pointer to an XDR structure that it initializes,
a pointer to a
-.I FILE
+.I FILE
that the input or output is performed on, and the operation.
The operation may be
.I XDR_ENCODE
for serializing in the
-.I writer
+.I writer
program, or
.I XDR_DECODE
for deserializing in the
-.I reader
+.I reader
program.
.LP
Note: RPC users never need to create XDR streams;
@@ -353,14 +353,14 @@ the RPC system itself creates these streams,
which are then passed to the users.
.LP
The
-.I xdr_long()
+.I xdr_long()
.IX xdr_long() "" "\fIxdr_long()\fP"
-primitive is characteristic of most XDR library
+primitive is characteristic of most XDR library
primitives and all client XDR routines.
First, the routine returns
-.I FALSE
+.I FALSE
(0) if it fails, and
-.I TRUE
+.I TRUE
(1) if it succeeds.
Second, for each data type,
.I xxx ,
@@ -374,18 +374,18 @@ xdr_xxx(xdrs, xp)
}
.DE
In our case,
-.I xxx
+.I xxx
is long, and the corresponding XDR routine is
a primitive,
.I xdr_long() .
The client could also define an arbitrary structure
-.I xxx
+.I xxx
in which case the client would also supply the routine
.I xdr_xxx (),
describing each field by calling XDR routines
of the appropriate type.
In all cases the first parameter,
-.I xdrs
+.I xdrs
can be treated as an opaque handle,
and passed to the primitive routines.
.LP
@@ -400,9 +400,9 @@ of an object rather than the object itself \(em
only in the case of deserialization is the object modified.
This feature is not shown in our trivial example,
but its value becomes obvious when nontrivial data structures
-are passed among machines.
+are passed among machines.
If needed, the user can obtain the
-direction of the XDR operation.
+direction of the XDR operation.
See the
.I "XDR Operation Directions"
section below for details.
@@ -436,20 +436,20 @@ xdr_gnumbers(xdrs, gp)
}
.DE
Note that the parameter
-.I xdrs
+.I xdrs
is never inspected or modified;
it is only passed on to the subcomponent routines.
It is imperative to inspect the return value of each XDR routine call,
and to give up immediately and return
-.I FALSE
+.I FALSE
if the subroutine fails.
.LP
This example also shows that the type
.I bool_t
is declared as an integer whose only values are
-.I TRUE
+.I TRUE
(1) and
-.I FALSE
+.I FALSE
(0). This document uses the following definitions:
.ie t .DS
.el .DS L
@@ -460,7 +460,7 @@ is declared as an integer whose only values are
.DE
.LP
Keeping these conventions in mind,
-.I xdr_gnumbers()
+.I xdr_gnumbers()
can be rewritten as follows:
.ie t .DS
.el .DS L
@@ -540,9 +540,9 @@ is an XDR stream handle.
The second parameter is the address of the number
that provides data to the stream or receives data from it.
All routines return
-.I TRUE
+.I TRUE
if they complete successfully, and
-.I FALSE
+.I FALSE
otherwise.
.NH 2
\&Floating Point Filters
@@ -561,15 +561,15 @@ bool_t xdr_double(xdrs, dp)
double *dp;
.DE
The first parameter,
-.I xdrs
+.I xdrs
is an XDR stream handle.
The second parameter is the address
of the floating point number that provides data to the stream
or receives data from it.
Both routines return
-.I TRUE
+.I TRUE
if they complete successfully, and
-.I FALSE
+.I FALSE
otherwise.
.LP
Note: Since the numbers are represented in IEEE floating point,
@@ -581,14 +581,14 @@ into a machine-specific representation, or vice-versa.
.LP
The XDR library provides a primitive for generic enumerations.
The primitive assumes that a C
-.I enum
+.I enum
has the same representation inside the machine as a C integer.
The boolean type is an important instance of the
.I enum .
The external representation of a boolean is always
-.I TRUE
-(1) or
-.I FALSE
+.I TRUE
+(1) or
+.I FALSE
(0).
.DS
.ft CW
@@ -610,7 +610,7 @@ The second parameters
.I ep
and
.I bp
-are addresses of the associated type that provides data to, or
+are addresses of the associated type that provides data to, or
receives data from, the stream
.I xdrs .
.NH 2
@@ -674,42 +674,42 @@ bool_t xdr_string(xdrs, sp, maxlength)
u_int maxlength;
.DE
The first parameter
-.I xdrs
+.I xdrs
is the XDR stream handle.
The second parameter
-.I sp
+.I sp
is a pointer to a string (type
.I "char **" .
The third parameter
-.I maxlength
+.I maxlength
specifies the maximum number of bytes allowed during encoding or decoding.
its value is usually specified by a protocol. For example, a protocol
specification may say that a file name may be no longer than 255 characters.
.LP
The routine returns
-.I FALSE
+.I FALSE
if the number of characters exceeds
.I maxlength ,
and
-.I TRUE
+.I TRUE
if it doesn't.
.SH
Keep
-.I maxlength
+.I maxlength
small. If it is too big you can blow the heap, since
-.I xdr_string()
+.I xdr_string()
will call
-.I malloc()
+.I malloc()
for space.
.LP
The behavior of
-.I xdr_string()
+.I xdr_string()
.IX xdr_string() "" \fIxdr_string()\fP
is similar to the behavior of other routines
discussed in this section. The direction
-.I XDR_ENCODE
+.I XDR_ENCODE
is easiest to understand. The parameter
-.I sp
+.I sp
points to a string of a certain length;
if the string does not exceed
.I maxlength ,
@@ -720,14 +720,14 @@ First the length of the incoming string is determined;
it must not exceed
.I maxlength .
Next
-.I sp
+.I sp
is dereferenced; if the the value is
.I NULL ,
then a string of the appropriate length is allocated and
-.I *sp
+.I *sp
is set to this string.
If the original value of
-.I *sp
+.I *sp
is non-null, then the XDR package assumes
that a target area has been allocated,
which can hold strings no longer than
@@ -736,33 +736,33 @@ In either case, the string is decoded into the target area.
The routine then appends a null character to the string.
.LP
In the
-.I XDR_FREE
+.I XDR_FREE
operation, the string is obtained by dereferencing
.I sp .
If the string is not
.I NULL ,
it is freed and
-.I *sp
+.I *sp
is set to
.I NULL .
In this operation,
-.I xdr_string()
+.I xdr_string()
ignores the
-.I maxlength
+.I maxlength
parameter.
.NH 3
\&Byte Arrays
.IX "XDR library" "byte arrays"
.LP
Often variable-length arrays of bytes are preferable to strings.
-Byte arrays differ from strings in the following three ways:
+Byte arrays differ from strings in the following three ways:
1) the length of the array (the byte count) is explicitly
located in an unsigned integer,
2) the byte sequence is not terminated by a null character, and
3) the external representation of the bytes is the same as their
internal representation.
The primitive
-.I xdr_bytes()
+.I xdr_bytes()
.IX xdr_bytes() "" \fIxdr_bytes()\fP
converts between the internal and external
representations of byte arrays:
@@ -779,9 +779,9 @@ are identical to the first, second and third parameters of
.I xdr_string (),
respectively.
The length of the byte area is obtained by dereferencing
-.I lp
+.I lp
when serializing;
-.I *lp
+.I *lp
is set to the byte length when deserializing.
.NH 3
\&Arrays
@@ -790,7 +790,7 @@ is set to the byte length when deserializing.
The XDR library package provides a primitive
for handling arrays of arbitrary elements.
The
-.I xdr_bytes()
+.I xdr_bytes()
routine treats a subset of generic arrays,
in which the size of array elements is known to be 1,
and the external description of each element is built-in.
@@ -798,7 +798,7 @@ The generic array primitive,
.I xdr_array() ,
.IX xdr_array() "" \fIxdr_array()\fP
requires parameters identical to those of
-.I xdr_bytes()
+.I xdr_bytes()
plus two more:
the size of array elements,
and an XDR routine to handle each of the elements.
@@ -816,23 +816,23 @@ xdr_array(xdrs, ap, lp, maxlength, elementsiz, xdr_element)
bool_t (*xdr_element)();
.DE
The parameter
-.I ap
+.I ap
is the address of the pointer to the array.
If
-.I *ap
+.I *ap
is
-.I NULL
+.I NULL
when the array is being deserialized,
XDR allocates an array of the appropriate size and sets
-.I *ap
+.I *ap
to that array.
The element count of the array is obtained from
-.I *lp
+.I *lp
when the array is serialized;
-.I *lp
-is set to the array length when the array is deserialized.
+.I *lp
+is set to the array length when the array is deserialized.
The parameter
-.I maxlength
+.I maxlength
is the maximum number of elements that the array is allowed to have;
.I elementsiz
is the byte size of each element of the array
@@ -840,28 +840,28 @@ is the byte size of each element of the array
.I sizeof()
can be used to obtain this value).
The
-.I xdr_element()
+.I xdr_element()
.IX xdr_element() "" \fIxdr_element()\fP
routine is called to serialize, deserialize, or free
each element of the array.
.br
.LP
-Before defining more constructed data types, it is appropriate to
+Before defining more constructed data types, it is appropriate to
present three examples.
.LP
.I "Example A:"
.br
-A user on a networked machine can be identified by
+A user on a networked machine can be identified by
(a) the machine name, such as
.I krypton :
see the
-.I gethostname
+.I gethostname
man page; (b) the user's UID: see the
-.I geteuid
-man page; and (c) the group numbers to which the user belongs:
+.I geteuid
+man page; and (c) the group numbers to which the user belongs:
see the
-.I getgroups
-man page. A structure with this information and its associated
+.I getgroups
+man page. A structure with this information and its associated
XDR routine could be coded like this:
.ie t .DS
.el .DS L
@@ -882,7 +882,7 @@ xdr_netuser(xdrs, nup)
{
return(xdr_string(xdrs, &nup->nu_machinename, NLEN) &&
xdr_int(xdrs, &nup->nu_uid) &&
- xdr_array(xdrs, &nup->nu_gids, &nup->nu_glen,
+ xdr_array(xdrs, &nup->nu_gids, &nup->nu_glen,
NGRPS, sizeof (int), xdr_int));
}
.DE
@@ -973,13 +973,13 @@ xdr_history(xdrs, hp)
}
.DE
The most confusing part of this example is that the routine
-.I xdr_wrap_string()
+.I xdr_wrap_string()
is needed to package the
-.I xdr_string()
+.I xdr_string()
routine, because the implementation of
-.I xdr_array()
+.I xdr_array()
only passes two parameters to the array element description routine;
-.I xdr_wrap_string()
+.I xdr_wrap_string()
supplies the third parameter to
.I xdr_string ().
.LP
@@ -995,7 +995,7 @@ Handles are never inspected by clients;
they are obtained and submitted.
That is to say, handles are opaque.
The
-.I xdr_opaque()
+.I xdr_opaque()
.IX xdr_opaque() "" \fIxdr_opaque()\fP
primitive is used for describing fixed sized, opaque bytes.
.DS
@@ -1006,7 +1006,7 @@ bool_t xdr_opaque(xdrs, p, len)
u_int len;
.DE
The parameter
-.I p
+.I p
is the location of the bytes;
.I len
is the number of bytes in the opaque object.
@@ -1042,7 +1042,7 @@ xdr_netuser(xdrs, nup)
return(FALSE);
if (!xdr_int(xdrs, &nup->nu_uid))
return(FALSE);
- if (!xdr_vector(xdrs, nup->nu_gids, NGRPS, sizeof(int),
+ if (!xdr_vector(xdrs, nup->nu_gids, NGRPS, sizeof(int),
xdr_int)) {
return(FALSE);
}
@@ -1071,18 +1071,18 @@ bool_t xdr_union(xdrs, dscmp, unp, arms, defaultarm)
struct xdr_discrim *arms;
bool_t (*defaultarm)(); /* \fImay equal NULL\fP */
.DE
-First the routine translates the discriminant of the union located at
+First the routine translates the discriminant of the union located at
.I *dscmp .
The discriminant is always an
.I enum_t .
Next the union located at
-.I *unp
+.I *unp
is translated.
The parameter
.I arms
is a pointer to an array of
.I xdr_discrim
-structures.
+structures.
Each structure contains an ordered pair of
.I [value,proc] .
If the union's discriminant is equal to the associated
@@ -1093,7 +1093,7 @@ is called to translate the union.
The end of the
.I xdr_discrim
structure array is denoted by a routine of value
-.I NULL
+.I NULL
(0). If the discriminant is not found in the
.I arms
array, then the
@@ -1105,7 +1105,7 @@ otherwise the routine returns
.I "Example D:"
Suppose the type of a union may be integer,
character pointer (a string), or a
-.I gnumbers
+.I gnumbers
structure.
Also, assume the union and its current type
are declared in a structure.
@@ -1147,21 +1147,21 @@ xdr_u_tag(xdrs, utp)
}
.DE
The routine
-.I xdr_gnumbers()
-was presented above in
+.I xdr_gnumbers()
+was presented above in
.I "The XDR Library"
section.
-.I xdr_wrap_string()
+.I xdr_wrap_string()
was presented in example C.
-The default
-.I arm
+The default
+.I arm
parameter to
-.I xdr_union()
+.I xdr_union()
(the last parameter) is
-.I NULL
+.I NULL
in this example. Therefore the value of the union's discriminant
may legally take on only values listed in the
-.I u_tag_arms
+.I u_tag_arms
array. This example also demonstrates that
the elements of the arm's array do not need to be sorted.
.LP
@@ -1175,7 +1175,7 @@ representation of the discriminant and guarantees that different
C compilers emit identical discriminant values.
.LP
Exercise: Implement
-.I xdr_union()
+.I xdr_union()
using the other primitives in this section.
.NH 3
\&Pointers
@@ -1184,7 +1184,7 @@ using the other primitives in this section.
In C it is often convenient to put pointers
to another structure within a structure.
The
-.I xdr_reference()
+.I xdr_reference()
.IX xdr_reference() "" \fIxdr_reference()\fP
primitive makes it easy to serialize, deserialize, and free
these referenced structures.
@@ -1198,40 +1198,40 @@ bool_t xdr_reference(xdrs, pp, size, proc)
.DE
.LP
Parameter
-.I pp
+.I pp
is the address of
the pointer to the structure;
parameter
.I ssize
is the size in bytes of the structure (use the C function
-.I sizeof()
+.I sizeof()
to obtain this value); and
.I proc
is the XDR routine that describes the structure.
When decoding data, storage is allocated if
-.I *pp
+.I *pp
is
.I NULL .
.LP
There is no need for a primitive
-.I xdr_struct()
+.I xdr_struct()
to describe structures within structures,
because pointers are always sufficient.
.LP
Exercise: Implement
-.I xdr_reference()
+.I xdr_reference()
using
.I xdr_array ().
Warning:
-.I xdr_reference()
+.I xdr_reference()
and
-.I xdr_array()
+.I xdr_array()
are NOT interchangeable external representations of data.
.LP
.I "Example E:"
Suppose there is a structure containing a person's name
and a pointer to a
-.I gnumbers
+.I gnumbers
structure containing the person's gross assets and liabilities.
The construct is:
.DS
@@ -1257,18 +1257,18 @@ xdr_pgn(xdrs, pp)
}
.DE
.IX "pointer semantics and XDR"
-.I "Pointer Semantics and XDR"
+.I "Pointer Semantics and XDR"
.LP
-In many applications, C programmers attach double meaning to
+In many applications, C programmers attach double meaning to
the values of a pointer. Typically the value
-.I NULL
+.I NULL
(or zero) means data is not needed,
yet some application-specific interpretation applies.
In essence, the C programmer is encoding
a discriminated union efficiently
by overloading the interpretation of the value of a pointer.
For instance, in example E a
-.I NULL
+.I NULL
pointer value for
.I gnp
could indicate that
@@ -1280,21 +1280,21 @@ Linked lists are an extreme example of the use
of application-specific pointer interpretation.
.LP
The primitive
-.I xdr_reference()
+.I xdr_reference()
.IX xdr_reference() "" \fIxdr_reference()\fP
cannot and does not attach any special
meaning to a null-value pointer during serialization.
That is, passing an address of a pointer whose value is
-.I NULL
+.I NULL
to
-.I xdr_reference()
+.I xdr_reference()
when serialing data will most likely cause a memory fault and, on the UNIX
system, a core dump.
.LP
-.I xdr_pointer()
-correctly handles
-.I NULL
-pointers. For more information about its use, see
+.I xdr_pointer()
+correctly handles
+.I NULL
+pointers. For more information about its use, see
the
.I "Linked Lists"
topics below.
@@ -1303,19 +1303,19 @@ topics below.
After reading the section on
.I "Linked Lists" ,
return here and extend example E so that
-it can correctly deal with
-.I NULL
+it can correctly deal with
+.I NULL
pointer values.
.LP
.I Exercise:
Using the
.I xdr_union (),
-.I xdr_reference()
+.I xdr_reference()
and
-.I xdr_void()
+.I xdr_void()
primitives, implement a generic pointer handling primitive
that implicitly deals with
-.I NULL
+.I NULL
pointers. That is, implement
.I xdr_pointer ().
.NH 2
@@ -1337,31 +1337,31 @@ xdr_destroy(xdrs)
XDR *xdrs;
.DE
The routine
-.I xdr_getpos()
+.I xdr_getpos()
.IX xdr_getpos() "" \fIxdr_getpos()\fP
returns an unsigned integer
that describes the current position in the data stream.
Warning: In some XDR streams, the returned value of
-.I xdr_getpos()
+.I xdr_getpos()
is meaningless;
the routine returns a \-1 in this case
(though \-1 should be a legitimate value).
.LP
The routine
-.I xdr_setpos()
+.I xdr_setpos()
.IX xdr_setpos() "" \fIxdr_setpos()\fP
sets a stream position to
.I pos .
Warning: In some XDR streams, setting a position is impossible;
in such cases,
-.I xdr_setpos()
+.I xdr_setpos()
will return
.I FALSE .
This routine will also fail if the requested position is out-of-bounds.
The definition of bounds varies from stream to stream.
.LP
The
-.I xdr_destroy()
+.I xdr_destroy()
.IX xdr_destroy() "" \fIxdr_destroy()\fP
primitive destroys the XDR stream.
Usage of the stream
@@ -1403,7 +1403,7 @@ streams, TCP/IP connections and UNIX files, and memory.
.IX "XDR" "standard I/O streams"
.LP
XDR streams can be interfaced to standard I/O using the
-.I xdrstdio_create()
+.I xdrstdio_create()
.IX xdrstdio_create() "" \fIxdrstdio_create()\fP
routine as follows:
.DS
@@ -1418,7 +1418,7 @@ xdrstdio_create(xdrs, fp, x_op)
enum xdr_op x_op;
.DE
The routine
-.I xdrstdio_create()
+.I xdrstdio_create()
initializes an XDR stream pointed to by
.I xdrs .
The XDR stream interfaces to the standard I/O library.
@@ -1445,7 +1445,7 @@ xdrmem_create(xdrs, addr, len, x_op)
enum xdr_op x_op;
.DE
The routine
-.I xdrmem_create()
+.I xdrmem_create()
.IX xdrmem_create() "" \fIxdrmem_create()\fP
initializes an XDR stream in local memory.
The memory is pointed to by parameter
@@ -1462,7 +1462,7 @@ are identical to the corresponding parameters of
Currently, the UDP/IP implementation of RPC uses
.I xdrmem_create ().
Complete call or result messages are built in memory before calling the
-.I sendto()
+.I sendto()
system routine.
.NH 3
\&Record (TCP/IP) Streams
@@ -1483,7 +1483,7 @@ xdrrec_create(xdrs,
int (*readproc)(), (*writeproc)();
.DE
The routine
-.I xdrrec_create()
+.I xdrrec_create()
provides an XDR stream interface that allows for a bidirectional,
arbitrarily long sequence of records.
The contents of the records are meant to be data in XDR form.
@@ -1502,13 +1502,13 @@ and
determine the size in bytes of the output and input buffers, respectively;
if their values are zero (0), then predetermined defaults are used.
When a buffer needs to be filled or flushed, the routine
-.I readproc()
+.I readproc()
or
-.I writeproc()
+.I writeproc()
is called, respectively.
The usage and behavior of these
routines are similar to the UNIX system calls
-.I read()
+.I read()
and
.I write ().
However,
@@ -1521,9 +1521,9 @@ and
and the results
(byte count) are identical to the system routines.
If
-.I xxx
+.I xxx
is
-.I readproc()
+.I readproc()
or
.I writeproc (),
then it has the following form:
@@ -1563,7 +1563,7 @@ xdrrec_eof(xdrs)
XDR *xdrs;
.DE
The routine
-.I xdrrec_endofrecord()
+.I xdrrec_endofrecord()
.IX xdrrec_endofrecord() "" \fIxdrrec_endofrecord()\fP
causes the current outgoing data to be marked as a record.
If the parameter
@@ -1571,13 +1571,13 @@ If the parameter
is
.I TRUE ,
then the stream's
-.I writeproc
+.I writeproc
will be called; otherwise,
-.I writeproc
+.I writeproc
will be called when the output buffer has been filled.
.LP
The routine
-.I xdrrec_skiprecord()
+.I xdrrec_skiprecord()
.IX xdrrec_skiprecord() "" \fIxdrrec_skiprecord()\fP
causes an input stream's position to be moved past
the current record boundary and onto the
@@ -1585,7 +1585,7 @@ beginning of the next record in the stream.
.LP
If there is no more data in the stream's input buffer,
then the routine
-.I xdrrec_eof()
+.I xdrrec_eof()
.IX xdrrec_eof() "" \fIxdrrec_eof()\fP
returns
.I TRUE .
@@ -1658,13 +1658,13 @@ The caller can then use the buffer segment for any purpose.
From the stream's point of view, the bytes in the
buffer segment have been consumed or put.
The routine may return
-.I NULL
+.I NULL
if it cannot return a buffer segment of the requested size.
(The
-.I x_inline()
+.I x_inline()
routine is for cycle squeezers.
Use of the resulting buffer is not data-portable.
-Users are encouraged not to use this feature.)
+Users are encouraged not to use this feature.)
.LP
The operations
.I x_getbytes()
@@ -1673,9 +1673,9 @@ and
blindly get and put sequences of bytes
from or to the underlying stream;
they return
-.I TRUE
+.I TRUE
if they are successful, and
-.I FALSE
+.I FALSE
otherwise. The routines have identical parameters (replace
.I xxx ):
.DS
@@ -1707,7 +1707,7 @@ have the same bit representations as unsigned integers.
The routines return
.I TRUE
if they succeed, and
-.I FALSE
+.I FALSE
otherwise. They have identical parameters:
.DS
.ft CW
@@ -1727,11 +1727,11 @@ This section describes techniques for passing data structures that
are not covered in the preceding sections. Such structures include
linked lists (of arbitrary lengths). Unlike the simpler examples
covered in the earlier sections, the following examples are written
-using both the XDR C library routines and the XDR data description
-language.
+using both the XDR C library routines and the XDR data description
+language.
The
.I "External Data Representation Standard: Protocol Specification"
-describes this
+describes this
language in complete detail.
.NH 2
\&Linked Lists
@@ -1739,9 +1739,9 @@ language in complete detail.
.LP
The last example in the
.I Pointers
-topic earlier in this chapter
+topic earlier in this chapter
presented a C data structure and its associated XDR
-routines for a individual's gross assets and liabilities.
+routines for an individual's gross assets and liabilities.
The example is duplicated below:
.ie t .DS
.el .DS L
@@ -1762,7 +1762,7 @@ xdr_gnumbers(xdrs, gp)
}
.DE
.LP
-Now assume that we wish to implement a linked list of such information.
+Now assume that we wish to implement a linked list of such information.
A data structure could be constructed as follows:
.ie t .DS
.el .DS L
@@ -1777,16 +1777,16 @@ typedef struct gnumbers_node *gnumbers_list;
.LP
The head of the linked list can be thought of as the data object;
that is, the head is not merely a convenient shorthand for a
-structure. Similarly the
-.I gn_next
-field is used to indicate whether or not the object has terminated.
-Unfortunately, if the object continues, the
-.I gn_next
-field is also the address of where it continues. The link addresses
+structure. Similarly the
+.I gn_next
+field is used to indicate whether or not the object has terminated.
+Unfortunately, if the object continues, the
+.I gn_next
+field is also the address of where it continues. The link addresses
carry no useful information when the object is serialized.
.LP
-The XDR data description of this linked list is described by the
-recursive declaration of
+The XDR data description of this linked list is described by the
+recursive declaration of
.I gnumbers_list :
.ie t .DS
.el .DS L
@@ -1803,22 +1803,22 @@ struct gnumbers_node {
.DE
.LP
In this description, the boolean indicates whether there is more data
-following it. If the boolean is
+following it. If the boolean is
.I FALSE ,
-then it is the last data field of the structure. If it is
+then it is the last data field of the structure. If it is
.I TRUE ,
-then it is followed by a gnumbers structure and (recursively) by a
+then it is followed by a gnumbers structure and (recursively) by a
.I gnumbers_list .
-Note that the C declaration has no boolean explicitly declared in it
-(though the
-.I gn_next
-field implicitly carries the information), while the XDR data
+Note that the C declaration has no boolean explicitly declared in it
+(though the
+.I gn_next
+field implicitly carries the information), while the XDR data
description has no pointer explicitly declared in it.
.LP
-Hints for writing the XDR routines for a
-.I gnumbers_list
-follow easily from the XDR description above. Note how the primitive
-.I xdr_pointer()
+Hints for writing the XDR routines for a
+.I gnumbers_list
+follow easily from the XDR description above. Note how the primitive
+.I xdr_pointer()
is used to implement the XDR union above.
.ie t .DS
.el .DS L
@@ -1837,8 +1837,8 @@ xdr_gnumbers_list(xdrs, gnp)
XDR *xdrs;
gnumbers_list *gnp;
{
- return(xdr_pointer(xdrs, gnp,
- sizeof(struct gnumbers_node),
+ return(xdr_pointer(xdrs, gnp,
+ sizeof(struct gnumbers_node),
xdr_gnumbers_node));
}
.DE
@@ -1870,12 +1870,12 @@ xdr_gnumbers_list(xdrs, gnp)
if (xdrs->x_op == XDR_FREE) {
nextp = &(*gnp)->gn_next;
}
- if (!xdr_reference(xdrs, gnp,
+ if (!xdr_reference(xdrs, gnp,
sizeof(struct gnumbers_node), xdr_gnumbers)) {
return(FALSE);
}
- gnp = (xdrs->x_op == XDR_FREE) ?
+ gnp = (xdrs->x_op == XDR_FREE) ?
nextp : &(*gnp)->gn_next;
}
*gnp = NULL;
@@ -1885,83 +1885,83 @@ xdr_gnumbers_list(xdrs, gnp)
.LP
The first task is to find out whether there is more data or not,
so that this boolean information can be serialized. Notice that
-this statement is unnecessary in the
-.I XDR_DECODE
-case, since the value of more_data is not known until we
+this statement is unnecessary in the
+.I XDR_DECODE
+case, since the value of more_data is not known until we
deserialize it in the next statement.
.LP
-The next statement XDR's the more_data field of the XDR union.
-Then if there is truly no more data, we set this last pointer to
-.I NULL
-to indicate the end of the list, and return
-.I TRUE
-because we are done. Note that setting the pointer to
-.I NULL
-is only important in the
-.I XDR_DECODE
-case, since it is already
-.I NULL
-in the
-.I XDR_ENCODE
-and
-XDR_FREE
+The next statement XDR's the more_data field of the XDR union.
+Then if there is truly no more data, we set this last pointer to
+.I NULL
+to indicate the end of the list, and return
+.I TRUE
+because we are done. Note that setting the pointer to
+.I NULL
+is only important in the
+.I XDR_DECODE
+case, since it is already
+.I NULL
+in the
+.I XDR_ENCODE
+and
+XDR_FREE
cases.
.LP
-Next, if the direction is
+Next, if the direction is
.I XDR_FREE ,
-the value of
-.I nextp
-is set to indicate the location of the next pointer in the list.
-We do this now because we need to dereference gnp to find the
-location of the next item in the list, and after the next
+the value of
+.I nextp
+is set to indicate the location of the next pointer in the list.
+We do this now because we need to dereference gnp to find the
+location of the next item in the list, and after the next
statement the storage pointed to by
-.I gnp
+.I gnp
will be freed up and no be longer valid. We can't do this for all
-directions though, because in the
-.I XDR_DECODE
-direction the value of
-.I gnp
+directions though, because in the
+.I XDR_DECODE
+direction the value of
+.I gnp
won't be set until the next statement.
.LP
-Next, we XDR the data in the node using the primitive
+Next, we XDR the data in the node using the primitive
.I xdr_reference ().
-.I xdr_reference()
-is like
-.I xdr_pointer()
+.I xdr_reference()
+is like
+.I xdr_pointer()
which we used before, but it does not
-send over the boolean indicating whether there is more data.
-We use it instead of
-.I xdr_pointer()
-because we have already XDR'd this information ourselves. Notice
-that the xdr routine passed is not the same type as an element
-in the list. The routine passed is
+send over the boolean indicating whether there is more data.
+We use it instead of
+.I xdr_pointer()
+because we have already XDR'd this information ourselves. Notice
+that the xdr routine passed is not the same type as an element
+in the list. The routine passed is
.I xdr_gnumbers (),
-for XDR'ing gnumbers, but each element in the list is actually of
-type
+for XDR'ing gnumbers, but each element in the list is actually of
+type
.I gnumbers_node .
-We don't pass
-.I xdr_gnumbers_node()
-because it is recursive, and instead use
-.I xdr_gnumbers()
-which XDR's all of the non-recursive part. Note that this trick
-will work only if the
-.I gn_numbers
-field is the first item in each element, so that their addresses
-are identical when passed to
+We don't pass
+.I xdr_gnumbers_node()
+because it is recursive, and instead use
+.I xdr_gnumbers()
+which XDR's all of the non-recursive part. Note that this trick
+will work only if the
+.I gn_numbers
+field is the first item in each element, so that their addresses
+are identical when passed to
.I xdr_reference ().
.LP
-Finally, we update
-.I gnp
-to point to the next item in the list. If the direction is
+Finally, we update
+.I gnp
+to point to the next item in the list. If the direction is
.I XDR_FREE ,
-we set it to the previously saved value, otherwise we can
-dereference
-.I gnp
-to get the proper value. Though harder to understand than the
+we set it to the previously saved value, otherwise we can
+dereference
+.I gnp
+to get the proper value. Though harder to understand than the
recursive version, this non-recursive routine is far less likely
to blow the C stack. It will also run more efficiently since
-a lot of procedure call overhead has been removed. Most lists
-are small though (in the hundreds of items or less) and the
+a lot of procedure call overhead has been removed. Most lists
+are small though (in the hundreds of items or less) and the
recursive version should be sufficient for them.
.EQ
delim off
diff --git a/lib/libc/rpc/rpc_svc_calls.3 b/lib/libc/rpc/rpc_svc_calls.3
index 1569d76..1118576 100644
--- a/lib/libc/rpc/rpc_svc_calls.3
+++ b/lib/libc/rpc/rpc_svc_calls.3
@@ -111,7 +111,7 @@ has global scope and ends all RPC server activity.
.Vt fd_set Va svc_fdset
.Xc
A global variable reflecting the
-RPC server's read file descriptor bit mask; it is suitable as a argument
+RPC server's read file descriptor bit mask; it is suitable as an argument
to the
.Xr select 2
system call.
diff --git a/lib/libc/stdlib/strtoimax.c b/lib/libc/stdlib/strtoimax.c
index ec66018..0cb387b 100644
--- a/lib/libc/stdlib/strtoimax.c
+++ b/lib/libc/stdlib/strtoimax.c
@@ -43,7 +43,7 @@ __FBSDID("$FreeBSD$");
#include <inttypes.h>
/*
- * Convert a string to a intmax_t integer.
+ * Convert a string to an intmax_t integer.
*
* Assumes that the upper and lower case
* alphabets and digits are each contiguous.
diff --git a/lib/libc/sys/socket.2 b/lib/libc/sys/socket.2
index a1c8122..65f74ac 100644
--- a/lib/libc/sys/socket.2
+++ b/lib/libc/sys/socket.2
@@ -203,7 +203,7 @@ by forcing transmissions
roughly every minute in the absence of other activity.
An error is then indicated if no response can be
elicited on an otherwise
-idle connection for a extended period (e.g. 5 minutes).
+idle connection for an extended period (e.g. 5 minutes).
A
.Dv SIGPIPE
signal is raised if a process sends
diff --git a/lib/libdisk/libdisk.h b/lib/libdisk/libdisk.h
index b3c5e08..fd7b4a5 100644
--- a/lib/libdisk/libdisk.h
+++ b/lib/libdisk/libdisk.h
@@ -294,7 +294,7 @@ __END_DECLS
/* TODO
*
- * Need a error string mechanism from the functions instead of warn()
+ * Need an error string mechanism from the functions instead of warn()
*
* Make sure only FreeBSD start at offset==0
*
diff --git a/lib/libedit/chared.h b/lib/libedit/chared.h
index 9d6c4ad..80606bb 100644
--- a/lib/libedit/chared.h
+++ b/lib/libedit/chared.h
@@ -52,7 +52,7 @@
#define EL_MAXMACRO 10
/*
- * This is a issue of basic "vi" look-and-feel. Defining VI_MOVE works
+ * This is an issue of basic "vi" look-and-feel. Defining VI_MOVE works
* like real vi: i.e. the transition from command<->insert modes moves
* the cursor.
*
diff --git a/lib/libedit/common.c b/lib/libedit/common.c
index f2d02e3..145f4b7 100644
--- a/lib/libedit/common.c
+++ b/lib/libedit/common.c
@@ -175,7 +175,7 @@ ed_delete_next_char(EditLine *el, int c)
return (CC_ERROR);
#else
term_overwrite(el, STReof, 4);
- /* then do a EOF */
+ /* then do an EOF */
term__flush();
return (CC_EOF);
#endif
diff --git a/lib/libedit/emacs.c b/lib/libedit/emacs.c
index 2e82f13..eff478d 100644
--- a/lib/libedit/emacs.c
+++ b/lib/libedit/emacs.c
@@ -61,7 +61,7 @@ em_delete_or_list(EditLine *el, int c)
/* if I'm at the end */
if (el->el_line.cursor == el->el_line.buffer) {
/* and the beginning */
- term_overwrite(el, STReof, 4); /* then do a EOF */
+ term_overwrite(el, STReof, 4); /* then do an EOF */
term__flush();
return (CC_EOF);
} else {
diff --git a/lib/libedit/vi.c b/lib/libedit/vi.c
index 34f781c..72de5c9 100644
--- a/lib/libedit/vi.c
+++ b/lib/libedit/vi.c
@@ -744,7 +744,7 @@ vi_list_or_eof(EditLine *el, int c)
if (el->el_line.cursor == el->el_line.lastchar &&
el->el_line.cursor == el->el_line.buffer) {
#endif
- term_overwrite(el, STReof, 4); /* then do a EOF */
+ term_overwrite(el, STReof, 4); /* then do an EOF */
term__flush();
return (CC_EOF);
#ifdef notyet
diff --git a/lib/libipsec/ipsec_set_policy.3 b/lib/libipsec/ipsec_set_policy.3
index 9c781a7..3d2f25c 100644
--- a/lib/libipsec/ipsec_set_policy.3
+++ b/lib/libipsec/ipsec_set_policy.3
@@ -77,7 +77,7 @@ Therefore,
can be regarded as inverse conversion of
.Fn ipsec_set_policy .
.Fa buf
-points to a IPsec policy structure,
+points to an IPsec policy structure,
.Li struct sadb_x_policy .
.Fa delim
is a delimiter string, which is usually a blank character.
diff --git a/lib/libnetgraph/sock.c b/lib/libnetgraph/sock.c
index 44af94f..d3bdf59 100644
--- a/lib/libnetgraph/sock.c
+++ b/lib/libnetgraph/sock.c
@@ -70,7 +70,7 @@ NgMkSockNode(const char *name, int *csp, int *dsp)
name = NULL;
/* Create control socket; this also creates the netgraph node.
- If we get a EPROTONOSUPPORT then the socket node type is
+ If we get an EPROTONOSUPPORT then the socket node type is
not loaded, so load it and try again. */
if ((cs = socket(AF_NETGRAPH, SOCK_DGRAM, NG_CONTROL)) < 0) {
if (errno == EPROTONOSUPPORT) {
diff --git a/lib/libvgl/vgl.3 b/lib/libvgl/vgl.3
index 96a7eb3..a5bdf8b 100644
--- a/lib/libvgl/vgl.3
+++ b/lib/libvgl/vgl.3
@@ -377,7 +377,7 @@ And
.Va object
must be
.Va VGLDisplay .
-Passing a in-memory bitmap to this function results in error.
+Passing an in-memory bitmap to this function results in error.
.Pp
The desired virtual screen width may not be achievable because
of the video card hardware. In such case the video driver (and
@@ -401,7 +401,7 @@ foreground.
.Va object
must be
.Va VGLDisplay .
-Passing a in-memory bitmap to this function results in error.
+Passing an in-memory bitmap to this function results in error.
.Pp
.Fn VGLBlankDisplay
blank the display if the argument
diff --git a/lib/msun/bsdsrc/b_log.c b/lib/msun/bsdsrc/b_log.c
index 101f8b1..75cd81e 100644
--- a/lib/msun/bsdsrc/b_log.c
+++ b/lib/msun/bsdsrc/b_log.c
@@ -442,7 +442,7 @@ log(x) double x;
/*
* Extra precision variant, returning struct {double a, b;};
- * log(x) = a+b to 63 bits, with a is rounded to 26 bits.
+ * log(x) = a+b to 63 bits, with a rounded to 26 bits.
*/
struct Double
#ifdef _ANSI_SOURCE
diff --git a/lib/msun/src/k_tan.c b/lib/msun/src/k_tan.c
index 7da811f..bb7770d 100644
--- a/lib/msun/src/k_tan.c
+++ b/lib/msun/src/k_tan.c
@@ -24,7 +24,7 @@ static char rcsid[] = "$FreeBSD$";
* Algorithm
* 1. Since tan(-x) = -tan(x), we need only to consider positive x.
* 2. if x < 2^-28 (hx<0x3e300000 0), return x with inexact if x!=0.
- * 3. tan(x) is approximated by a odd polynomial of degree 27 on
+ * 3. tan(x) is approximated by an odd polynomial of degree 27 on
* [0,0.67434]
* 3 27
* tan(x) ~ x + T1*x + ... + T13*x
OpenPOWER on IntegriCloud