The following terms are used in this document:
The implementor shall document such a value or behavior so that it can be used correctly by an application.
To avoid ambiguity, the opposite of may is expressed as need not, instead of may not.
For an application, describes a feature or behavior that is recommended programming practice for optimum portability.
The value or behavior may vary among implementations that conform to this document. An application should not rely on the existence or validity of the value or behavior. An application that relies on any particular value or behavior cannot be assured to be portable across conforming implementations.
The value or behavior may vary among implementations that conform to this document. An application should not rely on the existence or validity of the value or behavior. An application that relies on any particular value or behavior cannot be assured to be portable across conforming implementations.
For backward compatibility purposes, any of the function names within
the header file may be redefined by the implementation, using
the pre-processor "#define" mechanism (or any other similar
compiler supported mechanism) to another function name.
If redefined, the function name so defined will be in accordance with
the name space rules in
As a result of changes in this issue of this document, application writers are only required to include the minimum number of headers. Implementations of XSI-conformant systems will make all necessary symbols visible as described in the Headers section of this document.
The _XOPEN_SOURCE macro may be defined automatically by the
compilation process, but to ensure maximum portability, applications
should make sure that _XOPEN_SOURCE is defined by using either
compiler options or
#define
directives in the source files, before any
#include
directives. Identifiers in this document may be undefined using the
#undef
directive as described in
Since this specification is aligned with the ISO C standard, and since all functionality enabled by _POSIX_C_SOURCE set greater than zero and less than or equal to 199506L should be enabled by _XOPEN_SOURCE set greater than or equal to 500, there should be no need to define either _POSIX_SOURCE or _POSIX_C_SOURCE if _XOPEN_SOURCE is defined. Therefore if _XOPEN_SOURCE is set greater than or equal to 500 and _POSIX_SOURCE is defined, or _POSIX_C_SOURCE is set greater than zero and less than or equal to 199506L, the behavior is the same as if only _XOPEN_SOURCE is defined and set greater than or equal to 500. However, should _POSIX_C_SOURCE be set to a value greater than 199506L, the behaviour is undefined.
The c89 and cc utilities defined in the referenced XCU specification recognise the additional -l operand for standard libraries:
It is unspecified whether the library libxnet.a exists as a regular file.
If the implementation supports the utilities marked DEVELOPMENT in the XCU specification, the lint utility recognises the additional -l operand for standard libraries:
It is unspecified whether the library llib-lxnet.ln exists as a regular file.
The identifiers reserved for use by the implementation are described below.
If any header in the following table is included, identifiers with the following prefixes or suffixes shown are reserved for any use by the implementation.
Header | Prefix | Suffix |
---|---|---|
<arpa/inet.h> | in_, inet_ | |
<netdb.h> | h_, n_, p_, s_ | |
<net/if.h> | if_ | |
<netinet/in.h> | in_, ip_, s_, sin_ | |
<sys/socket.h> | _ss, sa_, if_, ifc_, ifru_, infu_, ifra_, msg_, cmsg_, l_ | |
<sys/un.h> | sun_ | |
ANY header | _t |
When the optional XTI is supported, identifiers with the following prefixes are reserved for any use by the implementation:
Header | Prefix |
---|---|
<xti.h> | l_, t_, T_ |
If any header in the following table is included, macros with the prefixes shown may be defined. After the last inclusion of a given header, an application may use identifiers with the corresponding prefixes for its own purpose, provided their use is preceded by an #undef of the corresponding macro.
Header | Prefix |
---|---|
<net/if.h> | IF_ |
<netinet/in.h> | IMPLINK_, IN_, INADDR_, IP_, IPPORT_, IPPROTO_, SOCK_ |
<netinet/tcp.h> | TCP_ |
<sys/socket.h> | AF_, CMSG_, MSG_, PF_, SCM_, SHUT_, SO |
When the optional XTI is supported, identifiers with the following prefixes are reserved for any use by the implementation:
Header | Prefix |
---|---|
<xti.h> | OPT_, T_1, XTI_ |
The following identifiers are reserved regardless of the inclusion of headers:
Sockets: | ||||
accept
bind connect getpeername getsockname | getsockopt
if_freenameindex if_indextoname if_nameindex if_nametoindex | listen
recv recvfrom recvmsg send | sendmsg
sendto setsockopt shutdown socket | socketpair |
IP Address Resolution: | ||||
endhostent
endnetent endprotoent endservent getaddrinfo gethostbyaddr gethostbyname gethostent | gethostname
getipnodebyaddr getipnodebyname getnameinfo getnetbyaddr getnetbyname getnetent getprotobyname | getprotobynumber
getprotoent getservbyname getservbyport getservent h_errno htonl htons | inet_addr
inet_lnaof inet_makeaddr inet_netof inet_network inet_ntoa ntohl ntohs | sethostent setnetent setprotoent setservent |
XTI - the following symbols are only reserved when optional XTI is supported: | ||||
t_accept
t_alloc t_bind t_close t_connect t_errno t_error t_free | t_getinfo
t_getprotaddr t_getstate t_listen t_look t_open t_optmgmt | t_rcv
t_rcvconnect t_rcvdis t_rcvrel t_rcvreldata t_rcvudata t_rcvuderr | t_rcvv
t_rcvvudata t_snd t_snd t_snddis t_sndrel t_sndreldata | t_sndudata
t_sndv t_sndvudata t_strerror t_sync t_sysconf t_unbind |
All the identifiers defined in this document that have external linkage are always reserved for use as identifiers with external linkage.
No other identifiers are reserved.
Applications must not declare or define identifiers with the same name as an identifier reserved in the same context. Since macro names are replaced whenever found, independent of scope and name space, macro names matching any of the reserved identifier names must not be defined if any associated header is included.
Headers may be included in any order, and each may be included more than once in a given scope, with no difference in effect from that of being included only once.
If used, a header must be included outside of any external declaration or definition, and it must be first included before the first reference to any type or macro it defines, or to any function or object it declares. However, if an identifier is declared or defined in more than one header, the second and subsequent associated headers may be included after the initial reference to the identifier. Prior to the inclusion of a header, the program must not define any macros with names lexically identical to symbols defined by that header.
A list of valid values for errno and advice to application writers on the use of errno appears in the XSH specification.
A cancellation point may also occur when a thread is executing any of the following functions:
An implementation will not introduce cancellation points into any other function specified in this document.
See the referenced XSH, Section 2.8 for further information.
Contents | Next section | Index |