Notes |
(0005209)
geoffclare (manager)
2021-01-26 09:39
|
The <limits.h> page contains these paragraphs before the list of limits that includes {OPEN_MAX}:A definition of one of the symbolic constants in the following list shall be omitted from <limits.h> on specific implementations where the corresponding value is equal to or greater than the stated minimum, but is unspecified.
This indetermination might depend on the amount of available memory space on a specific instance of a specific implementation. The actual value supported by a specific instance shall be provided by the sysconf() function.
I would hope that from this it is sufficiently clear that any error condition worded in terms of {OPEN_MAX} is required to be checked against the runtime value obtained from sysconf() if there is no OPEN_MAX definition in <limits.h>. Likewise for the other limits in the same list. |
|
(0005211)
dalias (reporter)
2021-01-26 17:27
|
I don't see any way that this is "sufficiently clear". Either reading is plausible and defensible, and moreover semantically the check only makes sense if the limit is static, since otherwise it's an inherent TOCTOU error (limit at time of creating the file actions object may be different than limit at the time of posix_spawn).
If a particular reading is intended it should be documented explicitly. That could be general text in the limits.h specification, to the effect that when {x} appears in the description of an interface it should be read as the dynamic limit obtainable by sysconf if the static limit is not defined. However I wonder if there might be other places where such a requirement is unintended and/or harmful, and I'd like to have a thorough review of everything potentially affected. |
|
(0005212)
shware_systems (reporter)
2021-01-26 18:05
|
I believe the expectation is these values will be static, at least for the life of the process, so applications and implementation internals can rely on sysconf(). They certainly would be if the header provided them as #define's, after all. The only reason I see for returning a different value on a subsequent call would be to mirror calls by an application to other interfaces requesting a higher or lower value be applied. Maybe this needs to be stated better in <limts.h>, maybe not, that it is on implementations not to modify these arbitrarily without such requests, as a conformance requirement. |
|
(0005213)
dalias (reporter)
2021-01-26 18:15
|
In the case of sysconf(_SC_OPEN_MAX), historically it varies dynamically within the process lifetime with setrlimit (RLIMIT_NOFILE), and moreover it's very reasonable to want to change the limit for a child process (in fact various implementors have proposed extending posix_spawn to include setrlimit-like action). Maybe it's inappropriate for sysconf(_SC_OPEN_MAX) to represent the rlimit anyway and it should just be returning -1. But this is something of a mess at present, I think. |
|
(0005214)
shware_systems (reporter)
2021-01-26 18:49
|
That is the application explicitly requesting changes, though, via setrlimit(). It's on the developer to guard against TOCTOU for that circumstance, not the standard.
Where interfaces indicate a value that isn't necessarily constant is to be referenced the behavior should be as if sysconf() is called, in the description of the curly brace notation by default more than per interface, whether the header includes an entry for the constant or not. |
|