NAME
FN_ref_addr_t, fn_ref_addr_create, fn_ref_addr_destroy,
fn_ref_addr_copy, fn_ref_addr_assign, fn_ref_addr_type,
fn_ref_addr_length, fn_ref_addr_data,
fn_ref_addr_description - an address in an XFN reference
SYNOPSIS
cc [ flag ... ] file ... -lxfn [ library ... ]
#include <xfn/xfn.h>
FN_ref_addr_t *fn_ref_addr_create(constFN_identifier_t
*type, size_t length, const void *data);
void fn_ref_addr_destroy(FN_ref_addr_t *addr);
FN_ref_addr_t *fn_ref_addr_copy(constFN_ref_addr_t *addr);
FN_ref_addr_t *fn_ref_addr_assign(FN_ref_addr_t *dst, const
FN_ref_addr_t *src);
const FN_identifier_t *fn_ref_addr_type(constFN_ref_addr_t
*addr);
size_t fn_ref_addr_length(const FN_ref_addr_t *addr);
const void* fn_ref_addr_data(const FN_ref_addr_t *addr);
FN_string_t *fn_ref_addr_description(constFN_ref_addr_t
*addr, unsigned int detail, unsigned int *more_detail);
DESCRIPTION
An XFN reference is represented by the type FN_ref_t. An
object of this type contains a reference type and a list of
addresses. Each address in the list is represented by an
object of type FN_ref_addr_t. An address consists of an
opaque data buffer and a type field, of type
FN_identifier_t.
fn_ref_addr_create() creates and returns an address with the
given type and data. length indicates the size of the data.
fn_ref_addr_destroy() releases the storage associated with
the given address. fn_ref_addr_copy() returns a copy of the
given address object. fn_ref_addr_assign() makes a copy of
the address pointed to by src and assigns it to dst, releas-
ing any old contents of dst. A pointer to the same object as
dst is returned.
fn_ref_addr_type() returns the type of the given address.
fn_ref_addr_length() returns the size of the address in
bytes. fn_ref_addr_data() returns the contents of the
address.
fn_ref_addr_description() returns the implementation-defined
textual description of the address. It takes as arguments a
number, detail, and a pointer to a number, more_detail.
detail specifies the level of detail for which the descrip-
tion should be generated; the higher the number, the more
detail is to be provided. If more_detail is 0, it is
ignored. If more_detail is non-zero, it is set by the
description operation to indicate the next level of detail
available, beyond that specified by detail. If no higher
level of detail is available, more_detail is set to
detail.
USAGE
The address type of an FN_ref_addr_t object is intended to
identify the mechanism that should be used to reach the
object using that address. The client must interpret the
contents of the opaque data buffer of the address based on
the type of the address, and on the type of the reference
that the address is in. However, this interpretation is
intended to occur below the application layer. Most appli-
cations developers should not have to manipulate the con-
tents of either address or reference objects themselves.
These interfaces would generally be used within service
libraries.
Multiple addresses in a single reference are intended to
identify multiple communication endpoints for the same con-
ceptual object. Multiple addresses may arise for various
reasons, such as the object offering interfaces over more
than one communication mechanism.
Manipulation of addresses using the operations described in
this manual page does not affect their representation in the
underlying naming system. Changes to addresses in the under-
lying naming system can only be effected through the use of
the interfaces described in FN_ctx_t(3XFN).
ATTRIBUTES
See attributes(5) for descriptions of the following attri-
butes:
____________________________________________________________
| ATTRIBUTE TYPE | ATTRIBUTE VALUE |
|_____________________________|_____________________________|
| MT-Level | MT-Safe |
|_____________________________|_____________________________|
SEE ALSO
FN_ctx_t(3XFN), FN_identifier_t(3XFN), FN_ref_t(3XFN),
FN_string_t(3XFN), xfn(3XFN), attributes(5)
NOTES
The implementation of XFN in this Solaris release is based
on the X/Open preliminary specification. It is likely that
there will be minor changes to these interfaces to reflect
changes in the final version of this specification. The next
minor release of Solaris will offer binary compatibility for
applications developed using the current interfaces. As the
interfaces evolve toward standardization, it is possible
that future releases of Solaris will require minor source
code changes to applications that have been developed
against the preliminary specification.
|
Закладки на сайте Проследить за страницей |
Created 1996-2025 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |