Austin Group Defect Tracker

Aardvark Mark IV

Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001446 [1003.1(2016/18)/Issue7+TC2] System Interfaces Editorial Clarification Requested 2021-01-25 18:17 2021-01-26 18:49
Reporter dalias View Status public  
Assigned To
Priority normal Resolution Open  
Status New  
Name Rich Felker
Organization musl libc
User Reference
Section posix_spawn_file_actions_addopen et al
Page Number unknown
Line Number unknown
Interp Status ---
Final Accepted Text
Summary 0001446: Does a shall-fail in terms of an undefined limits.h macro impose any requirement?
Description posix_spawn_file_actions_addopen has a "shall fail" error condition for "The value specified by fildes is negative or greater than or equal to {OPEN_MAX}" and similar conditions appear elsewhere. If the implementation does not define OPEN_MAX, does this impose any requirement on the implementation to fail when the value exceeds a dynamic sysconf(_SC_OPEN_MAX), or is the condition vacuously false?
Desired Action Clarity whether {OPEN_MAX} refers to the actual macro value or some abstract limit by the name whose value may only be available at runtime, or just explicitly limit the condition to the case where it is defined, as in:

    The value specified by fildes is negative or the implementation defines OPEN_MAX in limits.h and the value specified by filedes is greater than or equal to OPEN_MAX.
Tags No tags attached.
Attached Files

- Relationships

-  Notes
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.
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.
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.
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.
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.

- Issue History
Date Modified Username Field Change
2021-01-25 18:17 dalias New Issue
2021-01-25 18:17 dalias Name => Rich Felker
2021-01-25 18:17 dalias Organization => musl libc
2021-01-25 18:17 dalias Section => posix_spawn_file_actions_addopen et al
2021-01-25 18:17 dalias Page Number => unknown
2021-01-25 18:17 dalias Line Number => unknown
2021-01-26 09:39 geoffclare Note Added: 0005209
2021-01-26 17:27 dalias Note Added: 0005211
2021-01-26 18:05 shware_systems Note Added: 0005212
2021-01-26 18:15 dalias Note Added: 0005213
2021-01-26 18:49 shware_systems Note Added: 0005214

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker