 |
» |
|
|
|
NAMExdr_create, xdr_destroy, xdrmem_create, xdrrec_create, xdrstdio_create — library routines for external data representation stream creation SYNOPSIS#include <rpc/xdr.h>
void xdr_destroy(XDR *xdrs);
void xdrmem_create(XDR *xdrs,
const caddr_t addr,
const u_int size,
const enum xdr_op op);
void xdrrec_create(XDR *xdrs,
const u_int sendsz,
const u_int recvsz,
const caddr_t handle,
const int (*readit)(
const void *read_handle,
char *buf,
const int len),
const int (*writeit)(
const void *write_handle,
const char *buf,
const int len));
void xdrstdio_create(XDR *xdrs,
FILE *file,
const enum xdr_op op); DESCRIPTIONXDR library routines allow C programmers to describe
arbitrary data structures in a machine-independent fashion.
Protocols such as remote procedure calls (RPC)
use these routines to describe the format of the data. These routines deal with the creation of XDR streams.
XDR streams have to be created before any data can be translated into
XDR format. RoutinesSee
rpc(3N)
for the definition of the
XDR,
CLIENT,
and
SVCXPRT
data structures.
Any buffers passed to the XDR routines must be properly aligned.
It is suggested either that
malloc(3C)
be used to allocate these buffers or that the programmer insure
that the buffer address is divisible evenly by four.
- void xdr_destroy()
A macro that invokes the destroy routine associated with the
XDR stream,
xdrs.
Private data structures associated with the stream are freed.
Using
xdrs
after invoking
xdr_destroy()
is undefined. - void xdrmem_create()
This routine initializes the XDR stream object pointed to by
xdrs.
The stream's data is written to or read from a chunk of memory
at location
addr
whose length is no less than
size
bytes long.
The parameter
op
determines the direction of the XDR stream.
The value of
op
can be either
XDR_ENCODE,
XDR_DECODE,
or
XDR_FREE.
In the case where the value of
size
exceeds
INT_MAX,
xdrmem_create()
resets
size
to
INT_MAX. - void xdrrec_create()
This routine initializes the read-oriented XDR
stream object pointed to by
xdrs.
The stream's data is written to a buffer of size
sendsz;
a value of
0
indicates the system should use a suitable default.
The stream's data is read from a buffer of size
recvsz;
it too can be set to a suitable default by passing a
0
value.
When a stream's output buffer is full,
writeit
is called.
Similarly, when a stream's input buffer is empty,
readit
is called.
The behavior of these two routines is similar to the system calls
read()
and
write()
(see
read(2)
and
write(2),
respectively),
except that an appropriate handle
(read_handle
or
write_handle)
is passed to the former routines as the first parameter
instead of a file descriptor.
The XDR stream's
op
field must be set by the caller. Warning: this XDR stream implements an intermediate record stream.
Therefore there are additional bytes in the stream
to provide record boundary information. - void xdrstdio_create()
This routine initializes the XDR stream object pointed to by
xdrs.
The XDR stream data is written to or read from the standard
I/O stream
file.
The parameter
op
determines the direction of the XDR stream.
The value of
op
can be either
XDR_ENCODE,
XDR_DECODE,
or
XDR_FREE. Warning: the destroy routine associated with such XDR streams calls
fflush()
on the
file
stream, but never
fclose()
(see
fclose(3S)).
Failure of the
xdrrec_create()
function can be detected by first initializing the
x_ops
field in the
XDR
structure
(xdrs→x_ops)
to NULL
before calling the
xdrrec_create()
function.
After the return from the
xdrrec_create()
function, if the
x_ops
field is still NULL,
the call has failed.
If the
x_ops
field contains some other value, assume the call has succeeded.
Failures cannot be detected for the
xdrmem_create()
and
xdrstdio_create()
functions. MULTITHREAD USAGE- Thread Safe:
Yes - Cancel Safe:
Yes - Fork Safe:
No - Async-cancel Safe:
No - Async-signal Safe:
No
These functions can be called safely in a multithreaded environment.
They may be cancellation points in that they call functions that are
cancel points. In a multithreaded environment, these functions are
not safe to be called by a child process after
fork()
and before
exec().
These functions should not be called by a multithreaded application
that supports asynchronous cancellation or asynchronous signals. |
Printable version
