Museum

Home

Lab Overview

Retrotechnology Articles

Online Manuals

⇒ stdipc(3C) — Reliant UNIX 5.44c4

Media Vault

Software Library

Restoration Projects

Artifacts Sought

Related Articles

msgget(2)

semget(2)

shmget(2)

stat(2)

makedev(3C)

ipc(5)

types(5)

stdipc(3C)                                                       stdipc(3C)

NAME
     stdipc: ftok - standard interprocess communication package

SYNOPSIS
     #include <sys/types.h>
     #include <sys/ipc.h>

     keyt ftok(const char *path, int id);

DESCRIPTION
     All interprocess communication facilities require the user to supply a
     key to be used by the msgget(2), semget(2), and shmget(2) system calls
     to obtain interprocess communication identifiers. One possible way of
     forming a key is to use the ftok() subroutine. Another way to compose
     keys is to include the project ID in the most significant byte and to
     use the remaining portion as a sequence number. There are many other
     ways to form keys, but it is necessary for each system to define stan-
     dards for forming them. If some standard is not adhered to, it will be
     possible for unrelated processes to unintentionally interfere with
     each other's operation. It is possible with all types of key resolu-
     tion that two processes will coincidentally still use the same key.
     The user should therefore ensure that the most significant byte of a
     key in some sense refers to a project so that keys do not conflict
     across a given system.

     ftok() returns a key based on path and id that is usable in subsequent
     msgget(), semget(), and shmget() system calls. path must be the path
     name of an existing file that is accessible to the process. id is a
     character that uniquely identifies a project. Note that ftok() will
     return the same key for linked files when called with the same id and
     that it will return different keys when called with the same filename
     but different id identifiers.

     The key is made up of the id, the minor number [cf. makedev(3C)] and
     the inode of the path. Only the eight low-order bits of the id and the
     minor number are significant. Only the sixteen low-order bits of the
     inode are significant. The behavior of ftok() is unspecified if these
     bits are 0.

RESULT
     ftok() returns (keyt)-1 if path does not exist or if it is not acces-
     sible to the process.

ERRORS
     The following error code descriptions are function-specific. You will
     find a general description in introprm2(2) or in errno(5).

     The ftok() function will fail if:

     EACCES        Search permission is denied for a component of the path
                   prefix.




Page 1                       Reliant UNIX 5.44                Printed 11/98

stdipc(3C)                                                       stdipc(3C)

     ELOOP         Too many symbolic links were encountered in resolving
                   path.

     ENAMETOOLONG  The length of the path argument exceeds PATHMAX or a
                   pathname component is longer than NAMEMAX.

     ENOENT        A component of path does not name an existing file or
                   path is an empty string.

     ENOTDIR       A component of the path prefix is not a directory.

     The ftok() function may fail if:

     ENAMETOOLONG  Pathname resolution of a symbolic link produced an
                   intermediate result whose length exceeds PATHMAX.

NOTES
     If the file whose path is passed to ftok() is removed when keys still
     refer to the file, future calls to ftok() with the same path and id
     will return an error. If the same file is recreated, then ftok() is
     likely to return a different key than it did the original time it was
     called.

SEE ALSO
     msgget(2), semget(2), shmget(2), stat(2), makedev(3C), ipc(5),
     types(5).




























Page 2                       Reliant UNIX 5.44                Printed 11/98

Typewritten Software • bear@typewritten.org • Edmonds, WA 98026