General Concepts
<<<
Previous
Next
>>>
The Open Group Base Specifications Issue 7, 2018 edition
IEEE Std 1003.1-2017 (Revision of IEEE Std 1003.1-2008)
Copyright © 2001-2018 IEEE and The Open Group
A newer edition of this document exists
here
4.
General Concepts
For the purposes of POSIX.1-2017, the general concepts given in
General Concepts
apply.
Note:
No shading to denote extensions or options occurs in this chapter. Where the terms and definitions given in this chapter are
used elsewhere in text related to extensions and options, they are shaded as appropriate.
4.1
Concurrent Execution
Functions that suspend the execution of the calling thread shall not cause the execution of other threads to be indefinitely
suspended.
4.2
Default Initialization
Default initialization causes an object to be initialized according to these rules:
If it has pointer type, it is initialized to a null pointer.
If it has arithmetic type, it is initialized to (positive or unsigned) zero.
If it is an aggregate, every member is initialized (recursively) according to these rules.
If it is a union, the first named member is initialized (recursively) according to these rules.
For an object of aggregate type with an explicit initializer, the initialization shall occur in initializer list order, each
initializer provided for a particular subobject overriding any previously listed initializer for the same subobject; all subobjects
that are not initialized explicitly shall be initialized implicitly according to the rules for default initialization.
Objects with static storage duration but no explicit initializer shall be initialized implicitly according to the rules for
default initialization.
An explicit initializer of
{ 0 }
works to perform explicit default initialization for any object of scalar or aggregate
type, and for any storage duration.
Notes:
The ISO C standard does not require a compiler to set any field alignment padding bits in a structure or array definition
to a particular value. Because of this, a structure initialized using
{ 0 }
might not
memcmp
()
as equal to the same structure initialized using
memset
()
to zero. For consistent results, portable applications comparing structures should
test each field individually.
If an implementation treats the all-zero bit pattern of a pointer object as a null pointer, and the all-zero bit pattern of a
floating-point object as equivalent to positive 0, then
memset
()
to zero and
calloc
()
have the same effects as default initialization for all named members of a
structure.
MX
Implementations that define __STDC_IEC_559__ guarantee that the all-zero bit pattern of a floating-point object
represents 0.0.
4.3
Directory Protection
If a directory is writable and the mode bit S_ISVTX is set on the directory, a process may remove or rename files within that
directory only if one or more of the following is true:
The effective user ID of the process is the same as that of the owner ID of the file.
The effective user ID of the process is the same as that of the owner ID of the directory.
The process has appropriate privileges.
Optionally, the file is writable by the process. Whether or not files that are writable by the process can be removed or renamed
is implementation-defined.
If the S_ISVTX bit is set on a non-directory file, the behavior is unspecified.
4.4
Extended Security Controls
An implementation may provide implementation-defined extended security controls (see
Extended Security Controls
). These permit an implementation to provide security
mechanisms to implement different security policies than those described in POSIX.1-2017. These mechanisms shall not alter or
override the defined semantics of any of the interfaces in POSIX.1-2017.
4.5
File Access Permissions
The standard file access control mechanism uses the file permission bits, as described below.
Implementations may provide
additional
or
alternate
file access control mechanisms, or both. An additional access
control mechanism shall only further restrict the access permissions defined by the file permission bits. An alternate file access
control mechanism shall:
Specify file permission bits for the file owner class, file group class, and file other class of that file, corresponding to the
access permissions.
Be enabled only by explicit user action, on a per-file basis by the file owner or a user with appropriate privileges.
Be disabled for a file after the file permission bits are changed for that file with
chmod
()
. The disabling of the alternate mechanism need not disable any additional mechanisms
supported by an implementation.
Whenever a process requests file access permission for read, write, or execute/search, if no additional mechanism denies access,
access shall be determined as follows:
If a process has appropriate privileges:
If read, write, or directory search permission is requested, access shall be granted.
If execute permission is requested, access shall be granted if execute permission is granted to at least one user by the file
permission bits or by an alternate access control mechanism; otherwise, access shall be denied.
Otherwise:
The file permission bits of a file contain read, write, and execute/search permissions for the file owner class, file group
class, and file other class.
Access shall be granted if an alternate access control mechanism is not enabled and the requested access permission bit is set
for the class (file owner class, file group class, or file other class) to which the process belongs, or if an alternate access
control mechanism is enabled and it allows the requested access; otherwise, access shall be denied.
4.6
File Hierarchy
Files in the system are organized in a hierarchical structure in which all of the non-terminal nodes are directories and all of
the terminal nodes are any other type of file. Since multiple directory entries may refer to the same file, the hierarchy is
properly described as a "directed graph".
4.7
Filenames
Uppercase and lowercase letters shall retain their unique identities between conforming implementations.
4.8
Filename Portability
For a filename to be portable across implementations conforming to POSIX.1-2017, it shall consist only of the portable filename
character set as defined in
Portable Filename Character Set
Note:
Applications should avoid using filenames that have the
cause problems when filenames are passed as command line arguments.
4.9
File Times Update
Many operations have requirements to update file timestamps. These requirements do not apply to streams that have no underlying
file description (for example, memory streams created by
open_memstream
()
have no underlying file description).
Each file has three distinct associated timestamps: the time of last data access, the time of last data modification, and the
time the file status last changed. These values are returned in the file characteristics structure
struct stat
, as described
in
Each function or utility in POSIX.1-2017 that reads or writes data (even if the data does not change) or performs an operation
to change file status (even if the file status does not change) indicates which of the appropriate timestamps shall be marked for
update. If an implementation of such a function or utility marks for update one of these timestamps in a place or time not
specified by POSIX.1-2017, this shall be documented, except that any changes caused by pathname resolution need not be documented.
For the other functions or utilities in POSIX.1-2017 (those that are not explicitly required to read or write file data or change
file status, but that in some implementations happen to do so), the effect is unspecified.
An implementation may update timestamps that are marked for update immediately, or it may update such timestamps periodically.
At the point in time when an update occurs, any marked timestamps shall be set to the current time and the update marks shall be
cleared. All timestamps that are marked for update shall be updated when the file ceases to be open by any process or before a
fstat
()
fstatat
()
fsync
()
futimens
()
lstat
()
stat
()
utime
()
utimensat
()
, or
utimes
()
is successfully performed on the file. Other times at which updates are done are
unspecified. Marks for update, and updates themselves, shall not be done for files on read-only file systems; see
Read-Only File System
The resolution of timestamps of files in a file system is implementation-defined, but shall be no coarser than one-second
resolution. The three timestamps shall always have values that are supported by the file system. Whenever any of a file's
timestamps are to be set to a value
according to the rules of the preceding paragraphs of this section, the implementation
shall immediately set the timestamp to the greatest value supported by the file system that is not greater than
4.10
Host and Network Byte Orders
When data is transmitted over the network, it is sent as a sequence of octets (8-bit unsigned values). If an entity (such as an
address or a port number) can be larger than 8 bits, it needs to be stored in several octets. The convention is that all such
values are stored with 8 bits in each octet, and with the first (lowest-addressed) octet holding the most-significant bits. This is
called "network byte order".
Network byte order may not be convenient for processing actual values. For this, it is more sensible for values to be stored as
ordinary integers. This is known as "host byte order". In host byte order:
The most significant bit might not be stored in the first byte in address order.
Bits might not be allocated to bytes in any obvious order at all.
8-bit values stored in
uint8_t
objects do not require conversion to or from host byte order, as they have the same
representation. 16 and 32-bit values can be converted using the
htonl
()
htons
()
ntohl
()
, and
ntohs
()
functions. When reading data that is to be converted to host byte order, it should
either be received directly into a
uint16_t
or
uint32_t
object or should be copied from an array of bytes using
memcpy
()
or similar. Passing the data through other types could cause the byte order to
be changed. Similar considerations apply when sending data.
4.11
Measurement of Execution Time
The mechanism used to measure execution time shall be implementation-defined. The implementation shall also define to whom the
CPU time that is consumed by interrupt handlers and system services on behalf of the operating system will be charged. See
CPU Time (Execution Time)
4.12
Memory Synchronization
Applications shall ensure that access to any memory location by more than one thread of control (threads or processes) is
restricted such that no thread of control can read or modify a memory location while another thread of control may be modifying it.
Such access is restricted using functions that synchronize thread execution and also synchronize memory with respect to other
threads. The following functions synchronize memory with respect to other threads:
fork
()
pthread_barrier_wait
()
pthread_cond_broadcast
()
pthread_cond_signal
()
pthread_cond_timedwait
()
pthread_cond_wait
()
pthread_create
()
pthread_join
()
pthread_mutex_lock
()
pthread_mutex_timedlock
()
pthread_mutex_trylock
()
pthread_mutex_unlock
()
pthread_spin_lock
()
pthread_spin_trylock
()
pthread_spin_unlock
()
pthread_rwlock_rdlock
()
pthread_rwlock_timedrdlock
()
pthread_rwlock_timedwrlock
()
pthread_rwlock_tryrdlock
()
pthread_rwlock_trywrlock
()
pthread_rwlock_unlock
()
pthread_rwlock_wrlock
()
sem_post
()
sem_timedwait
()
sem_trywait
()
sem_wait
()
semctl
()
semop
()
wait
()
waitpid
()
The
pthread_once
()
function shall synchronize memory for the first call in
each thread for a given
pthread_once_t
object. If the
init_routine
called by
pthread_once
()
is a cancellation point and is canceled, a call to
pthread_once
()
for the same
pthread_once_t
object made from a cancellation
cleanup handler shall also synchronize memory.
The
pthread_mutex_lock
()
function need not synchronize memory if the
mutex type if PTHREAD_MUTEX_RECURSIVE and the calling thread already owns the mutex. The
pthread_mutex_unlock
()
function need not synchronize memory if the mutex type
is PTHREAD_MUTEX_RECURSIVE and the mutex has a lock count greater than one.
Unless explicitly stated otherwise, if one of the above functions returns an error, it is unspecified whether the invocation
causes memory to be synchronized.
Applications may allow more than one thread of control to read a memory location simultaneously.
4.13
Pathname Resolution
Pathname resolution is performed for a process to resolve a pathname to a particular directory entry for a file in the file
hierarchy. There may be multiple pathnames that resolve to the same directory entry, and multiple directory entries for the same
file. When a process resolves a pathname of an existing directory entry, the entire pathname shall be resolved as described below.
When a process resolves a pathname of a directory entry that is to be created immediately after the pathname is resolved, pathname
resolution terminates when all components of the path prefix of the last component have been resolved. It is then the
responsibility of the process to create the final component.
Each filename in the pathname is located in the directory specified by its predecessor (for example, in the pathname fragment
a/b
, file
is located in directory
). Pathname resolution shall fail if this cannot be accomplished. If the
pathname begins with a
of the process (such pathnames are referred to as "absolute pathnames"). If the pathname does not begin with a
predecessor of the first filename of the pathname shall be taken to be either the current working directory of the process or for
certain interfaces the directory identified by a file descriptor passed to the interface (such pathnames are referred to as
"relative pathnames").
The interpretation of a pathname component is dependent on the value of {NAME_MAX} and _POSIX_NO_TRUNC associated with the path
prefix of that component. If any pathname component is longer than {NAME_MAX}, the implementation shall consider this an error.
A pathname that contains at least one non-
characters shall not be resolved successfully unless the last pathname component before the trailing
an existing directory or a directory entry that is to be created for a directory immediately after the pathname is resolved.
Interfaces using pathname resolution may specify additional constraints
when a
pathname that does not name an existing directory contains at least one non-
trailing
If a symbolic link is encountered during pathname resolution, the behavior shall depend on whether the pathname component is at
the end of the pathname and on the function being performed. If all of the following are true, then pathname resolution is
complete:
This is the last pathname component of the pathname.
The pathname has no trailing
The function is required to act on the symbolic link itself, or certain arguments direct that the function act on the symbolic
link itself.
In all other cases, the system shall prefix the remaining pathname, if any, with the contents of the symbolic link, except that
if the contents of the symbolic link is the empty string, then either pathname resolution shall fail with functions reporting an
[ENOENT] error and utilities writing an equivalent diagnostic message, or the pathname of the directory containing the symbolic
link shall be used in place of the contents of the symbolic link. If the contents of the symbolic link consist solely of
combined pathname, leaving only the leading
occurs, if the combined length exceeds {PATH_MAX}, and the implementation considers this to be an error, pathname resolution shall
fail with functions reporting an [ENAMETOOLONG] error and utilities writing an equivalent diagnostic message. Otherwise, the
resolved pathname shall be the resolution of the pathname just created. If the resulting pathname does not begin with a
If the system detects a loop in the pathname resolution process, pathname resolution shall fail with functions reporting an
[ELOOP] error and utilities writing an equivalent diagnostic message. The same may happen if during the resolution process more
symbolic links were followed than the implementation allows. This implementation-defined limit shall not be smaller than
{SYMLOOP_MAX}.
The special filename dot shall refer to the directory specified by its predecessor. The special filename dot-dot shall refer to
the parent directory of its predecessor directory. As a special case, in the root directory, dot-dot may refer to the root
directory itself.
A pathname consisting of a single
successfully resolved. If a pathname begins with two successive
characters shall be treated as a single
Pathname resolution for a given pathname shall yield the same results when used by any interface in POSIX.1-2017 as long as
there are no changes to any files evaluated during pathname resolution for the given pathname between resolutions.
4.14
Process ID Reuse
A process group ID shall not be reused by the system until the process group lifetime ends.
A process ID shall not be reused by the system until the process lifetime ends. In addition, if there exists a process group
whose process group ID is equal to that process ID, the process ID shall not be reused by the system until the process group
lifetime ends. A process that is not a system process shall not have a process ID of 1.
4.15
Scheduling Policy
A scheduling policy affects process or thread ordering:
When a process or thread is a running thread and it becomes a blocked thread
When a process or thread is a running thread and it becomes a preempted thread
When a process or thread is a blocked thread and it becomes a runnable thread
When a running thread calls a function that can change the priority or scheduling policy of a process or thread
In other scheduling policy-defined circumstances
Conforming implementations shall define the manner in which each of the scheduling policies may modify the priorities or
otherwise affect the ordering of processes or threads at each of the occurrences listed above. Additionally, conforming
implementations shall define in what other circumstances and in what manner each scheduling policy may modify the priorities or
affect the ordering of processes or threads.
4.16
Seconds Since the Epoch
A value that approximates the number of seconds that have elapsed since the Epoch. A Coordinated Universal Time name (specified
in terms of seconds (
tm_sec
), minutes (
tm_min
), hours (
tm_hour
), days since January 1 of the year
tm_yday
), and calendar year minus 1900 (
tm_year
)) is related to a time represented as seconds since the Epoch,
according to the expression below.
If the year is <1970 or the value is negative, the relationship is undefined. If the year is >=1970 and the value is
non-negative, the value is related to a Coordinated Universal Time name according to the C-language expression, where
tm_sec
tm_min
tm_hour
tm_yday
, and
tm_year
are all integer types:
tm_sec
tm_min
*60 +
tm_hour
*3600 +
tm_yday
*86400 +
tm_year
-70)*31536000 + ((
tm_year
-69)/4)*86400 -
((
tm_year
-1)/100)*86400 + ((
tm_year
+299)/400)*86400
The relationship between the actual time of day and the current value for seconds since the Epoch is unspecified.
How any changes to the value of seconds since the Epoch are made to align to a desired relationship with the current actual time
is implementation-defined. As represented in seconds since the Epoch, each and every day shall be accounted for by exactly 86400
seconds.
Note:
The last three terms of the expression add in a day for each year that follows a leap year starting with the first leap year
since the Epoch. The first term adds a day every 4 years starting in 1973, the second subtracts a day back out every 100 years
starting in 2001, and the third adds a day back in every 400 years starting in 2001. The divisions in the formula are integer
divisions; that is, the remainder is discarded leaving only the integer quotient.
4.17
Semaphore
A minimum synchronization primitive to serve as a basis for more complex synchronization mechanisms to be defined by the
application program.
For the semaphores associated with the Semaphores option, a semaphore is represented as a shareable resource that has a
non-negative integer value. When the value is zero, there is a (possibly empty) set of threads awaiting the availability of the
semaphore.
For the semaphores associated with the X/Open System Interfaces (XSI) option, a semaphore is a positive integer (0 through
32767). The
semget
()
function can be called to create a set or array of semaphores. A
semaphore set can contain one or more semaphores up to an implementation-defined value.
Semaphore Lock Operation
An operation that is applied to a semaphore. If, prior to the operation, the value of the semaphore is zero, the semaphore lock
operation shall cause the calling thread to be blocked and added to the set of threads awaiting the semaphore; otherwise, the value
shall be decremented.
Semaphore Unlock Operation
An operation that is applied to a semaphore. If, prior to the operation, there are any threads in the set of threads awaiting
the semaphore, then some thread from that set shall be removed from the set and becomes unblocked; otherwise, the semaphore value
shall be incremented.
4.18
Thread-Safety
Refer to XSH
Threads
4.19
Tracing
The trace system allows a traced process to have a selection of events created for it. Traces consist of streams of trace event
types.
A trace event type is identified on the one hand by a trace event type name, also referenced as a trace event name, and on the
other hand by a trace event type identifier. A trace event name is a human-readable string. A trace event type identifier is an
opaque identifier used by the trace system. There shall be a one-to-one relationship between trace event type identifiers and trace
event names for a given trace stream and also for a given traced process. The trace event type identifier shall be generated
automatically from a trace event name by the trace system either when a trace controller process invokes
posix_trace_trid_eventid_open
()
or when an instrumented application
process invokes
posix_trace_eventid_open
()
. Trace event type
identifiers are used to filter trace event types, to allow interpretation of user data, and to identify the kind of trace point
that generated a trace event.
Each trace event shall be of a particular trace event type, and associated with a trace event type identifier. The execution of
a trace point shall generate a trace event if a trace stream has been created and started for the process that executed the trace
point and if the corresponding trace event type identifier is not ignored by filtering.
A generated trace event shall be recorded in a trace stream, and optionally also in a trace log if a trace log is associated
with the trace stream, except that:
For a trace stream, if no resources are available for the event, the event is lost.
For a trace log, if no resources are available for the event, or a flush operation does not succeed, the event is lost.
A trace event recorded in an active trace stream may be retrieved by an application having appropriate privileges.
A trace event recorded in a trace log may be retrieved by an application having appropriate privileges after opening the trace
log as a pre-recorded trace stream, with the function
posix_trace_open
()
When a trace event is reported it is possible to retrieve the following:
A trace event type identifier
A timestamp
The process ID of the traced process, if the trace event is process-dependent
Any optional trace event data including its length
If the Threads option is supported, the thread ID, if the trace event is process-dependent
The program address at which the trace point was invoked
Trace events may be mapped from trace event types to trace event names. One such mapping shall be associated with each trace
stream. An active trace stream is associated with a traced process, and also with its children if the Trace Inherit option is
supported and also the inheritance policy is set to _POSIX_TRACE_INHERIT. Therefore each traced process has a mapping of the trace
event names to trace event type identifiers that have been defined for that process.
Traces can be recorded into either trace streams or trace logs.
The implementation and format of a trace stream are unspecified. A trace stream need not be and generally is not persistent. A
trace stream may be either active or pre-recorded:
An active trace stream is a trace stream that has been created and has not yet been shut down. It can be of one of the two
following classes:
An active trace stream without a trace log that was created with the
posix_trace_create
()
function
If the Trace Log option is supported, an active trace stream with a trace log that was created with the
posix_trace_create_withlog
()
function
A pre-recorded trace stream is a trace stream that was opened from a trace log object using the
posix_trace_open
()
function.
An active trace stream can loop. This behavior means that when the resources allocated by the trace system for the trace stream
are exhausted, the trace system reuses the resources associated with the oldest recorded trace events to record new trace
events.
If the Trace Log option is supported, an active trace stream with a trace log can be flushed. This operation causes the trace
system to write trace events from the trace stream to the associated trace log, following the defined policies or using an explicit
function call. After this operation, the trace system may reuse the resources associated with the flushed trace events.
An active trace stream with or without a trace log can be cleared. This operation shall cause all the resources associated with
this trace stream to be reinitialized. The trace stream shall behave as if it was returning from its creation, except that the
mapping of trace event type identifiers to trace event names shall not be cleared. If a trace log was associated with this trace
stream, the trace log shall also be reinitialized.
A trace log shall be recorded when the
posix_trace_shutdown
()
operation is invoked or during tracing, depending on the tracing strategy which is defined by a log policy. After the trace stream
has been shut down, the trace information can be retrieved from the associated trace log using the same interface used to retrieve
information from an active trace stream.
For a traced process, if the Trace Inherit option is supported and the trace stream's inheritance attribute is
_POSIX_TRACE_INHERIT, the initial targeted traced process shall be traced together with all of its future children. The
posix_pid
member of each trace event in a trace stream shall be the process ID of the traced process.
Each trace point may be an implementation-defined action such as a context switch, or an application-programmed action such as a
call to a specific operating system service (for example,
fork
()
) or a call to
posix_trace_event
()
Trace points may be filtered. The operation of the filter is to filter out (ignore) selected trace events. By default, no trace
events are filtered.
The results of the tracing operations can be analyzed and monitored by a trace controller process or a trace analyzer
process.
Only the trace controller process has control of the trace stream it has created. The control of the operation of a trace stream
is done using its corresponding trace stream identifier. The trace controller process is able to:
Initialize the attributes of a trace stream
Create the trace stream
Start and stop tracing
Know the mapping of the traced process
If the Trace Event Filter option is supported, filter the type of trace events to be recorded
Shut the trace stream down
A traced process may also be a trace controller process. Only the trace controller process can control its trace stream(s). A
trace stream created by a trace controller process shall be shut down if its controller process terminates or executes another
file.
A trace controller process may also be a trace analyzer process. Trace analysis can be done concurrently with the traced process
or can be done off-line, in the same or in a different platform.
4.20
Treatment of Error Conditions for Mathematical Functions
For all the functions in the
header, an application wishing to check
for error situations should set
errno
to 0 and call
feclearexcept
(FE_ALL_EXCEPT) before calling the function. On
return, if
errno
is non-zero or
fetestexcept
( FE_INVALID | FE_DIVBYZERO | FE_OVERFLOW | FE_UNDERFLOW) is non-zero, an
error has occurred.
On implementations that support the IEC 60559 Floating-Point option, whether or when functions in the
header raise an undeserved underflow floating-point exception is unspecified.
Otherwise, as implied by XSH
feraiseexcept
, the
functions do not raise spurious floating-point exceptions (detectable by the
user), other than the inexact floating-point exception.
The following error conditions are defined for all functions in the
header.
4.20.1
Domain Error
A "domain error" shall occur if an input argument is outside the domain over which the mathematical function is defined. The
description of each function lists any required domain errors; an implementation may define additional domain errors, provided that
such errors are consistent with the mathematical definition of the function.
On a domain error, the function shall return an implementation-defined value; if the integer expression (math_errhandling &
MATH_ERRNO) is non-zero,
errno
shall be set to [EDOM]; if the integer expression (math_errhandling & MATH_ERREXCEPT) is
non-zero, the "invalid" floating-point exception shall be raised.
4.20.2
Pole Error
A "pole error" occurs if the mathematical result of the function is an exact infinity (for example, log(0.0)).
On a pole error, the function shall return the value of the macro HUGE_VAL, HUGE_VALF, or HUGE_VALL according to the return
type, with the same sign as the correct value of the function; if the integer expression (math_errhandling & MATH_ERRNO) is
non-zero,
errno
shall be set to [ERANGE]; if the integer expression (math_errhandling & MATH_ERREXCEPT) is non-zero, the
"divide-by-zero" floating-point exception shall be raised.
4.20.3
Range Error
A "range error" shall occur if the finite mathematical result of the function cannot be represented in an object of the
specified type, due to extreme magnitude.
Result Overflows
A floating result overflows if the magnitude of the mathematical result is finite but so large that the mathematical result
cannot be represented without extraordinary roundoff error in an object of the specified type. If a floating result overflows and
default rounding is in effect, then the function shall return the value of the macro HUGE_VAL, HUGE_VALF, or HUGE_VALL according to
the return type, with the same sign as the correct value of the function; if the integer expression (math_errhandling &
MATH_ERRNO) is non-zero,
errno
shall be set to [ERANGE]; if the integer expression (math_errhandling & MATH_ERREXCEPT)
is non-zero, the "overflow" floating-point exception shall be raised.
Result Underflows
The result underflows if the magnitude of the mathematical result is so small that the mathematical result cannot be
represented, without extraordinary roundoff error, in an object of the specified type. If the result underflows, the function shall
return an implementation-defined value whose magnitude is no greater than the smallest normalized positive number in the specified
type; if the integer expression (math_errhandling & MATH_ERRNO) is non-zero, whether
errno
is set to [ERANGE] is
implementation-defined; if the integer expression (math_errhandling & MATH_ERREXCEPT) is non-zero, whether the "underflow''
floating-point exception is raised is implementation-defined.
4.21
Treatment of NaN Arguments for the Mathematical Functions
For functions called with a NaN argument, no errors shall occur and a NaN shall be returned, except where stated otherwise.
If a function with one or more NaN arguments returns a NaN result, the result should be the same as one of the NaN arguments
(after possible type conversion), except perhaps for the sign.
On implementations that support the IEC 60559:1989 standard floating point, functions with signaling NaN argument(s) shall
be treated as if the function were called with an argument that is a required domain error and shall return a quiet NaN result,
except where stated otherwise.
Note:
The function might never see the signaling NaN, since it might trigger when the arguments are evaluated during the function
call.
On implementations that support the IEC 60559:1989 standard floating point, for those functions that do not have a
documented domain error, the following shall apply:
These functions shall fail if:
Domain Error
Any argument is a signaling NaN.
Either, the integer expression (math_errhandling & MATH_ERRNO) is non-zero and
errno
shall be set to [EDOM], or the
integer expression (math_errhandling & MATH_ERREXCEPT) is non-zero and the invalid floating-point exception shall be
raised.
4.22
Utility
A utility program shall be either an executable file, such as might be produced by a compiler or linker system from computer
source code, or a file of shell source code, directly interpreted by the shell. The program may have been produced by the user,
provided by the system implementor, or acquired from an independent distributor.
The system may implement certain utilities as shell functions (see XCU
Function Definition Command
) or built-in utilities, but only an application
that is aware of the command search order (as described in XCU
Command
Search and Execution
) or of performance characteristics can discern differences between the behavior of such a function or
built-in utility and that of an executable file.
4.23
Variable Assignment
In the shell command language, a word consisting of the following parts:
varname
value
When used in a context where assignment is defined to occur and at no other time, the
value
(representing a word or
field) shall be assigned as the value of the variable denoted by
varname
Note:
For further information, see XCU
Simple Commands
The
varname
and
value
parts shall meet the requirements for a name and a word, respectively, except that they are
delimited by the embedded unquoted
Note:
Additional delimiters are described in XCU
Token Recognition
When a variable assignment is done, the variable shall be created if it did not already exist. If
value
is not specified,
the variable shall be given a null value.
Note:
An alternative form of variable assignment:
symbol
value
(where
symbol
is a valid word delimited by an
The form
symbol
value
is used by the KornShell
name
expression
]=
value
syntax.
Footnotes
1.
The only interfaces that further constrain pathnames in POSIX.1-2017 are the
rename
()
and
renameat
()
functions (see XSH
rename
) and the
mv
utility (see XCU
mv
).
return to top of page
UNIX ® is a registered Trademark of The Open Group.
POSIX ™ is a Trademark of The IEEE.
Copyright © 2001-2018 IEEE and The Open Group, All Rights Reserved
Main Index
XBD
XSH
XCU
XRAT
<<<
Previous
Next
>>>
US