gno/usr.man/man2/intro.2

695 lines
26 KiB
Groff
Raw Normal View History

1997-02-27 07:32:31 +00:00
.\" Copyright (c) 1993, 1980198319861991
.\" The Regents of the University of California. All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\" must display the following acknowledgement:
.\" This product includes software developed by the University of
.\" California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\" may be used to endorse or promote products derived from this software
.\" without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\" @(#)intro.2 8.3 (Berkeley) 12/11/93
.\"
.TH INTRO 2 "29 January 1997" GNO "System Calls"
.SH NAME
.BR intro
\- introduction to system calls and error numbers
.SH SYNOPSIS
#include <sys/errno.h>
.SH DESCRIPTION
This section provides an overview of the GNO system calls,
their error returns, and other common definitions and concepts.
Some functions listed in this chapter are not actually implemented as
kernel traps, but have been listed as such because they would be
system calls on a traditional Unix system.
.LP
The
.BR SYNOPSIS
section of each manual page gives the prototype for the function(s)
described, along with a listing of the header files which provide
the prototypes. The sequence of header file inclusion may be important,
so they should be included in the sequence given.
.LP
The
.BR DESCRIPTION
section gives the detailed description of the system call.
.LP
Reference may be made to symbolic links or other features
or functions that are either unimplemented or otherwise unavailable
under GNO. This information has often been obtained from the original
BSD manual pages. In most cases such information has been retained
in the GNO manual pages either because such functionality is planned
or because the information is relevent to code intended to run on
other BSD operating systems.
.SH DIAGNOSTICS
Nearly all of the system calls provide an error number in the external
variable
.BR errno ,
which is defined as:
.RS
.LP
extern int \fBerrno\fR;
.LP
.RE
When a system call detects an error,
it returns an integer value
indicating failure (usually -1)
and sets the variable
.BR errno
accordingly. (This allows interpretation of the failure on receiving
a -1 and to take action accordingly.)
Successful calls never set
.BR errno ;
once set, it remains until another error occurs.
It should only be examined after an error.
Note that a number of system calls overload the meanings of these
error numbers, and that the meanings must be interpreted according
to the type and circumstances of the call.
.LP
The following is a complete list of the errors used in GNO and their
names as given in <sys/errno.h>. The first twelve (up to
.BR ENOSPC )
are also used by the ORCA/Shell.
.RS
.IP "\fBENOERR\fR -- Error 0"
Not used.
.IP "\fBEDOM\fR -- Numerical argument out of domain"
A numerical input argument was outside the defined domain of the mathematical
function.
.IP "\fBERANGE\fR -- Numerical result out of range"
A numerical result of the function was too large to fit in the
available space (perhaps exceeded precision).
.IP "\fBENOMEM\fR -- Cannot allocate memory"
The new process image required more memory than was allowed by the hardware
or by system-imposed memory management constraints.
.IP "\fBENOENT\fR -- No such file or directory"
A component of a specified pathname did not exist, or the
pathname was an empty string.
.IP "\fBEIO\fR -- Input/output error"
Some physical input or output error occurred.
.sp 1
Any GS/OS errors that occur and which do not have any other suitable
.BR errno
counterparts will be mapped to this error.
.IP "\fBEINVAL\fR -- Invalid argument"
Some invalid argument was supplied. (For example,
specifying an undefined signal to a
.BR signal
or
.BR kill
function).
.IP "\fBEBADF\fR -- Bad file descriptor"
A file descriptor argument was out of range, referred to no open file,
or a read (write) request was made to a file that was only open for
writing (reading).
.IP "\fBEMFILE\fR -- Too many open files"
(The limit on the number of
open files per process is 32. This is configurable under some versions
of Unix, but not under GNO.)
.BR Getdtablesize (2)
will obtain the current limit.
.IP "\fBEACCES\fR -- Permission denied"
An attempt was made to access a file in a way forbidden
by its file access permissions.
.sp 1
The default Orca/C header files use
.BR EACCESS
(with two
.BR S \'s)
for this macro, but GNO does not since it causes a conflict with
standard macros in the <arpa/tftp.h> header.
.IP "\fBEEXIST\fR -- File exists"
An existing file was mentioned in an inappropriate context.
.IP "\fBENOSPC\fR -- Device out of space"
A
.BR write
to an ordinary file, the creation of a
directory or symbolic link, or the creation of a directory
entry failed because no more disk blocks were available
on the file system, or (for filesystems using inodes)
the allocation of an inode for a newly
created file failed because no more inodes were available
on the file system.
.IP "\fBEPERM\fR -- Operation not permitted"
An attempt was made to perform an operation limited to processes
with appropriate privileges or to the owner of a file or other
resources.
.IP "\fBESRCH\fR -- No such process"
No process could be found corresponding to that specified by the given
process ID.
.IP "\fBEINTR\fR -- Interrupted function call"
An asynchronous signal (such as
.BR SIGINT
or
.BR SIGQUIT )
was caught by the process during the execution of an interruptible
function. If the signal handler performs a normal return, the
interrupted function call will seem to have returned the error condition.
.IP "\fBE2BIG\fR -- Arg list too long"
The number of bytes used for the argument and environment
list of the new process exceeded the current limit
of 4096 bytes (NCARGS in <sys/param.h>).
.IP "\fBENOEXEC\fR -- Exec format error"
A request was made to execute a file
that, although it has the appropriate permissions,
was not in the format required for an
executable file.
.IP "\fBECHILD\fR -- \&No child processes"
A
.BR wait
or
.BR waitpid
function was executed by a process that had no existing or unwaited-for
child processes.
.IP "\fBEAGAIN\fR -- Resource temporarily unavailable"
This is a temporary condition and later calls to the
same routine may complete normally.
.IP "\fBENOTDIR\fR -- Not a directory"
A component of the specified pathname existed, but it was
not a directory, when a directory was expected.
.IP "\fBENOTTY\fR -- Inappropriate ioctl for device"
A control function (see
.BR ioctl (2))
was attempted for a file or
special device for which the operation was inappropriate.
.IP "\fBEPIPE\fR -- Broken pipe"
A write on a pipe, socket or
.BR FIFO
for which there is no process
to read the data.
.IP "\fBESPIPE\fR -- Illegal seek"
An
.BR lseek
function was issued on a socket, pipe or
.BR FIFO .
.IP "\fBENOTBLK\fR -- Not a block device"
A block device operation was attempted on a non-block device or file.
.IP "\fBEISDIR\fR -- Is a directory"
An attempt was made to open a directory with write mode specified.
.IP "\fBENOTSOCK\fR -- Socket operation on non-socket"
Self-explanatory.
.IP "\fBEDESTADDRREQ\fR -- Destination address required"
A required address was omitted from an operation on a socket.
.IP "\fBEMSGSIZE\fR -- Message too long"
A message sent on a socket was larger than the internal message buffer
or some other network limit.
.IP "\fBEPROTOTYPE\fR -- Protocol wrong type for socket"
A protocol was specified that does not support the semantics of the
socket type requested. For example, you cannot use the
.BR ARPA
Internet
.BR UDP
protocol with type
.BR SOCK_STREAM .
.IP "\fBENOPROTOOPT\fR -- Protocol not available"
A bad option or level was specified in a
.BR getsockopt (2)
or
.BR setsockopt (2)
call.
.IP "\fBEPROTONOSUPPORT\fR -- Protocol not supported"
The protocol has not been configured into the
system or no implementation for it exists.
.IP "\fBESOCKTNOSUPPORT\fR -- Socket type not supported"
The support for the socket type has not been configured into the
system or no implementation for it exists.
.IP "\fBEOPNOTSUPP\fR -- Operation not supported"
The attempted operation is not supported for the type of object referenced.
Usually this occurs when a file descriptor refers to a file or socket
that cannot support this operation,
for example, trying to
.IR accept
a connection on a datagram socket.
.IP "\fBEPFNOSUPPORT\fR -- Protocol family not supported"
The protocol family has not been configured into the
system or no implementation for it exists.
.IP "\fBEAFNOSUPPORT\fR -- Address family not supported by protocol family"
An address incompatible with the requested protocol was used.
For example, you shouldn't necessarily expect to be able to use
.BR NS
addresses with
.BR ARPA
Internet protocols.
.IP "\fBEADDRINUSE\fR -- Address already in use"
Only one usage of each address is normally permitted.
.IP "\fBEADDRNOTAVAIL\fR -- Cannot assign requested address"
Normally results from an attempt to create a socket with an
address not on this machine.
.IP "\fBENETDOWN\fR -- Network is down"
A socket operation encountered a dead network.
.IP "\fBENETUNREACH\fR -- Network is unreachable"
A socket operation was attempted to an unreachable network.
.IP "\fBENETRESET\fR -- Network dropped connection on reset"
The host you were connected to crashed and rebooted.
.IP "\fBECONNABORTED\fR -- Software caused connection abort"
A connection abort was caused internal to your host machine.
.IP "\fBECONNRESET\fR -- Connection reset by peer"
A connection was forcibly closed by a peer. This normally
results from a loss of the connection on the remote socket
due to a timeout or a reboot.
.IP "\fBENOBUFS\fR -- \&No buffer space available"
An operation on a socket or pipe was not performed because
the system lacked sufficient buffer space or because a queue was full.
.IP "\fBEISCONN\fR -- Socket is already connected"
A
.BR connect
request was made on an already connected socket; or,
a
.BR sendto
or
.BR sendmsg
request on a connected socket specified a destination
when already connected.
.IP "\fBENOTCONN\fR -- Socket is not connected"
An request to send or receive data was disallowed because
the socket was not connected and (when sending on a datagram socket)
no address was supplied.
.IP "\fBESHUTDOWN\fR -- Cannot send after socket shutdown"
A request to send data was disallowed because the socket
had already been shut down with a previous
.BR shutdown (2)
call.
.IP "\fBETIMEDOUT\fR -- Operation timed out"
A
.BR connect
or
.BR send
request failed because the connected party did not
properly respond after a period of time. (The timeout
period is dependent on the communication protocol.)
.IP "\fBECONNREFUSED\fR -- Connection refused"
No connection could be made because the target machine actively
refused it. This usually results from trying to connect
to a service that is inactive on the foreign host.
.IP "\fBEWOULDBLOCK\fR -- Operation would block"
An operation was attempted on a non-blocking file descriptor that
would cause the calling process to block.
.IP "\fBEINPROGRESS\fR -- Operation now in progress"
An operation that takes a long time to complete (such as
a
.BR connect (2))
was attempted on a non-blocking object (see
.BR fcntl (2)).
.IP "\fBEALREADY\fR -- Operation already in progress"
An operation was attempted on a non-blocking object that already
had an operation in progress.
.IP "\fBEFAULT\fR -- Bad address"
The system detected an invalid address in attempting to
use an argument of a call.
.IP "\fBENODEV\fR -- Operation not supported by device"
An attempt was made to apply an inappropriate
function to a device,
for example,
trying to read a write-only device such as a printer.
.IP "\fBEHOSTDOWN\fR -- Host is down"
A socket operation failed because the destination host was down.
.IP "\fBEHOSTUNREACH\fR -- No route to host"
A socket operation was attempted to an unreachable host.
.RE
.LP
The following errors may be present in various BSD sources, but are
not currently used in GNO:
.LP
.RS
.IP "\fBENXIO\fR -- \&No such device or address"
Input or output on a special file referred to a device that did not
exist, or
made a request beyond the limits of the device.
This error may also occur when, for example,
a tape drive is not online or no disk pack is
loaded on a drive.
.IP "\fBEDEADLK\fR -- Resource deadlock avoided"
An attempt was made to lock a system resource that
would have resulted in a deadlock situation.
.IP "\fBEBUSY\fR -- Resource busy"
An attempt to use a system resource which was in use at the time
in a manner which would have conflicted with the request.
.IP "\fBEXDEV\fR -- Improper link"
A hard link to a file on another file system
was attempted.
.IP "\fBENFILE\fR -- Too many open files in system"
Maximum number of file descriptors allowable on the system
has been reached and a requests for an open cannot be satisfied
until at least one has been closed.
.IP "\fBETXTBSY\fR -- Text file busy"
The new process was a pure procedure (shared text) file
which was open for writing by another process, or
while the pure procedure file was being executed an
.BR open
call requested write access.
.IP "\fBEFBIG\fR -- File too large"
The size of a file exceeded the maximum (about
.if t 2\u\s-231\s+2\d
.if n 2.1E9
bytes).
.IP "\fBEROFS\fR -- Read-only file system"
An attempt was made to modify a file or directory
was made
on a file system that was read-only at the time.
.IP "\fBEMLINK\fR -- Too many links"
Maximum allowable hard links to a single file has been exceeded (limit
of 32767 hard links per file).
.IP "\fBELOOP\fR -- Too many levels of symbolic links"
A path name lookup involved more than 8 symbolic links.
.IP "\fBENAMETOOLONG\fR -- File name too long"
A component of a path name exceeded 255 (MAXNAMELEN)
characters, or an entire path name exceeded 1023 (MAXPATHLEN-1) characters.
.IP "\fBENOTEMPTY\fR -- Directory not empty"
A directory with entries other than
.BR \&.
and
.BR \&..
was supplied to a remove directory or rename call.
.IP "\fBEPROCLIM\fR -- Too many processes"
.IP "\fBEUSERS\fR -- Too many users"
The quota system ran out of table entries.
.IP "\fBEDQUOT\fR -- Disc quota exceeded"
A
.BR write
to an ordinary file, the creation of a
directory or symbolic link, or the creation of a directory
entry failed because the user's quota of disk blocks was
exhausted, or the allocation of an inode for a newly
created file failed because the user's quota of inodes
was exhausted.
.IP "\fBESTALE\fR -- Stale NFS file handle"
An attempt was made to access an open file (on an
.BR NFS
filesystem)
which is now unavailable as referenced by the file descriptor.
This may indicate the file was deleted on the
.BR NFS
server or some
other catastrophic event occurred.
.IP "\fBEBADRPC\fR -- RPC struct is bad"
Exchange of
.BR RPC
information was unsuccessful.
.IP "\fBERPCMISMATCH\fR -- RPC version wrong"
The version of
.BR RPC
on the remote peer is not compatible with
the local version.
.IP "\fBEPROGUNAVAIL\fR -- RPC prog. not avail"
The requested program is not registered on the remote host.
.IP "\fBEPROGMISMATCH\fR -- Program version wrong"
The requested version of the program is not available
on the remote host
.BR RPC .
.IP "\fBEPROCUNAVAIL\fR -- Bad procedure for program"
An
.BR RPC
call was attempted for a procedure which doesn't exist
in the remote program.
.IP "\fBENOLCK\fR -- No locks available"
A system-imposed limit on the number of simultaneous file
locks was reached.
.IP "\fBENOSYS\fR -- Function not implemented"
Attempted a system call that is not available on this
system.
.RE
.SH DEFINITIONS
.IP "\fBProcess ID\fR"
Each active process in the system is uniquely identified by a non-negative
integer called a process ID. The range of this ID is from 0 to 30000.
.IP "\fBParent process ID\fR"
A new process is created by a currently active process; (see
.BR fork (2)).
The parent process ID of a process is initially the process ID of its creator.
If the creating process exits,
the parent process ID of each child is set to the ID of a system process,
.BR init .
.IP "\fBProcess Group\fR"
Each active process is a member of a process group that is identified by
a non-negative integer called the process group ID. This is the process
ID of the group leader. This grouping permits the signaling of related
processes (see
.BR termios (4))
and the job control mechanisms of
.BR csh (1).
.IP \fBSession\fR
A session is a set of one or more process groups.
A session is created by a successful call to
.BR setsid (2),
which causes the caller to become the only member of the only process
group in the new session.
.IP "\fBSession leader\fR"
A process that has created a new session by a successful call to
.BR setsid (2),
is known as a session leader.
Only a session leader may acquire a terminal as its controlling terminal (see
.BR termios (4)).
.IP "\fBControlling process\fR"
A session leader with a controlling terminal is a controlling process.
.IP "\fBControlling terminal\fR"
A terminal that is associated with a session is known as the controlling
terminal for that session and its members.
.IP "\fBTerminal Process Group ID\fR"
A terminal may be acquired by a session leader as its controlling terminal.
Once a terminal is associated with a session, any of the process groups
within the session may be placed into the foreground by setting
the terminal process group ID to the ID of the process group.
This facility is used
to arbitrate between multiple jobs contending for the same terminal;
(see
.BR csh (1)
and
.BR tty (4)).
.IP "\fBOrphaned Process Group\fR"
A process group is considered to be
.IR orphaned
if it is not under the control of a job control shell.
More precisely, a process group is orphaned
when none of its members has a parent process that is in the same session
as the group,
but is in a different process group.
Note that when a process exits, the parent process for its children
is changed to be
.BR init ,
which is in a separate session.
Not all members of an orphaned process group are necessarily orphaned
processes (those whose creating process has exited).
The process group of a session leader is orphaned by definition.
.IP "\fBReal User ID\fR and \fBReal Group ID\fR"
Each user on the system is identified by a positive integer
termed the real user ID.
.sp 1
Each user is also a member of one or more groups.
One of these groups is distinguished from others and
used in implementing accounting facilities. The positive
integer corresponding to this distinguished group is termed
the real group ID.
.sp 1
All processes have a real user ID and real group ID.
These are initialized from the equivalent attributes
of the process that created it.
.IP "\fBEffective User Id, Effective Group Id\fR, and \fBGroup Access List\fR"
Access to system resources is governed by two values:
the effective user ID, and the group access list.
The first member of the group access list is also known as the
effective group ID.
(In POSIX.1, the group access list is known as the set of supplementary
group IDs, and it is unspecified whether the effective group ID is
a member of the list.)
.sp 1
The effective user ID and effective group ID are initially the
process's real user ID and real group ID respectively. Either
may be modified through execution of a set-user-ID or set-group-ID
file (possibly by one its ancestors) (see
.BR execve (2)).
By convention, the effective group ID (the first member of the group access
list) is duplicated, so that the execution of a set-group-ID program
does not result in the loss of the original (real) group ID.
.sp 1
The group access list is a set of group IDs
used only in determining resource accessibility. Access checks
are performed as described below in ``File Access Permissions''.
.IP "\fBSaved Set User ID\fR and \fBSaved Set Group ID\fR"
When a process executes a new file, the effective user ID is set
to the owner of the file if the file is set-user-ID, and the effective
group ID (first element of the group access list) is set to the group
of the file if the file is set-group-ID.
The effective user ID of the process is then recorded as the saved set-user-ID,
and the effective group ID of the process is recorded as the saved set-group-ID.
These values may be used to regain those values as the effective user
or group ID after reverting to the real ID (see
.BR setuid (2)).
(In POSIX.1, the saved set-user-ID and saved set-group-ID are optional,
and are used in setuid and setgid, but this does not work as desired
for the super-user.)
.IP \fBSuper-user\fR
A process is recognized as a
.IR super-user
process and is granted special privileges if its effective user ID is 0.
.IP "\fBSpecial Processes\fR"
The processes with process IDs of 0, 1, and 2 are special.
Process 0 is the scheduler. Process 1 is the initialization process
.BR init ,
and is the ancestor of every other process in the system.
It is used to control the process structure.
Process 2 is the paging daemon.
.IP \fBDescriptor\fR
An integer assigned by the system when a file is referenced
by
.BR open (2)
or
.BR dup (2),
or when a socket is created by
.BR pipe (2),
.BR socket (2)
or
.BR socketpair (2),
which uniquely identifies an access path to that file or socket from
a given process or any of its children.
.IP "\fBFile Name\fR"
names consisting of up to 255 (MAXNAMELEN)
characters may be used to name
an ordinary file, special file, or directory.
.sp 1
These characters may be selected from the set of all
.BR ASCII
character
excluding 0 (NUL) and the
.BR ASCII
code for
.BR \&/
(slash). (The parity bit,
bit 7, must be 0.)
.sp 1
Note that it is generally unwise to use
.BR \&* ,
.BR \&? ,
.BR \&[
or
.BR \&]
as part of
file names because of the special meaning attached to these characters
by the shell.
.IP "\fBPath Name\fR"
A path name is a
.BR NULL \-terminated
character string starting with an
optional slash
.BR \&/ ,
followed by zero or more directory names separated
by slashes, optionally followed by a file name.
The total length of a path name must be less than 1024 (MAXPATHLEN)
characters.
.sp 1
If a path name begins with a slash, the path search begins at the
.IR root
directory.
Otherwise, the search begins from the current working directory.
A slash by itself names the root directory. An empty
pathname refers to the current directory.
.IP \fBDirectory\fR
A directory is a special type of file that contains entries
that are references to other files.
Directory entries are called links. By convention, a directory
contains at least two links,
.BR \&.
and
.BR \&.. ,
referred to as
.IR dot
and
.IR dot-dot
respectively. Dot refers to the directory itself and
dot-dot refers to its parent directory.
.IP "\fBRoot Directory\fR and \fBCurrent Working Directory\fR"
Each process has associated with it a concept of a root directory
and a current working directory for the purpose of resolving path
name searches. A process's root directory need not be the root
directory of the root file system.
.IP "\fBFile Access Permissions\fR"
Every file in the file system has a set of access permissions.
These permissions are used in determining whether a process
may perform a requested operation on the file (such as opening
a file for writing). Access permissions are established at the
time a file is created. They may be changed at some later time
through the
.BR chmod (2)
call.
.sp 1
File access is broken down according to whether a file may be: read,
written, or executed. Directory files use the execute
permission to control if the directory may be searched.
.sp 1
File access permissions are interpreted by the system as
they apply to three different classes of users: the owner
of the file, those users in the file's group, anyone else.
Every file has an independent set of access permissions for
each of these classes. When an access check is made, the system
decides if permission should be granted by checking the access
information applicable to the caller.
.sp 1
Read, write, and execute/search permissions on
a file are granted to a process if:
.sp 1
The process's effective user ID is that of the super-user. (Note:
even the super-user cannot execute a non-executable file.)
.sp 1
The process's effective user ID matches the user ID of the owner
of the file and the owner permissions allow the access.
.sp 1
The process's effective user ID does not match the user ID of the
owner of the file, and either the process's effective
group ID matches the group ID
of the file, or the group ID of the file is in
the process's group access list,
and the group permissions allow the access.
.sp 1
Neither the effective user ID nor effective group ID
and group access list of the process
match the corresponding user ID and group ID of the file,
but the permissions for ``other users'' allow access.
.sp 1
Otherwise, permission is denied.
.IP "\fBSockets\fR and \fBAddress Families\fR"
.sp 1
A socket is an endpoint for communication between processes.
Each socket has queues for sending and receiving data.
.sp 1
Sockets are typed according to their communications properties.
These properties include whether messages sent and received
at a socket require the name of the partner, whether communication
is reliable, the format used in naming message recipients, etc.
.sp 1
Each instance of the system supports some
collection of socket types; consult
.BR socket (2)
for more information about the types available and
their properties.
.sp 1
Each instance of the system supports some number of sets of
communications protocols. Each protocol set supports addresses
of a certain format. An Address Family is the set of addresses
for a specific group of protocols. Each socket has an address
chosen from the address family in which the socket was created.
.SH SEE ALSO
.BR intro(3) ,
.BR perror (3),
the
.IR "GNO Kernel Reference Manual" .