получить настраиваемые системные переменные (get configurable system variables)
Обоснование (Rationale)
This functionality was added in response to requirements of
application developers and of system vendors who deal with many
international system configurations. It is closely related to
pathconf() and fpathconf().
Although a conforming application can run on all systems by never
demanding more resources than the minimum values published in
this volume of POSIX.1‐2017, it is useful for that application to
be able to use the actual value for the quantity of a resource
available on any given system. To do this, the application makes
use of the value of a symbolic constant in <limits.h> or
<unistd.h>.
However, once compiled, the application must still be able to
cope if the amount of resource available is increased. To that
end, an application may need a means of determining the quantity
of a resource, or the presence of an option, at execution time.
Two examples are offered:
1. Applications may wish to act differently on systems with or
without job control. Applications vendors who wish to
distribute only a single binary package to all instances of a
computer architecture would be forced to assume job control
is never available if it were to rely solely on the
<unistd.h> value published in this volume of POSIX.1‐2017.
2. International applications vendors occasionally require
knowledge of the number of clock ticks per second. Without
these facilities, they would be required to either distribute
their applications partially in source form or to have 50 Hz
and 60 Hz versions for the various countries in which they
operate.
It is the knowledge that many applications are actually
distributed widely in executable form that leads to this
facility. If limited to the most restrictive values in the
headers, such applications would have to be prepared to accept
the most limited environments offered by the smallest
microcomputers. Although this is entirely portable, there was a
consensus that they should be able to take advantage of the
facilities offered by large systems, without the restrictions
associated with source and object distributions.
During the discussions of this feature, it was pointed out that
it is almost always possible for an application to discern what a
value might be at runtime by suitably testing the various
functions themselves. And, in any event, it could always be
written to adequately deal with error returns from the various
functions. In the end, it was felt that this imposed an
unreasonable level of complication and sophistication on the
application developer.
This runtime facility is not meant to provide ever-changing
values that applications have to check multiple times. The values
are seen as changing no more frequently than once per system
initialization, such as by a system administrator or operator
with an automatic configuration program. This volume of
POSIX.1‐2017 specifies that they shall not change within the
lifetime of the process.
Some values apply to the system overall and others vary at the
file system or directory level. The latter are described in
fpathconf(3p).
Note that all values returned must be expressible as integers.
String values were considered, but the additional flexibility of
this approach was rejected due to its added complexity of
implementation and use.
Some values, such as {PATH_MAX}, are sometimes so large that they
must not be used to, say, allocate arrays. The sysconf() function
returns a negative value to show that this symbolic constant is
not even defined in this case.
Similar to pathconf(), this permits the implementation not to
have a limit. When one resource is infinite, returning an error
indicating that some other resource limit has been reached is
conforming behavior.
