xdr_admin(3N)xdr_admin(3N)NAME
xdr_admin, xdr_control, xdr_getpos, xdr_inline, xdrrec_endofrecord,
xdrrec_eof, xdrrec_readbytes, xdrrec_skiprecord, xdr_setpos, xdr_sizeof
- library routines for external data representation
SYNOPSISDESCRIPTION
XDR 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 specifically with the management of the XDR stream.
Routines
See rpc(3N) for the definition of the data structure. Note that 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.
A function macro to change or retrieve various information
about an XDR stream. req indicates the type of operation and
info is a pointer to the information. The supported value of
req is and its argument type is It returns the number of bytes
left unconsumed in the stream and a flag indicating whether or
not this is the last fragment.
A macro that invokes the get-position routine
associated with the XDR stream, xdrs. The routine returns an
unsigned integer, which indicates the position of the XDR byte
stream. A desirable feature of XDR streams is that simple
arithmetic works with this number, although the XDR stream
instances need not guarantee this. Therefore, applications
written for portability should not depend on this feature.
A macro that invokes the in-line routine associated with the XDR
stream, xdrs. The routine returns a pointer to a contiguous
piece of the stream's buffer; len is the byte length of the
desired buffer. Note: pointer is cast to
Warning: may return NULL if it cannot allocate a contiguous
piece of a buffer. Therefore the behavior may vary among stream
instances; it exists for the sake of efficiency, and applica‐
tions written for portability should not depend on this feature.
This routine can be invoked only on streams created by
(see xdr_create(3N)). The data in the output buffer is marked
as a completed record, and the output buffer is optionally writ‐
ten out if sendnow is non-zero. This routine returns if it suc‐
ceeds, otherwise.
This routine can be invoked only on streams created by
After consuming the rest of the current record in the stream,
this routine returns if there is no more data in the stream's
input buffer. It returns if there is additional data in the
stream's input buffer.
This routine can be invoked only on streams created by
It attempts to read nbytes bytes from the XDR stream into the
buffer pointed to by addr. Upon success this routine returns
the number of bytes read, on failure. A return value of indi‐
cates an end of record.
This routine can be invoked only on streams created by
(see xdr_create(3N)). It tells the XDR implementation that the
rest of the current record in the stream's input buffer should
be discarded. This routine returns if it succeeds, otherwise.
A macro that invokes the set position routine associated with the
XDR stream, xdrs. The parameter pos is a position value
obtained from This routine returns if the XDR stream was reposi‐
tioned, and otherwise.
Warning: it is difficult to reposition some types of XDR
streams, so this routine may fail with one type of stream and
succeed with another. Therefore, applications written for
portability should not depend on this feature.
This routine returns the number of bytes required to
encode
data using the XDR filter function func, excluding potential
overhead such as RPC headers or record markers. (zero) is
returned on error. This information might be used to select
between transport protocols, or to determine the buffer size for
various lower levels of RPC client and server creation routines,
or to allocate storage when XDR is used outside of the RPC sub‐
system.
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 and before These functions should not
be called by a multithreaded application that supports asynchronous
cancellation or asynchronous signals.
SEE ALSOmalloc(3C), rpc(3N), xdr_complex(3N), xdr_create(3N), xdr_simple(3N).
xdr_admin(3N)
