[ новости /+++ | форум | теги | ]

NAME
     fn_ctx_rename - rename the name of a binding

SYNOPSIS
     cc [ flag ... ] file ... -lxfn [ library ... ]
     #include <xfn/xfn.h>

     int fn_ctx_rename(FN_ctx_t *ctx,  const  FN_composite_name_t
     *oldname,  const  FN_composite_name_t *newname, unsigned int
     exclusive, FN_status_t *status);

DESCRIPTION
     The fn_ctx_rename() operation binds the reference  currently
     bound  to  oldname relative to ctx, to the name newname, and
     unbinds oldname. newname is resolved relative to the  target
     context  (that  named by all but the terminal atomic part of
     oldname).

     If exclusive is 0, the operation overwrites any old  binding
     of newname.  If exclusive is nonzero, the operation fails if
     newname is already bound.

RETURN VALUES
     fn_ctx_rename() returns 1 if the operation is successful,  0
     otherwise.

ERRORS
     fn_ctx_rename() sets status as  described  FN_status_t(3XFN)
     and xfn_status_codes(3XFN).

USAGE
     The only restriction that XFN places on newname is  that  it
     be  resolved  relative  to  the target context. XFN does not
     specify further restrictions on  newname.  For  example,  in
     some  implementations,  newname  might be restricted to be a
     name in the same naming system as the terminal component  of
     oldname.  In  another  implementation, newname might be res-
     tricted to be an atomic name.

     Normal   resolution   always   follows    links.    In    an
     fn_ctx_rename()  operation,  resolution of oldname continues
     to the target context;  the  terminal  atomic  name  is  not
     resolved.  If  the  terminal atomic name is bound to a link,
     the link is not followed and the operation binds  newname to
     the link and unbinds the terminal atomic name of oldname.

     In naming systems that  support  attributes  and  store  the
     attributes  along with the names, the unbind of the terminal
     atomic name of oldname also removes  its  associated  attri-
     butes.   It is implementation-dependent whether these attri-
     butes become associated with newname.

ATTRIBUTES
     See attributes(5) for descriptions of the  following  attri-
     butes:

     ____________________________________________________________
    |       ATTRIBUTE TYPE        |       ATTRIBUTE VALUE       |
    |_____________________________|_____________________________|
    | MT-Level                    | MT-Safe                     |
    |_____________________________|_____________________________|


SEE ALSO
     FN_composite_name_t(3XFN),  FN_ctx_t(3XFN),  FN_ref_t(3XFN),
     FN_status_t(3XFN),   fn_ctx_bind(3XFN)  fn_ctx_unbind(3XFN),
     xfn(3XFN), xfn_status_codes(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.

Партнёры:

Хостинг: