Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

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 2024-06-11 09:08
Reporter dalias View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Closed  
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 See Note: 0005511
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:

EBADF
    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 tc3-2008
Attached Files

- Relationships

-  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.
(0005511)
nick (manager)
2021-10-28 16:35
edited on: 2021-10-28 16:39

 In frontmatter on page xvi change item 4 in the list from:
    
Names surrounded by braces represent symbolic limits or configuration values which may be declared in appropriate headers by means of the C #define construct.

to:
    
Names surrounded by braces represent symbolic limits or configuration values which may be declared in appropriate headers by means of the C #define construct, or obtained at runtime from functions or utilities that return limit or configuration values.

Add a new element to the list on P270 after L8998:
   
  • The limit has been changed at runtime by an application (see xref to setrlimit()).


    • On P270 L8999 change:
        
    For these reasons, an application may use the fpathconf( ), pathconf( ), and sysconf( ) functions to determine the actual value of a limit at runtime.

    to:
        
    For these reasons, an application can use the fpathconf( ), getrlimit(), pathconf( ), and sysconf( ) functions to determine the actual value of a limit at runtime.
    (0005539)
    geoffclare (manager)
    2021-11-25 16:28

    		 The troff changes have been applied in gitlab. The frontmatter change has been applied in an updated version to be used for Issue 8 draft 3. In the unlikely event that we do an Issue 7 TC3, the frontmatter change will also be needed there.

    - 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
    2021-10-28 16:35 nick Note Added: 0005511
    2021-10-28 16:36 nick Note Edited: 0005511
    2021-10-28 16:37 nick Note Edited: 0005511
    2021-10-28 16:38 nick Interp Status => ---
    2021-10-28 16:38 nick Final Accepted Text => See Note: 0005511
    2021-10-28 16:38 nick Status New => Resolved
    2021-10-28 16:38 nick Resolution Open => Accepted As Marked
    2021-10-28 16:39 nick Tag Attached: tc3-2008
    2021-10-28 16:39 nick Note Edited: 0005511
    2021-11-25 16:28 geoffclare Note Added: 0005539
    2021-11-25 16:28 geoffclare Status Resolved => Applied
    2024-06-11 09:08 agadmin Status Applied => Closed

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