Document Number: AUSTIN/110r1 Title: XSHft Aardvark Change Request Report (draft 2) Revision Date: 2002-05-27 Source: Andrew Josey, Chair Action: for review This report contains the dispositions of the aardvark comments submitted against the XSH final text. Aardvark Summary Table ______________________ ERN 1 Accept ERN 2 Accept ERN 3 Accept as marked ERN 4 Accept as marked ERN 5 Accept ERN 6 Reject ERN 7 Accept as marked ERN 8 Accept ERN 9 Accept as marked ERN 10 Accept ERN 11 Accept ERN 12 OPEN (Accept as marked ) ERN 13 OPEN ERN 14 Accept as marked ERN 15 Reject ERN 16 OPEN ERN 17 Accept ERN 18 Accept as marked ERN 19 Accept as marked ERN 20 Accept ERN 21 Accept ERN 22 Accept (was Reject ) ERN 23 Accept ERN 24 Accept as marked ERN 25 Accept ERN 26 Accept as marked ERN 27 Accept as marked ERN 28 Accept ERN 29 Accept ERN 30 Accept ERN 31 Accept ERN 32 Reject ERN 33 Accept ERN 34 Accept ERN 35 Accept as marked ERN 36 Accept ERN 37 Accept ERN 38 Accept ERN 39 Accept ERN 40 Accept ERN 41 Accept ERN 42 Accept ERN 43 Accept as marked ERN 44 Reject ERN 45 Accept as marked ERN 46 Accept ERN 47 Accept ERN 48 Accept as marked ERN 49 Accept as marked ERN 50 Accept ERN 51 Accept ERN 52 Accept as marked ERN 53 Accept as marked ERN 54 Accept as marked ERN 55 Accept ERN 56 Accept as marked ERN 57 Accept as marked ERN 58 Accept as marked ERN 59 Accept as marked _____________________________________________________________________________ OBJECTION Enhancement Request Number 1 ajosey@opengroup.org Defect in XSH 2.2.2 (rdvk# 2) {tc1-1} Mon, 14 Jan 2002 15:35:03 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC1 candidate _____________________________________________________________________________ Page: 17 Line: 642 Section: 2.2.2 Problem: Defect code : 1. Error XSH 6 (ft) Section 2.2.2 "The Name Space" states that "The prefixes posix_, POSIX_ and _POSIX are reserved for use by IEEE Std 1003.1-2001 and other POSIX standards. Implementations may add symbols to the headers shown in the following table, provided the identifiers.... do not use the reserved prefixes posix_, POSIX_ or _POSIX." however, the last line(l642) of the following table on page 16/17 reserves the same prefixes for use in any header. There is thus a contradiction between the two parts of the standard. Action: Delete "POSIX_, _POSIX_, posix_" from the Prefix column of the table on page 17 , line 42. [Ed recommendation: Accept Recommend fix in TC1] _____________________________________________________________________________ OBJECTION Enhancement Request Number 2 joannaf@sun.com Defect in XSH 2.2.2 Namespace (rdvk# 33) {Sun-jf-dc4} Mon, 15 Apr 2002 15:31:15 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC1 candidate _____________________________________________________________________________ Page: 18 Line: 659 Section: 2.2.2 Problem: Defect code : 1. Error The C Standard allows implementations to define macros of the form "PRI" or "SCN" followed by any lowercase letter or "X" in . (ISO/IEC 9899:1999 P400, subclause 7.26.4.) The AGR's namespace reservation on XSH6, P18, L659 doesn't allow use of "PRIX" or "SCNX". Action: In XSH6, P18, L659 change:- PRI[a-z],SNC[a-z] to:- PRI[Xa-z],SNC[Xa-z] [Ed recommendation: Accept Recommend fix in TC1] _____________________________________________________________________________ OBJECTION Enhancement Request Number 3 ajosey@opengroup.org Defect in XSH 2.2.2 (rdvk# 1) {tc1-2} Mon, 14 Jan 2002 16:15:40 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC1 candidate Delete lines 670-671 Add new section under the table before line 688 The following are used to reserve complete names for the stdint.h header: INT[0-9A-Z_]*_MIN, INT[0-9A-Z_]*_MAX, INT[0-9]*_C _____________________________________________________________________________ Page: 18 Line: 670 Section: 2.2.2 Problem: Defect code : 1. Error XSH 6 (ft) Section 2.2.2 in the table on page 18 reserves the following namespace prefixes for stdint.h INT[0-9A-Z_]_MIN, INT[0-9A-Z_]_MAX, INT[0-9A-Z_]_C UINT[0-9A-Z_]_MIN, UINT[0-9A-Z_]_MAX, UINT[0-9A-Z_]_C Compare these with lines 606 and 607 where the patterns have the "*" in them. It is also probable that the [A-Z_] part should not be in the INT[0-9A-Z_]*_C and UINT[0-9A-Z_]*_C since these macros are for items such as INT64_C and UINT128_C. Action: Delete lines 670-671 Add new section under the table before line 688 The following are used to reserve complete names for the stdint.h header: INT[0-9A-Z_]*_MIN, INT[0-9A-Z_]*_MAX, INT[0-9]_C UINT[0-9A-Z_]*_MIN, UINT[0-9A-Z_]*_MAX, UINT[0-9]_C [Ed recommendation: Accept Recommend fix in TC1] _____________________________________________________________________________ OBJECTION Enhancement Request Number 4 drepper@redhat.com Defect in XSH 2.5.1 (rdvk# 6) {ud-ft-1} Fri, 25 Jan 2002 06:24:42 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: This will be forwarded down the interpretations track. Interpretation category: Defect Proposed response: The standards states the requirements for fflush() and interaction between file descriptors in section 2.5.1. Concerns have been raised about this which are being referred to the sponsor. Rationale: This is a difficult area. The specification as written appears to be telling applications to do something unspecified. Proposed wording for a future revision (not part of this interpretation): Add in line 11607 (CX shaded): If /stream/ is associated with a seekable file and points to an input stream or an update stream in which the most recent operation was input, fflush() shall cause all buffered input to be discarded and the file offset for the file descriptor be reset to the first unprocessed byte (or possibly similar wording from original .1-1988) _____________________________________________________________________________ Page: 36 Line: 1472 Section: 2.5.1 Problem: Defect code : 1. Error This could be filed as an error in this section or an ommision in fflush(). The problem is that in section 2.5.1 of XSH, which deals with the interaction of file descriptors and I/O streams, it is written: If the stream is open with a mode that allows reading and the underlying open file description refers to a device that is capable of seeking, the application shall either perform an fflush( ), or the stream shall be closed. The man page for fflush() explicitly does not mention what happens if fflush() is applied to an input stream or an update stream with the last operation being input. This wording comes straight from ISO C. The problem is that ISO C does not have to deal with file descriptors. POSIX does. In the early POSIX versions the text in section 2.5.1 was added to make clear how the interaction works. But the fflush() documentation was never updated. Action: There are two possible options: - the original intend was to define fflush() on input streams and it was just forgotten to update the fflush() documentation. In this case the page should be updated with the following in line 11607 (CX shaded): If /stream/ points to an input stream or an update stream in which the most recent operation was not input, fflush() shall cause all buffered input to be discarded and on seekable files the file offset for the file descriptor be reset to the first unprocessed byte. - if fflush() is not meant or cannot be changed some other mechanism for synchronizing input streams must be found. As far as I can see no existing function fits the bill so I cannot make any concrete proposal. _____________________________________________________________________________ OBJECTION Enhancement Request Number 5 drepper@redhat.com Defect in XSH 2.8.3.1 Memory Locking (rdvk# 28) {ud-13} Wed, 20 Mar 2002 06:28:21 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC1 candidate _____________________________________________________________________________ Page: 43 Line: 1759-1770 Section: 2.8.3.1 Problem: Defect code : 1. Error The first paragraph of section 2.8.3.1 says that the functionality described in the section is only available if the Process Memory Locking option is available. This is not true. The second paragraph describes functionality which is only available if the Range Memory Locking option is available. There is nowhere any wording which requires that Process Memory Locking must be available if Range Memory Locking is available. So there are two problems: - the first paragraph must say that the section applies also for Range Memory Locking - the second paragraph only applies for Range Memory Locking Action: The way the first paragraph is used becomes cumbersome with the necessary change therefore the proposed change is this: - remove the first paragraph explaining the missing shading - shade the second paragraph and mark it MLR - shade the third paragraph and mark it ML|MLR _____________________________________________________________________________ OBJECTION Enhancement Request Number 6 mgh@unican.es Defect in XSH (rdvk# 56) Tue, 30 Apr 2002 18:13:30 +0200 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: Out of scope for TC1 or interpretation. Recommend that this follow the route outlined for new submissions as per Austin/106 and forthcoming paper from the Chair. _____________________________________________________________________________ Page: 53-54 Line: 2188-2218 Section: 2.9.4 Problem: POSIX.1 defines the "Scheduling Allocation Domain" as the set of processors on which an individual thread can be scheduled at any given time. POSIX.1 states that: - "For application threads with scheduling allocation domains of size equal to one, the scheduling rules defined for SCHED_FIFO and SCHED_RR shall be used;" - "For application threads with scheduling allocation domains of size greater than one, the rules defined for SCHED_FIFO, SCHED_RR, and SCHED_SPORADIC shall be used in an implementation-defined manner." - "The choice of scheduling allocation domain size and the level of application control over scheduling allocation domains is implementation-defined. Conforming implementations may change the size of scheduling allocation domains and the binding of threads to scheduling allocation domains at any time." The problem is that with these semantics, it is only possible to write strictly conforming applications with realtime scheduling requirements for single-processor systems. If a multiprocessor platform is used, there is no portable way to specify static allocation of threads to processors and, therefore, to get predictable scheduling behavior. Although there are some special multiprocessor architectures, most commercial systems are either single-processor or symmetric shared-memory multiprocessor systems, and for these systems a simple API can be designed to manage allocation domains. Additional APIs may be needed for special architectures, but even a simple API represents a major step forward towards portability. The standard should have an API for setting the initial allocation domain of a thread as part of its thread-creation attributes. The new API should be optional, but it will be mandated in the realtime profiles so that predictable scheduling can be achieved in multiprocessors. It has to be discussed whether an API is necessary or not for dynamically changing the allocation domain, as not all implementations support this feature. Most probably, the real-time profiles will not require this feature. Some of the existing vendor models are not quite as general and flexible (orthogonal) as they could be, and a POSIX effort could end up raising the level of all. One limitation that has been found is the inability to make threads stay off of a specified processor or group of processors. Action: Add an API for being able to portably set the initial allocation domain of a thread. Every major UNIX platform vendor offers multiprocessor platforms, and has their own set of non-standard APIs (and perhaps shell commands) to enable and disable processors, to group them in various ways, and to allow or forbid defined threads of specified processors or groups of processors. The planned approach is to collect and study these APIs and shell commands, and come up with a simple model and set of APIs that can handle all those models. Without having made the exercise of checking existing APIs, an initial idea is sketched below to capture the essence of the required functionality. Concepts: define the concept of a scheduling allocation node as an abstract entity to which threads may be assigned for the purpose of scheduling. This will usually be a processor, but it may be some other implementation-defined object such as a virtual processor or similar. Change the wording under "scheduling allocation domain" to explain the model with the new optional thread attributes (see below) Types: Define a type for identification of scheduling allocation nodes; it is an arithmetic type: pthread_alloc_node_id_t Define an opaque type for the allocation domain of a thread. It is defined as an abstract set of allocation node ids: pthread_alloc_domain_t New thread attributes: allocation-domain-mode: A flag stating whether the allocation domain is implementation defined-- PTHREAD_ALLOC_SYSTEM (default) or application defined-- PTHREAD_ALLOC_APP. allocation-domain: it is only used if allocation-domain-mode is PTHREAD_ALLOC_APP Interfaces: define operations to portably get allocation node ids: pthread_alloc_node_id_t pthread_alloc_node_get_min() pthread_alloc_node_id_t pthread_alloc_node_get_max() the number of allocation nodes is (max-min+1); the allocation node min and max may be different for each process; allocation node ids are a per-process concept and are not comparable across processes. define operations for handling allocation domains (modeled after signal masks): int pthread_alloc_domain_empty (pthread_alloc_domain_t *domain) int pthread_alloc_domain_fill (pthread_alloc_domain_t *domain) int pthread_alloc_domain_add (pthread_alloc_domain_t *domain, pthread_alloc_node_id_t node) int pthread_alloc_domain_del (pthread_alloc_domain_t *domain, pthread_alloc_node_id_t node) int pthread_alloc_domain_ismember (const pthread_alloc_domain_t *domain, pthread_alloc_node_id_t node) define operations to set and get the allocation-domain-mode creation attribute of a thread: int pthread_attr_setallocdomainmode (pthread_attr_t *attr, int mode) int pthread_attr_getallocdomainmode (const pthread_attr_t *attr, int *mode) define operations to set and get the allocation-domain creation attribute of a thread: int pthread_attr_setallocdomain (pthread_attr_t *attr, pthread_alloc_domain_t domain) int pthread_attr_getallocdomain (const pthread_attr_t *attr, pthread_alloc_domain_t *domain) Note The requested action may seem too important for a technical corrigenda. In that case, the POSIX Realtime System Services Working Group would like to take this action as a work item for a future amendment to the standard. _____________________________________________________________________________ COMMENT Enhancement Request Number 7 terekhov@de.ibm.com Defect in XSH 2.9.5 Thread Cancelation (rdvk# 52) {6} Mon, 29 Apr 2002 12:48:27 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Our advice follows. There is no requirement in the standard today. The committee agrees with D B that this would be difficult to specify and gain consensus. (Note the committee would refer the submitter to the aardvark guidelines for future submissions. Questions should be phrased against the standard with proposed solutions if possible. Problem statements must be standalone, so that reviewers not familiar with the problem can understand the statement . Please note that the committee is not required to give consulting advice.) _____________________________________________________________________________ Page: 54-57 Line: 2226-2358 Section: 2.9.5 Problem: Defect code : 3. Clarification required http://groups.google.com/groups?selm=GcRH7.1479%24RL6.47817%40news.cpqcorp.net David Butenhof (David.Butenhof@compaq.com) wrote: ".... This discussion HAS pointed out a legitimate "gotcha" in the standard; there's really nothing you can do to deal with cancellation points in a signal handler. We've always said, however, that "signals and threads don't mix well". This is another example, and there's no good solution. Alexander Terekhov suggested making cancellation points ignore a pending cancel within a "signal catching function". While that's not entirely a BAD idea, it's not that simple. For one thing, most UNIX kernels don't really keep track of whether you're in a "signal catching function". The only state that distinguishes "a signal catching function" is that there's some sort of a signal trampoline frame on the stack, and there MAY be a signal "temporarily" blocked by delivery of a signal. It'd be difficult to make the standard specify behavior based on this nebulous "state"; not only are there technical complications, but I suspect that gaining any sort of political concensus would be really difficult. ...." Action: Please advise. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 8 bjh21@netbsd.org Defect in XSH _Exit (rdvk# 50) Fri, 26 Apr 2002 17:21:34 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC1 candidate _____________________________________________________________________________ Page: 85 Line: 3372-3374 Section: _Exit() Problem: The SYNOPSIS lists _Exit() under , whereas it should be under (confirmed at XBD page 325 line 11650 section and XSH page 305 line 9941 section exit()). Action: Replace the SYNOPSIS with: #include void _Exit(int status); #include void _exit(int status); _____________________________________________________________________________ OBJECTION Enhancement Request Number 9 drepper@redhat.com Defect in XSH bsearch (rdvk# 7) {ud-3} Tue, 29 Jan 2002 18:32:37 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC1 candidate: rationale further ISO C alignment Add at the end of line 5244: /nel/ can have the value zero on a call to that function; the comparison function is not called and a search finds no matching element. Add at line 5247 the new paragraphs: The comparison function shall not alter the contents of the array. The implementation may reorder elements of the array between calls to the comparison function, but shall not alter the contents of any individual element. The implementation shall ensure that the first argument is always a pointer to the key. When the same objects (consisting of size bytes, irrespective of their current positions in the array) are passed more than once to the comparison function, the results shall be consistent with one another. That is, the same object shall always compare the same way with the key. Replace line 5313 with: The requirement that the second argument to the comparison function is a pointer to elements of the array implies that for every call all of the following expressions are nonzero: ((char *)p - (char *)base) % size == 0 (char *)p >= (char *)base (char *)p < (char *)base + nel * size _____________________________________________________________________________ Page: 149 Line: 5244 Section: bsearch Problem: Defect code : 2. Omission The introduction to the header in ISO C99 contains the words (section 7.20.5): ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 These utilities make use of a comparison function to search or sort arrays of unspecified type. Where an argument declared as size_t nmemb specifies the length of the array for a function, nmemb can have the value zero on a call to that function; the comparison function is not called, a search finds no matching element, and sorting performs no rearrangement. Pointer arguments on such a call shall still have valid values, as described in 7.1.4 2 The implementation shall ensure that the second argument of the comparison function (when called from bsearch), or both arguments (when called from qsort), are pointers to elements of the array.254) The first argument when called from bsearch shall equal key. 3 The comparison function shall not alter the contents of the array. The implementation may reorder elements of the array between calls to the comparison function, but shall not alter the contents of any individual element. 4 When the same objects (consisting of size bytes, irrespective of their current positions in the array) are passed more than once to the comparison function, the results shall be consistent with one another. That is, for qsort they shall define a total ordering on the array, and for bsearch the same object shall always compare the same way with the key. 5 A sequence point occurs immediately before and immediately after each call to the comparison function, and also between any call to the comparison function and any movement of the objects passed as arguments to that call. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The bsearch man pages should contain the same information. Action: Add at the end of line 5244: /nel/ can have the value zero on a call to that function; the comparison function is not called and a search finds no matching element. Add at line 5247 the new paragraphs: The comparison function shall not alter the contents of the array. The implementation may reorder elements of the array between calls to the comparison function, but shall not alter the contents of any individual element. When the same objects (consisting of size bytes, irrespective of their current positions in the array) are passed more than once to the comparison function, the results shall be consistent with one another. That is, the same object shall always compare the same way with the key. Replace line 5313 with: The requirement that the second argument to the comparison function is a pointer to elements of the array implies that for every call all of the following expressions are nonzero: ((char *)p - (char *)base) % size == 0 (char *)p >= (char *)base (char *)p < (char *)base + nel * size I'm not sure whether the comment about the sequence points is needed as well. ISO C defines them carefully but it is avoided so far in this document. _____________________________________________________________________________ OBJECTION Enhancement Request Number 10 ajosey@opengroup.org Defect in XSH close (rdvk# 27) {pin4u.00068} Mon, 18 Mar 2002 09:26:28 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC1 candidate _____________________________________________________________________________ Page: 203 Line: 6879 Section: close Problem: Defect code : 1. Error The Open Group Base working group has detected a defect in this section of text relating to close when fildes refers to the master side of a psuedo-terminal. The current text doesn't match historic PTY behavior in 4.3BSD or UNIX SVR4. (On those systems, the SIGHUP signal is sent to the controlling process associated with a PTY device; not directly to the entire process group.) The Base WG believe that the behavior of pseudo-terminals and regular terminals should behave as much alike as possible in this case and proposes the attached change to achieve that and match historical behavior. Action: Replace the XSI shaded sentence commencing on line 6879 with: "If fildes refers to the master side of a pseudo-terminal, and this is the last close, a SIGHUP signal shall be sent to the controlling process, if any, for which the slave side of the pseudo-terminal is the controlling terminal." [Ed recommendation: Accept Recommend fix in TC1] _____________________________________________________________________________ COMMENT Enhancement Request Number 11 ajosey@opengroup.org Defect in XSH closelog (rdvk# 5) {tc1.setlogmask.ex} Thu, 24 Jan 2002 13:56:50 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC1 candidate _____________________________________________________________________________ Page: 210 Line: 7122 Section: closelog Problem: Defect code : 1. Error (page and line numbers are for the ft [finaltext] document) This is about the EXAMPLE, "Using setlogmask()" The call is incorrect. The values for priority are numbers in the range 0-7 and LOG_MASK(prio), that is, 1< shall always be provided and should be changed to be unshaded . This is a fix needed for TC1, and is an integration issue for the revised standard. (part 2) As a response to the rest of this request. Using string args instead of int args for the *conf functions is a change to the standard that is out of scope; this is an API, not an ABI, and binary values are not required. A group writing an ABI could (should) provide values for these symbols, this is not a goal of this standard. The SC values are strings, for the compiler to translate as it sees fit. _____________________________________________________________________________ Page: 212 Line: 7145 Section: confstr,pathconf,sysconf Problem: Defect code : 1. Error Problem: getconf is portable, conf interfaces aren't, as specified. Please note that the below is how I'm interpreting the spec as written, but I do allow I may have overlooked something that invalidates my reasoning, so no flames, please :-) Scenario: confstr(), (f)pathconf(), and sysconf() define their name parameter to be of type int, yet specifies also A) some options may be omitted by an implementation, and the associated identifiers from unistd.h, and B) the specification does not indicate which values any of these constants shall assume when specified in unistd.h, just that they be defined somehow. While these functions are included to support the facilitation of binary package redistribution, such allowances render these functions potentially non-portable for source distributions of an application, and even binary packages may fail to execute as intended if an implementor isn't careful. These allowances do not affect the getconf utility, as its name parameter is a string value, not an integer, and it's presumed an array of supported values for such strings will be scanned to generate the appropriate integer value for passing to the appropriate conf interface, and if the argument is not found exit returning an error code >0. This level of indirection makes getconf portable, as you can throw any text at it and it should blurp appropriately. While it may make for faster implementations, using an integer name isn't portable with the allowances above. Rationale: For A), allowing missing identifiers immediately makes any application desiring to use the interfaces non-portable source. They are explicitly bound to the implementation on which they were originally developed and for which it can be guaranteed all identifiers referenced by the application are defined in unistd.h. If an optional identifier is specified in an application source for testing and the identifier is not declared in unistd.h on any other implementation, any compile will fail with an 'identifier not found' error, yet both systems may be certified as conformant to the spec. The only way to avoid this error is for each instance where an optional identifier is to be used that the code be enclosed, in simplest form, as follows: #ifdef ident long sc_ident_rslt=sysconf(ident); // or confstr(ident), etc. // use sc_ident_rslt... #endif or constructions to this effect. However, it is not specified such constructs SHALL be required, and constructs like this make the specification that sysconf set errno if an identifier is not supported superfluous, nominally. For cases where applications hard code ident values, e.g. errno=0; long rslt=sysconf(1000); if !errno {/* no ident 1000 */}; the requirement to set errno is still valid, yet this usage is patently non-portable, requiring the compiler invoker to ensure that each hard coded value refers to the desired test option on their system. The other alternative is to specify that all identifiers be declared in unistd.h to some integer value, even if the implementation doesn't support that optional functionality. Which brings us to B), the lack of which integer value is to be assigned each identifier: As stands, this lack of specification affects potential binary portability more than source portability. Succinctly, a binary may fail to give correct results on another implementation, other environmental and architectural considerations being accounted for, because the unistd.h declarations of the constants aren't guaranteed to be equivalent in the two environments, just that they conform to the spec. The spec presumes an implementor of varying conformance levels for a specific architecture will use a single version of unistd.h for all implementations, thus implicitly maintaining an equivalence of name usage, or possibly multiple versions where the usage of values specific to each implementation is a subset of the maximum amount of values needed to be accounted for, but there is nothing in the spec. that mandates such equivalence or usage of values. While a single implementor can assure by the presumed usages above that an application will function correctly, it has no control over how another implementor may produce a conforming unistd.h. Thusly, while a binary distributin could conceivably load and begin execution in another environment, there is no way the application could rely on the results returned by a conf interface to adapt it's function to that environment's configuration. There is no guarantee that identifiers of the same name would have equal values, or that identifiers from an option group implemented on one machine could be assigned values that specify entirely different options on another machine. The only way I see to provide this level of portabilty is to explicitly specify that each identifier that is a potential legal value for an interfaces' name property be assigned an explicit integer value. This presumes it is desired to maintain backwards compatibility with the previous and current format of these interfaces' declarations. The solution that enables maximal future portability is to change the type of the name parameter from int to char*, or const char*, or provide additional interfaces that use a string parameter for name. This would simplify any implementation of getconf also. It could be this was what was originally intended for these interfaces, yet the functional difference between a compiletime header identifier and an explicit runtime string constant was overlooked. Action: As above, multiple ways of reconciling the discrepancies exist: For the current interfaces, 1) all mention that an identifier is optional should be excised (preferred), or require implementors to document that application developers cannot presume use of any optional identifier will give consistent results in other environments. The description of margin notation usage should be reworded to indicate that a) an identifier shall be recognized, but give meaningful output only when the Option Group indicated is in fact implemented in that execution environment, or b) indicates that any usage of such identifier will be appropriately ifdef'd in the applications' source, using either the identifier explicitly or a feature test identifier that guarantees in accordance with the specification that identifier shall also be defined in unistd.h. 2) All identifiers should be assigned explicit values. For case 1b), it would need to be also specified that even if an implementors' unistd.h did not include an identifier because the Option wasn't implemented, the value assigned can not be co-opted to some other purpose for features specific to their implementation. This has the benefit also, that in the case where an application does hard code a specific value in a an interface call, the behavior produced will be consistent with the interface description regardless of platform the application is compiled on, presuming the same system call mechanisms are adhered to by platform variants. For future portability considerations, ranges of non-overlapping values may be specified for option groups currently with optional subgroups, e.g. Batch Services, or to reserve values for use by a new group, or sub-group of an existing group, that a revision of the spec may deem appropriate, e.g. if RPC features are incorporated as a sub-group of a network IO service(s) at some point, the spec could have a new ASYNC_IO_RPC_SUPPORT and SYNCH_IO_RPC_SUPPORT interface gtroups, which would be assigned values from the ranges reserved for ASYNCHRONOUS_IO, and SYNCHRONOUS_IO, respectively. Larger ranges reserving values for LEGACY, OBSOLETE, and groups optional in previous versions; plus a range for vendor-specific non-portable customizations, may also be specified. 3) The current interfaces should be marked LEGACY as a Corrigenda item, introducing new interfaces where name is a char or wchar param, and OBSOLETE for next Issue of the spec. The extended portability benefits of interfaces specified as such, IMO, outweighs the loss of speed, entailed by requiring text lookups in the implementations thereof, for those applications accessing the interfaces directly. getconf's speed shouldn't be affected, as it does the lookups to begin with now. Optionally, the interfaces could be extended to accept a textname param as a varargs extension, with the int name only usage marked as LEGACY; or a helper interface that converts a text identifier to the integer assigned by that implementation could be defined. With the first, all cs, pc, and sc constants could eventually be removed from unistd.h, as the text constants actually supported would only need to be specified in the system docs and the Conformance statement, and declared privately in the implementations of the interfaces. 4) Other compatibility considerations should be discussed, and a consensus reached, before picking which remedy seems most suitable. _____________________________________________________________________________ COMMENT Enhancement Request Number 13 mseitz@yahoo.com Defect in XSH dlsym (rdvk# 35) {0} Tue, 16 Apr 2002 22:40:04 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_____OPEN Rationale for rejected or partial changes: This enhancement request is being handled as an interpretation request. Overview: The standard is clear and conforming implementations must behave as described. The dlsym() function is marked as part of the X/Open System Interfaces Extension (by the XSI margin marking). Systems conforming to the X/Open Systems Interfaces Extension are indeed required to be able to convert between function pointers and void * data pointers without losing data. This is most clearly stated in the description of the va_arg() macro in the description of (XBD, P310, L11109-11119) where the XSI shading on L11119 indicates that implementations supporting the X/Open System Interfaces Extension are required to be able to handle pointers to any type of object, not just pointers to data. The XSI margin marking description clearly states that requirements like this are extensions to the requirements of the C Standard. In this case, the 1999 C Standard does indeed require a warning to be issued for the function call shown in the dlsym() examples section on XSH P259, L8566. An equivalent form of this call: *(void **)(&fptr) = dlsym(handle, "my_function"); does not generate compiler warnings and will work correctly on all systems supporting the X/Open System Interfaces Extension. Notes to the Editor: In a TC or revision of the standard make the following changes: 1. XSH P259, L8566 (EXAMPLES): Change from: fptr = (int (*)(int))dlsym(handle, "my_function"); to: *(void **)(&fptr) = dlsym(handle, "my_function"); 2. XSH P260, L8590 (RATIONALE): Change from: None. to: The C Standard does not require that pointers to functions can be cast back and forth to pointers to data. Indeed, the C Standard does not require that an object of type void * can hold a pointer to a function. Systems supporting the X/Open System Interfaces Extension, however, do require that an object of type void * can hold a pointer to a function. The result of converting a pointer to a function into a pointer to another data type (except void *) is still undefined, however. Note that compilers conforming to the C Standard are required to generate a warning if a conversion from a void * pointer to a function pointer is attempted as in: fptr = (int (*)(int))dlsym(handle, "my_function"); _____________________________________________________________________________ Page: 259 Line: 8540 Section: dlsym Problem: Defect code : 2. Omission The "dlsym()" function is defined as returning "the address of a symbol". According to the Example, "dlsym ()can be used to access either function or data objects". The return type of dlsym is a "void *". In order to actually call a function using the pointer returned by "dlsym()", the pointer must be converted from a "void *" type to a pointer to function type. However, the ISO C Standard says that converting a "void *" type to a pointer to function type results in undefined behavior. At least one major compiler reports a warning when attempting such a conversion, even with an explicit cast. Action: I would like a new function added that returns the address of a function object symbol and whose return type is a function pointer. For example: fptr_t dlsym_f(void *restrict handle, const char *restrict name); Standard C requires that a pointer to a function of one type may be converted to a pointer to a function of another type and back again, and the result shall compare equal to the original pointer. Therefore, "fptr_t" can be defined as any pointer to function type. The "dlsym()" function could continue to be used for data objects. As an extension, implementations that allow converting from "void *" to pointer to function types could continue to allow using "dlsym()" in addition to "dlsym_f()" for function objects. This would allow backwards compatability, while offering a more portable option for new code. _____________________________________________________________________________ COMMENT Enhancement Request Number 14 wollman@lcs.mit.edu Defect in XSH exec (rdvk# 38) {GAW-2002c} Fri, 19 Apr 2002 05:12:19 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Propose for TC1 since this is a security issue. as a new para XSH6 exec p296 before 9573 If fd 0,1,2 would otherwise be closed after a succesful call to one of the exec family of functions, and the new process image file has the set-user-ID or set-group-ID file mode bits set,[XSI] and the ST_NOSUID bit is not set for the file system containing the new process image file,[/XSI] implementations may open an unspecified file for each of these file descriptors in the new process image. Add to APP USAGE Applications should not depend on file descriptors 0,1, and 2 being closed when they are exec'd. A future revision may allow these file descriptors to be automatically opened for any process. Rationale: want to permit impl to reopen fd 0,1,2 for setuid and setgid programs calling exec. this is a security issue _____________________________________________________________________________ Page: 295 Line: 9548 Section: exec Problem: (Ed:page and linenos corrected, was d7 777 9883, though exec is not on p 777, and line 9883 in d7 does not to map to relevant text, numbers above assumed) Defect code : 3. Clarification required The Standard requires that all file descriptors open in the old process remain open in the new process, unless marked close-on-exec. However, it is not clear whether the complement is also true; i.e., that all file descriptors closed in the old process remain closed in the new process. The list of explicit actions on exec() is silent on this question. Does the blanket statement ar the end of the list (``All process attributes [...] shall be the same in new and old process images.'') control? This question comes up in the context of an implementation which would automatically re-open STD{IN,OUT,ERR}_FILENO on certain calls to exec-family functions if the calling process had closed them. Does such an implementation conform? Action: I can see two possible resolutions: a) The blanket clause controls, and the behavior described in my example is prohibited. b) The standard does not specify, and no conformance distinction can be made on this basis. If the resolution is (a), I'd like to see this stated explicitly in the paragraph describing file descriptors: ``File descriptors closed in the old process image, whether as a result of an explicit call to the close() function, or as a result of the descriptor having been marked close-on-exec, shall remain closed in the new process.'' _____________________________________________________________________________ COMMENT Enhancement Request Number 15 terekhov@de.ibm.com de.ibm.com (rdvk# 29) {4} Sat, 23 Mar 2002 09:06:38 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: The committee agrees that there is a problem and requests that the submitter submits specific proposed actions for review. A global replacement between "process signal mask" to "thread signal mask" is not appropriate. Until such changes are received in the form of a revised aardvark, and changes, if any, accepted at the next review, there is no action here that can be accepted as is. _____________________________________________________________________________ Page: 297 Line: 9654- Section: Problem: Defect code : 1. Error David Butenhof wrote: [...] > 2) You've uncovered a bug in the specification that should be repaired >in the corrigenda. There is no such thing as a "process signal mask", >and even if it existed pselect() would have no business altering it. >It needs to be fixed to specify the THREAD signal mask. Please take a look at the results of my search on "signal mask" in the context of "process signal mask" (I think that these places (well, perhaps not all, but...) might need to be "corrected" as well): Line numbers as per XSH 9654 -Process signal mask (see sigprocmask()) 9825 SIG_IGN, and that the process signal mask be unchanged across an exec. 30903 If sigmask is not a null pointer, then the pselect( ) function shall replace the signal mask of the 30904 process by the set of signals pointed to by sigmask before examining the descriptors, and shall 30905 restore the signal mask of the process before returning. 35413 process signal mask shall be unchanged; 35428 shall be set to indicate the error, and the process signal mask shall be unchanged. 35438 When a process signal mask is changed in a signal-catching function that is installed by 41457 signals that shall be added to the process signal mask before the signal-catching function is 41523 XSI SA_NODEFER If set and sig is caught, sig shall not be added to the process signal mask 41524 on entry to the signal handler unless it is included in sa_mask.Otherwise, 41525 sig shall always be added to the process signal mask on entry to the 41526 signal handler. 41607 used to leave the signal handler, then the signal mask must be explicitly restored by the process. 41947 used, and disp is the address of a signal handler, the system shall add sig to the calling process 41948 signal mask before executing the signal handler; when the signal handler returns, the system 41949 shall restore the calling process signal mask to its state prior to the delivery of the signal. In 41950 addition, if sigset( ) is used, and disp is equal to SIG_HOLD, sig shall be added to the calling 41951 process signal mask and sigs disposition shall remain unchanged. If sigset( ) is used, and disp is 41952 not equal to SIG_HOLD, sig shall be removed from the calling process signal mask. 41953 The sighold ( ) function shall add sig to the calling process signal mask. 41954 The sigrelse( ) function shall remove sig from the calling process signal mask. 41955 The sigignore( ) function shall set the disposition of sig to SIG_IGN. 41956 The sigpause( ) function shall remove sig from the calling process signal mask and suspend the 41957 calling process until a signal is received. The sigpause( ) function shall restore the process signal 41958 mask to its original state before returning. 41997 The DESCRIPTION is updated to indicate that the sigpause( ) function restores the process 41998 signal mask to its original state before returning. 42192 The DESCRIPTION is updated to indicate that the sigpause( ) function restores the process 42193 signal mask to its original state before returning. 48179 unspecified whether the SIGALRM signal is blocked, unless the process signal mask is restored 48180 as part of the environment. Action: Change "process signal mask" to "thread signal mask". _____________________________________________________________________________ COMMENT Enhancement Request Number 16 kr-ag@raeburn.org Defect in XBD getaddrinfo (rdvk# 25) {none} Thu, 14 Mar 2002 20:35:06 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_____OPEN Rationale for rejected or partial changes: Action on adjg _____________________________________________________________________________ Page: 425 Line: 13888 Section: getaddrinfo Problem: Defect code : 3. Clarification required The description of getaddrinfo's AI_CANONNAME flag uses the terms "canonical name" and "alias" without definition. Since DNS is not the only possible implementation, it cannot be assumed that the RFC2181 definitions apply in the general case, and it's unclear whether they should be applied when DNS is used or if that would conflict with some existing but poorly described notion of what they should mean across all implementations. It also gives no indication what the expected behavior is if AI_CANONNAME is used with a numeric host address string. Action: After the second paragraph in the Description section (sorry, I'm reading the HTML version from opengroup.org, so no line numbers), add in smaller type this note copied from the gethostbyname description: Note: In many cases it is implemented by the Domain Name System, as documented in RFC 1034, RFC 1035, and RFC 1886. After the Description paragraph starting "If the AI_CANONNAME flag", add in smaller type: Note: Since different implementations use different conceptual models, the terms "canonical name" and "alias" cannot be precisely defined for the general case. However, Domain Name System implementations are expected to interpret them as they are used in RFC 1034. Note: A numeric host address string is not a "name", and thus does not have a "canonical name" form; no address to hostname translation is performed. See below for handling of the case where a canonical name cannot be obtained. OR, in place of the second paragraph, depending on the intent: Note: A numeric host address string is not a "name", and thus does not have a "canonical name" form. However, implementations may return the hostname corresponding to the address, as would be translated by getnameinfo, if it is available. Add to the Application Usage section: The term "canonical name" can be misleading. It should be noted that the canonical name is a result of alias processing, and not necessarily a unique attribute of a host, address, or set of addresses. See RFC 2181 for more discussion of this in the Domain Name System context. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 17 mccann@zk3.dec.com BUGs in XSH Issue 6 (rdvk# 10) [JMXSH6-2] Tue, 5 Feb 2002 15:49:43 -0500 (EST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC1 candidate (also get AI_ADDRCONFIG indexed) _____________________________________________________________________________ Page: 425 Line: 13919-13921 Section: freeaddrinfo Problem: Defect code : 2. Omission The list of valid flags for the ai_flags argument is missing the following flags: AI_V4MAPPED, AI_ALL, and AI_ADDRCONFIG. This is for alignment with the IETF IPv6 API specification. Action: On line 13921 change "and AI_NUMERICSERV" to "AI_NUMERICSERV, AI_V4MAPPED, AI_ALL, and AI_ADDRCONFIG". _____________________________________________________________________________ EDITORIAL Enhancement Request Number 18 mccann@zk3.dec.com BUGs in XSH Issue 6 (rdvk# 11) [JMXSH6-3] Tue, 5 Feb 2002 15:49:43 -0500 (EST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC1 candidate Insert the following text after line 13943: If the AI_ADDRCONFIG flag is specified, IPv4 addresses shall be returned only if an IPv4 address is configured on the local system,[IP6] and IPv6 addresses shall be returned only if an IPv6 address is configured on the local system.[/IP6] _____________________________________________________________________________ Page: 425 Line: 13922-13943 Section: freeaddrinfo Problem: Defect code : 2. Omission Missing description of the behavior of the AI_ADDRCONFIG flag. This was noted in my draft 5 aardvark [Compaq-JM7], but was for some reason was omitted from the final text. See http://www.opengroup.org/austin/docs/austin_77r2.txt. Note the AI_ADDRCONFIG flag is described in . This is for alignment with the IETF IPv6 API specification. Action: Insert the following text after line 13943: If the AI_ADDRCONFIG flag is specified, IPv4 addresses shall be returned only if an IPv4 address is configured on the local system, and IPv6 addresses shall be returned only if an IPv6 address is configured on the local system. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 19 mccann@zk3.dec.com BUGs in XSH Issue 6 (rdvk# 12) [JMXSH6-4] Tue, 5 Feb 2002 15:49:43 -0500 (EST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC1 candidate Append the following sentence at the end of line 13929: The AI_PASSIVE flag shall be ignored if the nodename argument is not null. _____________________________________________________________________________ Page: 425 Line: 13922-13929 Section: freeaddrinfo Problem: Defect code : 2. Omission The description of the AI_PASSIVE flag does not describe the behavior if the nodename is not null. The IETF IPv6 API specification states "This flag is ignored if the nodename argument is not null." Action: Append the following sentence at the end of line 13929: The AI_PASSIVE flag is ignored if the nodename argument is not null. _____________________________________________________________________________ COMMENT Enhancement Request Number 20 kleink@netbsd.org Defect in XSH fsetpos() (rdvk# 3) {KJK-2} Tue, 22 Jan 2002 13:04:21 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 443 Line: 14579 Section: fsetpos() Problem: (Ed: page and linenos corrected) Defect code : 1. Error The EINVAL failure description refers to an argument `whence'. This was apparently copied from the list of lseek() failures, and is not applicable to fsetpos(), which does not have such an argument or (or a differently named argument of equivalent functionality). Action: Delete EINVAL error. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 21 mccann@zk3.dec.com BUGs in XSH Issue 6 (rdvk# 9) [JMXSH6-1] Tue, 5 Feb 2002 15:49:43 -0500 (EST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC1 candidate _____________________________________________________________________________ Page: 481 Line: 15875-15883 Section: gai_strerror Problem: Defect code : 2. Omission EAI_OVERFLOW is missing from the list of known error codes. Action: Add a new line "[EAI_OVERFLOW]" between lines 15880 and 15881. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 22 mccann@zk3.dec.com BUGs in XSH Issue 6 (rdvk# 13) [JMXSH6-5] Tue, 5 Feb 2002 15:49:43 -0500 (EST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_____OPEN Rationale for rejected or partial changes: During the development of XNS5.2 it was felt that the flag need not be signed, and consensus would be reduced for it to be changed at this stage. _____________________________________________________________________________ Page: 526 Line: 17267 Section: getnameinfo Problem: Defect code : 1. Error The flags argument of the getnameinfo function should be of type 'int'. It is currently specified as 'unsigned'. The IETF IPv6 API specification has always specified type 'int'. Many implementations have implemented type 'int', including Solaris, Windows XP, AIX, Tru64 UNIX, HP-UX, FreeBSD, OpenBSD, NetBSD, and OpenVMS. The only implementation I have seen that uses 'unsigned' is GNU libc, which originally implemented using type 'int', but which changed to 'unsigned int' in January 2001. [Speculation: I suspect this was done in response to either an early draft of the austin spec, or in response to the XNS Issue 5.2 spec from which this bug was inherited.] The function prototype in also needs to be fixed, see related XBD bug report [JMXBD6-1]. Action: On line 17267 change "unsigned" to "int". _____________________________________________________________________________ EDITORIAL Enhancement Request Number 23 mccann@zk3.dec.com BUG in XSH Issue 6 (rdvk# 58) [JMXSH6-10] Tue, 30 Apr 2002 13:02:59 -0400 (EDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC1 candidate _____________________________________________________________________________ Page: 526 Line: 17281-17282,17292-17293 Section: getnameinfo Problem: Defect code : 2. Clarification When the text on lines 17272-17274 was added, it introduced an ambiguity about which address should be returned if the node's name cannot be located, or if the NI_NUMERICHOST flag is set. Action: Change the sentence that spans lines 17281-17282 to read: If the node's name cannot be located, the numeric form of the address contained in the socket address structure pointed to by the sa argument is returned instead of its name. Change the sentence on lines 17292-17293 to read: If the flag bit NI_NUMERICHOST is set, the numeric form of the address contained in the socket address structure pointed to by the sa argument shall be returned instead of its name, under all circumstances. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 24 mccann@zk3.dec.com BUGs in XSH Issue 6 (rdvk# 17) [JMXSH6-9] Tue, 5 Feb 2002 15:49:43 -0500 (EST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC1 candidate Insert the following text between lines 17297 and 17298, as a new bullet list item: If the flag bit NI_NUMERICSCOPE is set, the numeric form of the scope identifier shall be returned (for example, interface index) instead of its name. This flag shall be ignored if the sa argument is not an IPv6 address. _____________________________________________________________________________ Page: 526 Line: 17288-17305 Section: getnameinfo Problem: Defect code : 2. Omission The IETF IPv6 API specification defines a flag NI_NUMERICSCOPE for use with getnameinfo. This flag is missing from the Austin spec. The flag must also be added to , see related XBD bug report [JMXBD6-4]. Action: Insert the following text between lines 17297 and 17298, as a new bullet list item: If the flag bit NI_NUMERICSCOPE is set, the numeric form of the scope identifier shall be returned (for example, interface index) instead of its name. This flag is ignored if the sa argument is not an IPv6 address. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 25 mccann@zk3.dec.com BUGs in XSH Issue 6 (rdvk# 14) [JMXSH6-6] Tue, 5 Feb 2002 15:49:43 -0500 (EST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC1 candidate _____________________________________________________________________________ Page: 527 Line: 17312-17324 Section: getnameinfo Problem: Defect code : 2. Omission EAI_OVERFLOW is missing from the list of getnameinfo ERRORS. Action: Insert the following between lines 17323 and 17324: [EAI_OVERFLOW] An argument buffer overflowed. The buffer pointed to by the node argument or the service argument was too small. _____________________________________________________________________________ OBJECTION Enhancement Request Number 26 gwc@opengroup.org Defect in XSH getrlimit (rdvk# 32) [gwc RLIMIT_NOFILE+EMFILE] Sun, 14 Apr 2002 11:36:22 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC1 Candidate Accept action below Add to APP USAGE If a process attempts to set the hard limit or soft limit for RLIMIT_NOFILE to less than the highest currently open file descriptor +1 unexpected behavior may occur. _____________________________________________________________________________ Page: 551 Line: 18091 Section: getrlimit Problem: (This was previously discussed as bwg2001-014 shortly before draft 7 was produced. It didn't make it into draft 7, more for timing reasons than technical reasons, so I think it is worth raising again for TC1.) The use of "may fail" in the description of RLIMIT_NOFILE is inconsistent with other parts of the standard which require that an EMFILE error must occur when the RLIMIT_NOFILE soft limit is exceeded. From the remainder of the description of RLIMIT_NOFILE it is clear that when the soft limit has been reached, no more file descriptors can be opened. Therefore an attempt to open another file descriptor must fail, and according to section 2.3 "Error Numbers", the errno value which is set when a failure occurs due to this condition cannot be different from the one described in XSH for that condition - i.e. it must be EMFILE. Action: Change "may fail" to "shall fail" in the text "If this limit is exceeded, functions that allocate new file descriptors may fail with errno set to [EMFILE]." _____________________________________________________________________________ OBJECTION Enhancement Request Number 27 jonhitchcock@hotmail.com Defect in XSH gmtime (rdvk# 37) {jjh71} Thu, 18 Apr 2002 17:19:55 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: selection option 2 Rationale: ISO C alignment Also add EOVERFLOW as a shall fail error condition, with it CX shaded. (Ed note this needs further work to enumerate the wording for the error case) _____________________________________________________________________________ Page: 577 Line: 18969 Section: gmtime Problem: Defect code : 1. Error The gmtime() function is said to always return a pointer to a struct tm. This conflicts with the ISO C standard. The ISO C standard says that gmtime() returns a null pointer if the specified time cannot be converted to UTC. There are two reasons why this might happen: 1) the implementation cannot relate any time_t values to UTC, 2) the particular time_t value is invalid. POSIX.1-1996 relied on the C standard to specify gmtime(). But the current text is based on the old Single Unix Specification, which (like many Unix man pages) just said that gmtime() returns a pointer to a struct tm. This was probably because: 1) in POSIX, the time_t value is always related to UTC by the "seconds since the Epoch" expression. 2) with a 32-bit time_t it is impossible to have a value so large that the corresponding year cannot be held in an int, and the case of negative values was ignored. With a 64-bit time_t and a 32-bit tm_year it is possible to get an error. Action: Option 1: Add with CX-shading ", even if an error is detected" Option 2: Add "If an error is detected, gmtime() shall return a null pointer." Option 3: Add "If an error is detected, gmtime() may return a null pointer, unless the XSI extension is supported." (Note that there is a POSIX interpretation request (PASC 1003.1 #133) on gmtime_r() which would then make the description of the return value be the same as option 2.) _____________________________________________________________________________ COMMENT Enhancement Request Number 28 ajosey@opengroup.org Defect in XSH gmtime_r (rdvk# 48) {pasc-1003.1-133} Tue, 23 Apr 2002 11:54:50 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 577 Line: 18971 Section: gmtime_r Problem: Defect code : 1. Error (fwd'd from the PASC interps process which has now closed) The standard says gmtime_r() shall return a NULL pointer if "UTC is not available". But section 9945-1:1996 section 8.1 (page 206 lines 47-52) clearly states that in POSIX (unlike in ISO C) the relationship between the time_t argument to gmtime() and the resulting tm structure only depends on the "seconds since the Epoch" expression, and this should always be available. Action: The words "or UTC is not available," are unnecessary and confusing, and they should be removed. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 29 mccann@zk3.dec.com BUGs in XSH Issue 6 (rdvk# 15) [JMXSH6-7] Tue, 5 Feb 2002 15:49:43 -0500 (EST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC1 candidate _____________________________________________________________________________ Page: 593 Line: 19466 Section: if_indextoname Problem: Defect code : 1. Error IFNAMSIZ is not defined, should use IF_NAMESIZE from . Action: On line 19466, change "IFNAMSIZ" to "IF_NAMESIZE". _____________________________________________________________________________ EDITORIAL Enhancement Request Number 30 mccann@zk3.dec.com BUGs in XSH Issue 6 (rdvk# 16) [JMXSH6-8] Tue, 5 Feb 2002 15:49:43 -0500 (EST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC1 candidate _____________________________________________________________________________ Page: 603 Line: 19754-19755 Section: inet_ntop Problem: Defect code : 3. Clarification The description of the src argument of the inet_ntop function does not specify the byte-order of the address. The IETF IPv6 API specification states "the address must be in network byte order". Action: Append "; the address must be in network byte order" (not shaded) to the sentence on lines 19754-19755, so that it reads: The src argument points to a buffer holding an IPv4 address if the af argument is AF_INET, [IP6] or an IPv6 address if the af argument is AF_INET6[/IP6]; the address must be in network byte order. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 31 drepper@redhat.com Defect in XSH initstate() (rdvk# 30) {ud-21} Thu, 4 Apr 2002 01:22:44 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 606 Line: 19870 Section: initstate() Problem: Defect code : 1. Error The AppUsage current says: Threaded applications should use rand_r(), erand48(), [...] rand_r() definitely should not be recommended, it's the most useless RNG itnerface ever invented. Action: Remove rand_r(), from the line. _____________________________________________________________________________ COMMENT Enhancement Request Number 32 gwc@opengroup.org Defect in XSH lio_listio (rdvk# 34) [gwc lio_listio restrict] Tue, 16 Apr 2002 18:04:31 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: This prototype is following the rules defined for restrict (See Austin 45r1) _____________________________________________________________________________ Page: 683 Line: 22539 Section: lio_listio Problem: Defect code : 1. Error The use of restrict in the lio_listio() prototype is inconsistent with all the other uses of restrict in prototypes. Action: Change the second argument from: struct aiocb *restrict const list[restrict] to: struct aiocb *const list[restrict] Make the same change (minus the parameter name "list") to XBD6 P204 L7294. _____________________________________________________________________________ OBJECTION Enhancement Request Number 33 gwc@opengroup.org Defect in XSH localeconv (rdvk# 18) [gwc localeconv cs_precedes] Thu, 14 Feb 2002 16:08:14 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC1 candidate _____________________________________________________________________________ Page: 695 Line: 22885,22892 Section: localeconv Problem: Defect code : 1. Error The descriptions of p_cs_precedes and n_cs_precedes still contain references to int_curr_symbol. These should have been removed when the new members int_p_cs_precedes and int_n_cs_precedes were added. Action: On lines 22885 and 22892 delete "or int_curr_symbol". _____________________________________________________________________________ OBJECTION Enhancement Request Number 34 gwc@opengroup.org Defect in XSH localeconv (rdvk# 19) [gwc localeconv sep_by_space] Thu, 14 Feb 2002 16:08:14 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC1 candidate _____________________________________________________________________________ Page: 695 Line: 22888-22897 Section: localeconv Problem: Defect code : 1. Error The descriptions of p_sep_by_space and n_sep_by_space include details of the meanings of their values which are out of date and conflict with the new descriptions of the values on P696 L22928. Action: Replace lines 22888-22890 with the following: Set to a value indicating the separation of the currency_symbol, the sign string, and the value for a non-negative formatted monetary quantity. Replace lines 22895-22897 with the following: Set to a value indicating the separation of the currency_symbol, the sign string, and the value for a negative formatted monetary quantity. _____________________________________________________________________________ OBJECTION Enhancement Request Number 35 jonhitchcock@hotmail.com Defect in XSH localtime (rdvk# 36) {jjh72} Thu, 18 Apr 2002 17:21:38 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: selection option 2 Rationale: ISO C alignment Also add EOVERFLOW as a shall fail error condition, with it CX shaded. (Ed note: needs further work to enumerate the wording for the error case) Need to add a note to the EXAMPLES that error checking is omitted. localtime_r also needs to allow for the same error (also see gmtime changes for guidance) _____________________________________________________________________________ Page: 699 Line: 23037 Section: localtime Problem: Defect code : 1. Error The localtime() function is said to always return a pointer to a broken- down time structure, and the examples assume this. This conflicts with the ISO C standard. The ISO C standard says that localtime() returns a null pointer if the specified time cannot be converted to local time. There are two reasons why this might happen: 1) the implementation cannot relate any time_t values to local time, 2) the particular time_t value is invalid. POSIX.1-1996 relied on the C standard to specify localtime(). But the current text is based on the old Single Unix Specification, which (like many Unix man pages) just says that localtime() returns a pointer to the broken-down time structure. This was probably because: 1) in POSIX, the time_t value is always related to local time by the "seconds since the Epoch" expression and the timezone information. 2) with a 32-bit time_t it is impossible to have a value so large that the corresponding year cannot be held in an int, and the case of negative values was ignored. With a 64-bit time_t and a 32-bit tm_year it is possible to get an error. Action: Option 1: Add with CX-shading ", even if an error is detected" Option 2: Add "If an error is detected, localtime() shall return a null pointer." Option 3: Add "If an error is detected, localtime() may return a null pointer, unless the XSI extension is supported." Depending on which option is chosen, change the examples at lines 13651, 23054, 23069, 23083, 35939, 43309, 46677, 46696 to check for a null pointer. _____________________________________________________________________________ OBJECTION Enhancement Request Number 36 mgh@unican.es Defect in XSH (rdvk# 44) Tue, 23 Apr 2002 11:32:44 +0200 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Agreed, the editors may need to introduce an additional marker code, since it is problematic to have three codes in the synopsis margin. _____________________________________________________________________________ Page: 771 Line: 25175 Section: mmap() Problem: The mmap() function is only under the memory-mapped files (MF code) or the shared memory objects (SHM code) options, but should be also under the typed memory objects option (TYM code). It was under any of the three options in POSIX.1j. Action: Replace the codes MF|SHM in the synopsis section with the correct codes MF|SHM|TYM. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 37 drepper@redhat.com Defect in XSH modf() (rdvk# 26) {ud-7} Sat, 16 Mar 2002 06:31:09 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 778 Line: 25505 Section: modf() Problem: Defect code : 1. Error The example in the app usage for modf is: a = modf(x, &iptr) ; x == a+*iptr ; The first line suggests that iptr is of type double, the second line that it is of type double*. Action: The prototypes and the discussion in the RETURN VALUE section introduce iptr as of type double*. Be consistent, change the example to a = modf(x, iptr) ; x == a+*iptr ; (note the missing & in the first line). [Ed recommendation: Accept Recommend fix in TC1] _____________________________________________________________________________ OBJECTION Enhancement Request Number 38 mgh@unican.es Defect in XSH (rdvk# 45) Tue, 23 Apr 2002 11:32:44 +0200 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 817 Line: 26583 Section: munmap() Problem: The munmap() function is only under the memory-mapped files (MF code) or the shared memory objects (SHM code) options, but should be also under the typed memory objects option (TYM code). It was under any of the three options in POSIX.1j. Action: Replace the codes MF|SHM in the synopsis section with the correct codes MF|SHM|TYM. _____________________________________________________________________________ OBJECTION Enhancement Request Number 39 mgh@unican.es Defect in XSH (rdvk# 41) Tue, 23 Apr 2002 11:32:44 +0200 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 923 Line: 29616 Section: posix_trace_attr_setlogfullpolicy() Problem: The posix_trace_attr_setlogfullpolicy() is not listed under the Trace Log option (code TRL), but under trace inheritance (code TRI). This function is described under posix_trace_attr_getinherited() and the option in that section is correct. Action: Add the TRL and TRC codes to the posix_trace_attr_setlogfullpolicy() function synopsis. _____________________________________________________________________________ OBJECTION Enhancement Request Number 40 mgh@unican.es Defect in XSH (rdvk# 42) Tue, 23 Apr 2002 11:32:44 +0200 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 926 Line: 29648 Section: posix_trace_setstreamfullpolicy() Problem: The posix_trace_setstreamfullpolicy() function is incorrectly named as posix_trace_setlogfullpolicy() in the synopsis. This function is described under posix_trace_attr_getinherited() and the name in that section is correct. Action: Change the incorrect name posix_trace_setlogfullpolicy() into posix_trace_setstreamfullpolicy() _____________________________________________________________________________ OBJECTION Enhancement Request Number 41 mgh@unican.es Defect in XSH (rdvk# 43) Tue, 23 Apr 2002 11:32:44 +0200 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 944 Line: 30224 Section: posix_trace_flush() Problem: The posix_trace_flush() function is listed under the TRC (Tracing) option code only, but should also be under the TRL code (Trace log option). This function is described under posix_trace_create() and the option codes there are correct. Action: Add the missing TRL option code. _____________________________________________________________________________ OBJECTION Enhancement Request Number 42 mgh@unican.es Defect in XSH (rdvk# 40) Tue, 23 Apr 2002 11:32:44 +0200 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 953 Line: 30466 Section: posix_trace_open() Problem: posix_trace_open() and posix_trace_rewind() are wrongly listed under the TCT option code (thread cpu-time). They should be under the TRC option code (POSIX Tracing). These functions are described under posix_trace_close() and the option in that section is correct. Action: Change the TCT option code into the correct TRC code. _____________________________________________________________________________ OBJECTION Enhancement Request Number 43 mgh@unican.es Defect in XSH (rdvk# 39) Tue, 23 Apr 2002 11:32:44 +0200 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change the code TSA into the correct code TSS and correct the change history _____________________________________________________________________________ Page: 997 Line: 31631 Section: pthread_attr_getstacksize() Problem: The thread stack size functions pthread_attr_getstacksize() and pthread_attr_setstacksize() are listed under the thread stack address option (code TSA), but should be listed under the thread stack size option (code TSS) Action: Change the code TSA into the correct code TSS [Ed recommendation: Accept as marked as above, but also fix the change history] _____________________________________________________________________________ COMMENT Enhancement Request Number 44 terekhov@de.ibm.com Defect in XSH (rdvk# 51) {7} Mon, 29 Apr 2002 13:17:43 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: The group were unable to understand the problem statement. Please resubmit following the aardvark guidelines: specifically questions should be phrased against the standard with proposed solutions if possible. Problem statements must be standalone, so that reviewers not familiar with the problem can understand the statement . Until such changes are received in the form of a revised aardvark, and changes, if any, accepted at the next review, there is no action here that can be accepted as is. _____________________________________________________________________________ Page: 1065 Line: 33406-33408 Section: pthread_key_create Problem: Defect code : 3. Clarification required http://groups.google.com/groups?threadm=20020220231643.T86509-100000%40news1.macomnet.ru ("Subject: TSD key reusing issue" thread") [...] David Butenhof (David.Butenhof@compaq.com) wrote: ".... > Of course, a program which wants to destroy a key has to not only ensure > that no threads will ever try to use that key again, but also that > any resources associated with those keys are cleaned up too, since > the pthread_key_t registered destructors won't be run. Right. And the implementation can't (certainly shouldn't) help, including clearing TSD values, because that substantially increases the cost of ALL TSD access (by adding synchronization where none is otherwise needed, and where the standard definitely did not intend to require synchronization). >>> SUSv3, >>> http://www.opengroup.org/onlinepubs/007904975/functions/pthread_key_creat >>> e.html: >>> >>> "Upon key creation, the value NULL shall be associated with the new >>> key in all active threads. Upon thread creation, the value NULL shall >>> be associated with all defined keys in the new thread." >> >>This is the wording of the standard. The standard "says what it says", and >>conforming implementations are bound to implement what it says. However >>ridiculous and unsupportable that might be. That doesn't mean it's RIGHT. >>Conformance is a good goal. Blind conformance to errors is silly. > > This behavior supports what I believe is a common programming pattern. If > the slot is not null, then a thread has no way to know whether it contains > a value that it has previously stored there, or whether it is garbage. Absolutely. But the responsibility for setting the TSD value to NULL can only belong with the application; because only it can know when the resources it represents (if any) have been released. .... >>The standard does say that cleanup is the application's responsibility. I > > It also does not say that it's *not* the application's reponsibility. ;) > > Readers of the standard cannot afford to assume that their > responsibilities are limited to that which is explicitly spelled out. Depends on what's spelled out and how. In this case, it clearly SHOULD BE (and MUST BE) the application's responsibility, but the standard incorrectly requires behavior of the implementation that contradicts one of the most basic architectural intents of TSD. It is, inherently, "thread private" data that shouldn't require synchronization. The standard as currently written requires synchronization, and that's an error." [...] Alexander Terekhov (terekhov@web.de) wrote: ".... And, yes, I would have NO problems with a requirement to "manually" set TSD values to NULL in ALL threads prior to key destruction... BUT please spell this out *clearly* in the STANDARD[2] then! ...." Action: Uhmm... Are you going to argue against Butenhof? ;-) BTW, please note: 33528 The pthread_key_delete( ) function shall delete a thread-specific data key previously returned by 33529 pthread_key_create( ). The thread-specific data values associated with key need not be NULL at 33530 the time pthread_key_delete( ) is called. It is the responsibility of the application to free any 33531 application storage or perform any cleanup actions for data structures related to the deleted key 33532 or associated thread-specific data in any threads; this cleanup can be done either before or after 33533 pthread_key_delete( ) is called. Any attempt to use key following the call to pthread_key_delete( ) 33534 results in undefined behavior. [Ed recommendation: None The aardvark is malformed, specifically not being not self contained or coherent, and it would be quite understandable for the group to reject it on those grounds alone] _____________________________________________________________________________ OBJECTION Enhancement Request Number 45 mgh@unican.es Defect in XSH (rdvk# 55) Tue, 30 Apr 2002 18:14:18 +0200 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Recommend that this follow the route outlined for new submissions as per Austin/106 and forthcoming paper from the Chair. The following text will be put forward for TC1 as a result of this: Add to APP USAGE for pthread_rwlock_init Applications using these functions may be subject to priority inversion, as discussed in the Base Definitions volume of IEEE Std 1003.1-2001, Section 3.285, Priority Inversion. _____________________________________________________________________________ Page: 1107-1126 Line: 34679-35213 Section: pthread_rwlock_ Problem: The Reader/Writer locks defined in POSIX.1j were intended for shared memory multiprocessors, and they had no requirements for real-time behavior. For this reason no priority inheritance or priority ceiling mechanisms were specified for them, and thus applications using Reader/Writer locks may suffer from unbounded priority inversions, leading to delays that have a very low probability of ocurring, but can be very long and this is almost certainly unacceptable for real-time applications. The situation changed when Reader/Writer locks were made mandatory under the Threads option during the POSIX.1 revision. Because the POSIX.13 realtime profiles require the Threads option, Reader/Writer locks are also required now. We should fix these synchronization primitives so that they can also be usable inside applications with real-time requirements. Mutexes have three possible synchronization protocols: PTHREAD_PRIO_NONE: No priority inheritance; unbounded priority inversions are possible, and thus this option is for non-realtime PTHREAD_PRIO_INHERIT: Basic priority inheritance protocol. The thread owning on one of these mutexes inherits the priorities of other threads blocked on the mutex. This avoids unbounded priority inversions. But on multiprocessors it is well known that there is another source of unbounded priority inversion called "remote blocking" [1][2], by which a thread in one processor may block another thread in another processor for very long periods of time. PTHREAD_PRIO_PROTECT: This is the immediate priority ceiling protocol. The thread owning the mutex unconditionally inherits the priority ceiling of the mutex. Using the appropriate values for the ceilings, this protocol avoids both unbounded priority inversions and remote blocking [1][2]. Reader/Writer locks are used in applications that may run in multiprocessor systems (otherwise mutexes are equally useful). For this reason, basic priority inheritance is not appropriate because in multiprocessors we also need to address remote blocking. Consequently, the standard should specify the priority ceiling protocol for Reader/Writer locks, as an optional feature. Remote blocking occurs with mutually exclusive synchronization in multiprocessors. Suppose two threads (thread-A and thread-B) executing in two processors (P1 and P2, respectively) and contending for the same mutex. Suppose that thread A holds the mutex, and thread B is blocked waiting for it. The desirable case is that the maximum delay (also called blocking) experienced by thread B is the duration of the critical section, i.e., the time thread A is holding the mutex. Critical sections are usually designed to be very short, and this mininizes blocking. However in this case thread-A could be preempted by a higher priority thread-C executing in processor P1. In that case thread-B has to wait for the whole duration of thread-C (and perhaps for other threads also preempting, possibly multiple times). Priority inheritance does not solve the problem; in our example, thread-A would inherit the priority of thread-B, but thread-C can have higher priority and thus cause the long delay. The blocking time is no longer bounded by the duration of critical sections and this problem is just as bad as traditional uniprocessor unbounded priority inversion. The solution to the problem of remote blocking is to set a priority ceiling for the mutex that is high enough to prevent all undesired preemption effects during the critical sections. There is a lot of experience with Reader/Writer locks and the priority ceiling in Ada, because Ada's protected objects have the same multiple-readers-single-writer semantics as the POSIX Reader/Writer locks. The Solaris kernel has inversion-proof reader/writer locks. References [1] R. Rajkumar, L. Sha, and J.P. Lehoczky. "Real-Time Synchronization Protocols for Multiprocessors". IEEE Real-Time Systems Symposium, December 1988. [2] R. Rajkumar. "Real-Time Synchronization Protocols for Shared Memory Multiprocessors". Proceedings of the 10th International Conference on Distributed Computing, 1990. Action: If the Thread Priority Protection option is supported, two additional attributes should be added to Reader/Writer locks: protocol, and prioceiling. Protocol should be able to have the values PTHREAD_PRIO_NONE or PTHREAD_PRIO_PROTECT (but not PTHREAD_PRIO_INHERIT). The semantics of these two attributes should be the same as for mutexes. The presence of these attributes implies two functions to set the attributes, and another two functions to get them. In addition, a function to dynamically set the priority ceiling and another one to get it should be added, with the same semantics as for the mutexes. Note The requested action may seem too important for a technical corrigenda. In that case, the POSIX Realtime System Services Working Group would like to take this action as a work item for a future amendment to the standard. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 46 ajosey@opengroup.org Defect in XSH pthread_rwlockattr_init (rdvk# 21) {tog-19-feb-1} Tue, 19 Feb 2002 10:29:42 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC1 candidate _____________________________________________________________________________ Page: 1125 Line: 35199 Section: pthread_rwlockattr_init Problem: Defect code : 1. Error The XSI margin code on this pointer page should be THR Action: Change the XSI margin code to THR _____________________________________________________________________________ EDITORIAL Enhancement Request Number 47 ajosey@opengroup.org Defect in XSH pthread_rwlockattr_setpshared (rdvk# 20) {tog-19-feb-2} Tue, 19 Feb 2002 10:33:58 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC1 candidate _____________________________________________________________________________ Page: 1126 Line: 35208 Section: pthread_rwlockattr_setpshared Problem: Defect code : 1. Error The XSI margin code on this pointer page should be THR TSH Action: Change the XSI margin code to THR TSH _____________________________________________________________________________ OBJECTION Enhancement Request Number 48 jeroen@dekkers.cx Defect in XSH realpath() (rdvk# 57) {1} Tue, 30 Apr 2002 19:13:31 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add "If resolved_name is a null pointer, the behavior of realpath() is implementation defined" to the desciption. Change the reason of returning EINVAL to "The file_name argument is a null pointer". Add to FUTURE DIRECTIONS In the future passing a null pointer to realpath() for the resolved_name argument may be defined to have realpath() allocate space for the generated pathname. Add to RATIONALE: Copy getcwd rationale, from line 16171-16172 "Since the maximum pathname length is arbitrary .... +1}." _____________________________________________________________________________ Page: 1185-1186 Line: 0 Section: realpath() Problem: Defect code : 1. Error The realpath() function depends on the existence of PATH_MAX, however PATH_MAX is optional and implementations don't have to define it when they don't have a limit. Because there doesn't exist a limit, pathconf("/", _PC_PATH_MAX) returns -1. There is no way to be sure you have enough bytes in the buffer passed to realpath(), so there is always the danger of a buffer overflow! Action: Make the behavior unspecified if a NULL pointer is passed so that an implementation could malloc the buffer. Add "If resolved_name is a null pointer, the behavior of realpath() is unspecified" to the desciption. Change the reason of returning EINVAL to "The file_name argument is a null pointer". The rationale of getcwd() could be copied to describe why this behavior is unspecified. _____________________________________________________________________________ OBJECTION Enhancement Request Number 49 drepper@redhat.com Defect in XSH qsort (rdvk# 8) {ud-2} Tue, 29 Jan 2002 18:23:34 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC1, c99 alignment Add at the end of line 36047: /nel/ can have the value zero on a call to that function; the comparison function is not called and no rearrangement are made. Add at line 36048 the new paragraphs: The implementation shall ensure that both arguments are pointers to elements of the array. The comparison function shall not alter the contents of the array. The implementation may reorder elements of the array between calls to the comparison function, but shall not alter the contents of any individual element. The implementation shall ensure that the first argument is always a pointer to the key. When the same objects (consisting of size bytes, irrespective of their current positions in the array) are passed more than once to the comparison function, the results shall be consistent with one another. That is, they shall define a total ordering on the array. Replace line 36064 with: The requirement that both arguments to the comparison function are pointers to elements of the array implies that for every call all of the following expressions are nonzero: ((char *)p - (char *)base) % size == 0 (char *)p >= (char *)base (char *)p < (char *)base + nel * size _____________________________________________________________________________ Page: 1160 Line: 36047 Section: qsort Problem: Defect code : 2. Omission The introduction to the header in ISO C99 contains the words (section 7.20.5): ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 These utilities make use of a comparison function to search or sort arrays of unspecified type. Where an argument declared as size_t nmemb specifies the length of the array for a function, nmemb can have the value zero on a call to that function; the comparison function is not called, a search finds no matching element, and sorting performs no rearrangement. Pointer arguments on such a call shall still have valid values, as described in 7.1.4 2 The implementation shall ensure that the second argument of the comparison function (when called from bsearch), or both arguments (when called from qsort), are pointers to elements of the array.254) The first argument when called from bsearch shall equal key. 3 The comparison function shall not alter the contents of the array. The implementation may reorder elements of the array between calls to the comparison function, but shall not alter the contents of any individual element. 4 When the same objects (consisting of size bytes, irrespective of their current positions in the array) are passed more than once to the comparison function, the results shall be consistent with one another. That is, for qsort they shall define a total ordering on the array, and for bsearch the same object shall always compare the same way with the key. 5 A sequence point occurs immediately before and immediately after each call to the comparison function, and also between any call to the comparison function and any movement of the objects passed as arguments to that call. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The qsort man pages should contain the same information. Action: Add at the end of line 36047: /nel/ can have the value zero on a call to that function; the comparison function is not called and no rearrangement are made. Add at line 36048 the new paragraphs: The implementation shall ensure that both arguments are pointers to elements of the array. The comparison function shall not alter the contents of the array. The implementation may reorder elements of the array between calls to the comparison function, but shall not alter the contents of any individual element. When the same objects (consisting of size bytes, irrespective of their current positions in the array) are passed more than once to the comparison function, the results shall be consistent with one another. That is, they shall define a total ordering on the array. Replace line 36064 with: The requirement that both arguments to the comparison function are pointers to elements of the array implies that for every call all of the following expressions are nonzero: ((char *)p - (char *)base) % size == 0 (char *)p >= (char *)base (char *)p < (char *)base + nel * size I'm not sure whether the comment about the sequence points is needed as well. ISO C defines them carefully but it is avoided so far in this document. _____________________________________________________________________________ OBJECTION Enhancement Request Number 50 mgh@unican.es Defect in XSH (rdvk# 46) Tue, 23 Apr 2002 11:32:44 +0200 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC1 candidate _____________________________________________________________________________ Page: 1228 Line: 38226 Section: sched_get_priority_max() Problem: The sched_get_priority_max() and sched_get_priority_min() functions are required for the application to determine the range of priorities that are valid for a given scheduling policy, such as SCHED_FIFO. If these functions are not present, it is not possible for an application to determine which are the valid priorities (for example, an implementation might legally use a range between 337-369 for some obscure reason). The problem is that these functions are not required under the thread priority scheduling option (TPS code); they are only required under the process priority scheduling option. Therefore, it is not possible to write a strictly conforming application that sets its priority for an implementation supporting thread priority scheduling but not process priority scheduling (as mandated for example in the POSIX.13 small realtime profiles). This problem was also present in POSIX.1-1996, but was not discovered until the first implementations of the POSIX.13 minimal realtime system profile. Action: Change the PS code in the synopsis of these two functions into PS|TPS (process priority scheduling or thread priority scheduling) _____________________________________________________________________________ OBJECTION Enhancement Request Number 51 mgh@unican.es Defect in XSH (rdvk# 47) Tue, 23 Apr 2002 11:32:44 +0200 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC1 candidate _____________________________________________________________________________ Page: 1231 Line: 38343 Section: sched_rr_get_interval() Problem: The sched_rr_get_interval() function is required for the application to determine the interval for the round robin scheduler. If this function is not present, it is not possible for an application to determine which is this interval. The problem is that this function is not required under the thread priority scheduling option (TPS code); it is only required under the process priority scheduling option. Therefore, it is not possible to write a strictly conforming application that uses the round robin interval, for an implementation supporting thread priority scheduling but not process priority scheduling (as mandated for example in the POSIX.13 small realtime profiles). This problem was also present in POSIX.1-1996, but was not discovered until the first implementations of the POSIX.13 minimal realtime system profile. Action: Change the PS code in the synopsis of this function into PS|TPS (process priority scheduling or thread priority scheduling) _____________________________________________________________________________ OBJECTION Enhancement Request Number 52 bmark@us.ibm.com Defect in XSH setpgid (rdvk# 49) {1} Thu, 25 Apr 2002 18:39:10 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC1 candidate Change "Also, if pgid is 0, the process group ID of the indicated process shall be used." to "Also, if pgid is 0, the process ID of the indicated process shall be used." rationale revert to posix.1-1996 wording, appears to be an unintended change. _____________________________________________________________________________ Page: 1299 Line: 40351 Section: setpgid Problem: Defect code : 1. Error This specification states: "Also, if pgid is 0, the process group ID of the indicated process shall be used." 1003.1-1996 states (P.104, sec 4.3.3.2): "Also, if pgid is zero, the process ID of the indicated process shall be used." Did we mean to do this? I note that SUSv2 also has the newer wording. I also note that the SUS test suites do not test this, either way. Action: In the absence of an interpretation declaring otherwise, please use the 1003.1-1996 wording. _____________________________________________________________________________ COMMENT Enhancement Request Number 53 alevn@rambler.ru Defect in XSH sigaction (rdvk# 53) {N/A} Tue, 30 Apr 2002 08:58:50 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: This will be forwarded down the interpretations track. Proposed Interpretation On systems that do support realtime signals but do not support SA_SIGINFO on signals not in the range SIGRTMIN..SIGRTMAX (non realtime signals), ENOTSUP is a valid error when SA_SIGINFO is requested on the non realtime signals. Proposed future direction (not part of the interpretation) Add a may fail error The SA_SIGINFO flag is set in the sa_flags field of the sigaction structure for a signal not in the range SIGRTMIN through SIGRTMAX. The future direction may be also be a TC1 candidate (TBD later in the process) _____________________________________________________________________________ Page: 1341 Line: 41562 Section: sigaction Problem: (Ed has corrected page and lineno to final text) Defect code : 3. Clarification required The standard says: [ENOTSUP] The SA_SIGINFO flag is set in the sa_flags field of the sigaction structure, and the implementation does not support either the Realtime Signals Extension option, or the X/Open System Interfaces Extension option. It is not clear if the same errno value should be expected if the implementation does not support realtime behavior for certain signals (e.g. if the returning of additional information is provided only for realtime signals SIGRTMIN..SIGRTMAX). The relevant quote permitting the implementation to behave in such way is XBD, pages 301-302 (signal.h), lines 10751-10758: This header shall also declare macros SIGRTMIN and SIGRTMAX, ... ... It is implementation-defined whether realtime signal behavior is supported for other signals. Thank you for clarification. Regards, Alexey. Action: Ideally, such situation should be described as a reason for ENOTSUP/other errno values in the sigaction's description. _____________________________________________________________________________ OBJECTION Enhancement Request Number 54 drepper@redhat.com Defect in XSH sigaltstack() (rdvk# 22) {ud-5} Wed, 27 Feb 2002 04:01:26 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC1 candidate Agree that the alternate signal stack is per thread, go with option 1. _____________________________________________________________________________ Page: 1345 Line: 41764 Section: sigaltstack() Problem: Defect code : 2. Omission The sigaltstack() definition currently says wrt to threads only the following: Use of this function by library threads that are not bound to kernel-scheduled entities results in undefined behavior. This is not enough IMO. At least not without clarifications. The above statement only makes sense if alternate stacks are per-thread. This isn't stated anywhere, though. And the pthread_create desription doesn't say anything about inherinting or resetting the alternate stack either. Alternatively, if alternate stack are per-process, this function and alternate stack cannot be used at all. More than one signal can be handled by various threads of a process at the same time which would require the same alternate stack be used by multiple threads at the same time. Action: Two alternatives: If alternate stacks are per-thread, say this explicitlly. Add to the first sentence in line 41735: for the current thread Also in the pthread_create man page add as a new line 32853: The alternate stack is not inherited. Mark this sentence XSI Second alternative: If thread are per-process add to the sentence in the lines 41764-41675 with: sigaltstack() can be used in multi-threaded applications only if it can be made sure that never more than one signal is processed at any one time. And in the rational: Since the requirement that only one signal at any one time can be processed in multi-threaded applications can (almost) never be fulfilled this function effectively cannot be used in multi- threaded applications. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 55 drepper@redhat.com Defect in XSH siginterrupt() (rdvk# 23) {ud-4} Wed, 27 Feb 2002 03:12:06 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC1 candidate _____________________________________________________________________________ Page: 1353 Line: 42015 Section: siginterrupt() Problem: Defect code : 1. Error ISO C99 does not allow implicit ints anymore. Therefore add the missing return value for the example implementation. Action: Insert 'int' before siginterrupt in line 42015. _____________________________________________________________________________ COMMENT Enhancement Request Number 56 lennox@cs.columbia.edu Defect in XSH strftime() (rdvk# 4) {2} Wed, 16 Jan 2002 02:02:27 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC1 candidate Add the following text, highlighted with a CX indicator, after 44059 on p 1424 If a 'struct tm' broken-down time structure is created by localtime() or localtime_r(), or modified by mktime(), and the value of TZ is subsequently modified, the results of the %Z and %z strftime() conversion specifiers is undefined, when strftime() is called with such a broken-down time structure. If a 'struct tm' broken-down time structure is created or modified by gmtime() or gmtime_r(), it is unspecified whether the result of the %Z and %z conversion specifiers shall refer to UTC or the current local time zone, when strftime() is called with such a broken-down time structure. _____________________________________________________________________________ Page: 1423 Line: 44053 Section: strftime() Problem: (Ed has corrected page and lineno) Defect code : 2. Omission (This is an update for the revised POSIX specification of PASC interpretation request #135 against 1003.1-1996.) The specification is unclear on the meaning of the %Z and %z strftime() specifiers, in some circumstances. This is an area which multiple Unix systems implement differently. 1. The specification is unclear on what happens to existing local-time-related data, when the environment variable 'TZ' is changed. In particular, the indended result is unclear in the following situation: * mktime(), localtime(), or localtime_r() create or modify a 'struct tm' value. * The 'TZ' environment variable is altered. * strftime() is called with the %Z or %z conversion specifiers, with the old 'struct tm' as an argument. Some Unix platforms store time zone information in private fields within a 'struct tm', and thus output the old time zone. Some use a global variable, and thus output the new time zone. Some platforms store a pointer to a current time zone object, and thus may output invalid data. 2. Similarly, the correct behavior of the %Z and %z conversion specifiers of strftime() is unclear for 'struct tm' values representing UTC times. If a struct tm is created or altered by gmtime() or gmtime_r(), it is not clear whether strftime() should output a representation of the name or offset of the current local time zone, or a representation of Coordinated Universal Time in the current locale. Again, Unix platforms behave differently on this issue, depending on whether time zone information is stored inside struct tm. Action: Add the following text, highlighted with a CX indicator, to the descriptions of the %Z and %z strftime conversion specifiers (or else elsewhere within the description of strftime().) If a 'struct tm' broken-down time structure is created by localtime() or localtime_r(), or modified by mktime(), and the value of TZ is subsequently modified, the results of the %Z and %z strftime() conversion specifiers is undefined, when strftime() is called with such a broken-down time structure. If the broken-down time structure is subsequently modified by a successful call to mktime() or localtime_r(), the results of these conversion specifiers are once again defined. If a 'struct tm' broken-down time structure is created or modified by gmtime() or gmtime_r(), it is undefined whether the result of the %Z and %z conversion specifiers shall refer to UTC or the current local time zone, when strftime() is called with such a broken-down time structure. _____________________________________________________________________________ OBJECTION Enhancement Request Number 57 gwc@opengroup.org Defect in XSH sysconf (rdvk# 24) [gwc OPEN_MAX&RLIMIT_NOFILE] Sun, 3 Mar 2002 18:13:01 +0000 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC1 candidate After "during the lifetime of the calling process" append ", except that sysconf(_SC_OPEN_MAX) may return different values before and after a call to setrlimit() which changes the RLIMIT_NOFILE soft limit", with the new text shaded XSI. _____________________________________________________________________________ Page: 1469 Line: 45442 Section: sysconf Problem: Defect code : 1. Error POSIX.1 has always said that the value returned by multiple calls to sysconf(_SC_OPEN_MAX) in one process must not change over the lifetime of the process. However, existing practice on several systems is that after a call to setrlimit(RLIMIT_NOFILE, ...) the return value of sysconf(_SC_OPEN_MAX) does change (to the new soft limit). Before the merger of POSIX.1 and SUS this behaviour could perhaps have been considered to be POSIX conforming, because setrlimit() was an extension. However, now setrlimit() is part of POSIX.1-2001 it appears that, as things stand now, this behaviour is not allowed. There are several possible solutions, but they can be divided into two types: A. Reaffirm what the current spec. appears to say. Systems where sysconf(_SC_OPEN_MAX) returns the RLIMIT_NOFILE soft limit would have to be changed so that OPEN_MAX is an absolute limit, independent of RLIMIT_NOFILE. B. Change the spec. so that the value returned by sysconf(_SC_OPEN_MAX) is allowed to change over the lifetime of the process. There are several different variants of this, depending on how the value is allowed to change, what extra requirements are made to ensure that open fd's higher than the OPEN_MAX limit cannot exist, and whether a means of finding out information about open fd's is provided. For a type B solution, it is not enough just to change the spec. to allow the value returned by sysconf(_SC_OPEN_MAX) to vary. On its own this change would create a secondary problem whereby applications could have an fd open (e.g. inherited from the parent) which is larger than the maximum indicated by sysconf(_SC_OPEN_MAX). If this problem is not addressed, applications will have no portable way to find a reliable maximum fd value. Many existing applications assume that sysconf(_SC_OPEN_MAX) is a reliable maximum and use it, for example, to close all (unwanted) open fd's in situations where they cannot be sure what fd's might be open. Following discussions on the Austin Group mailing list, it is apparent that there is a lot of support for a type B solution, but it looks unlikely that consensus could be reached on the details of the best solution. Therefore, I think that it would be best not to try and specify any details - just make the minimum changes necessary to resolve the problem, and leave the details up to the implementation. Once the value returned by sysconf(_SC_OPEN_MAX) is allowed to vary, the minimum extra requirement necessary to ensure that open fd's higher than the OPEN_MAX limit cannot exist is simply to state that sysconf(_SC_OPEN_MAX) must return a value greater than the highest open fd. Implementations can comply with this either by having an absolute OPEN_MAX limit (independent of RLIMIT_NOFILE), or by making setrlimit() give an error if the new soft limit is lower than the current highest open fd (plus 1), or by making sysconf(_SC_OPEN_MAX) return the greater of the soft limit and (highest_open_fd + 1). Action: After "during the lifetime of the calling process" append ", except that sysconf(_SC_OPEN_MAX) may return different values before and after a call to setrlimit() which changes the RLIMIT_NOFILE soft limit", with the new text shaded XSI. After this sentence add (not shaded) "The value returned by sysconf(_SC_OPEN_MAX) shall be either -1 or a value greater than the highest currently open file descriptor." _____________________________________________________________________________ COMMENT Enhancement Request Number 58 ajosey@opengroup.org Defect in XSH unlink (rdvk# 31) {unlink-eisdir} Wed, 10 Apr 2002 16:15:57 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: The standard is clear. Only EPERM is defined for this error. This should be forwarded down the interpretations track. Proposed interpretation: The standard clearly states that unlink() on a directory should return EPERM for this condition,and conforming implementations must conform to this. Rationale: To make a change would reduce the consensus. _____________________________________________________________________________ Page: 1555 Line: 47966 Section: unlink Problem: Defect code : 3. Clarification required The unlink() function defines the following error condition [EPERM] The file named by path is a directory, and either the calling process does not have appropriate privileges, or the implementation prohibits using unlink() on directories. The EISDIR error condition would also seem an appropriate error to return in the case when unlink() is attempted on a directory. Is an implementation conforming that returns EISDIR rather than EPERM ? A certain body of implementors believe that this is the more natural error code to expect in this case. Action: Proposed interpretation: The standard is clear on the requirements, however concerns should be forwarded to the sponsor to consider allowing the EISDIR error. Proposed rationale: Applications receiving an error should be able to cope with any unexpected error code. The EISDIR code would seem a logical return. _____________________________________________________________________________ OBJECTION Enhancement Request Number 59 joannaf@sun.com Defect in XSH getsubopt (rdvk# 59) {Sun-jf-cm1} Mon, 25 Mar 2002 13:24:15 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "tokens" to "keylistp" on line 18449. TC1 candidate _____________________________________________________________________________ Page: 9999 Line: 18449 Section: getsubopt Problem: (really page 563 line 18449 section getsubopt objection {Sun-jf-cm1}, added at the end by Ed, since rdvk had missed this item filed on Mar 25) Defect code : 1. Error The Synopsis shows the second argument of getsubopt() to be called "token". In the Description though there is no description of an argument called "token" but there is of an argument called "keylistp" that is not in the Synopsis. It is believed they are refering to the same argument. Action: Change "token" to "keylistp" on line 18449. Or Change "keylistp" to "token" on lines 18457,18460,18462 and 18478.