Minutes of the 6 August 2015 Teleconference Austin-724 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 7th August 2015 Attendees: Joerg Schilling, FOKUS Fraunhofer Eric Blake, Red Hat Mark Ziegast, SHware Systems Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR Andrew Josey, The Open Group Don Cragun, IEEE PASC OR Geoff Clare, The Open Group Jim Grisanzio, Oracle Roger Faulkner, Oracle, The Open Group OR David Clissold, IBM (partial last 30 min) Apologies: Richard Hansen, BBN Martin Rehak, Oracle * General news Andrew noted that the invitation to join the IEEE ballot pool closes next week, and also that the editing for the merged draft is underway. * Outstanding actions ( Please note that this section has been flushed to shorten the minutes - to locate the previous set of outstanding actions, look to the minutes from 26 Feb 2015) Bug 0000887: printf and other functions appear many times in search results OPEN http://austingroupbugs.net/view.php?id=887 Andrew is investigating. Bug 0000900: add qsort_r OPEN http://austingroupbugs.net/view.php?id=900 The consensus was that its a good idea to add the suggested interface. The usual requirements regarding a sponsor for a new interface apply. Action: Open Group OR , to ask the Base WG if they wish to sponsor the additional qsort interface proposed here. Bug 0000901: reserve _POSIX* shell option namespace for future use OPEN http://austingroupbugs.net/view.php?id=901 The forward plan for this bug remains as before: Richard: file a new bug report with a concrete feature that would use the _POSIX* namespace (as motivation for reserving set -o _POSIX*) All: debate the proposed feature. If it's something we want, then revisit bug #901. If not, close bug #901. Bug 0000922: Implementations should be allowed to change/remove implementation-defined environment variables OPEN http://austingroupbugs.net/view.php?id=922 This item remains open. Action on Eric: propose wording for Issue 8 to add secure_getenv(), and make it clear that deleting from environment without explicit request is not compliant, but ignoring is fine. For Issue 7 TC 2: Create new bug to add additional conditions on what makes TMPDIR valid, vs. undefined behavior; also add future directions to getenv() to mention secure_getenv() * Current Business Bug 0000960: export can fail Accepted as marked http://austingroupbugs.net/view.php?id=960 This item is tagged for TC2-2008 An interpretation is required. Interpretation response: The standard is unclear on this issue, and no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Rationale: The standard was unclear whether certain shell special builtins must have exit status of 0, or whether the overall rule for non-zero status after error detection applied. Existing shells have non-zero status after errors. Notes to the Editor (not part of this interpretation): Make the following changes: At page 2370 line 75534 [XCU exit EXIT STATUS], change The exit status shall be n, if specified. to The exit status shall be n, if specified, except that the behavior is unspecified if n is not an unsigned decimal integer or is greater than 255. At page 2371 line 75552 [XCU exit RATIONALE], add a new paragraph: The behavior of exit when given an invalid argument or unknown option is unspecified, because of differing practices in the various historical implementations. A value larger than 255 might be truncated by the shell, and be unavailable even to a parent process that uses waitid() to get the full exit value. It is recommended that implementations that detect any usage error should cause a non-zero exit status (or, if the shell is interactive and the error does not cause the shell to abort, store a non-zero value in $?), but even this was not done historically in all shells. At page 2373 line 75609 [XCU export EXIT STATUS], change Zero. to 0 All name operands were successfully exported. >0 At least one name could not be exported, or the -p option was specified and an error occurred. At page 2373 line 75613 [XCU export APPLICATION USAGE], change None. to Note that, unless X was previously marked readonly, the value of $? after export X=$(false) will be 0 (because export successfully set X to the empty string) and that execution continues, even if set -e is in effect. In order to detect command substitution failures, a user must separate the assignment from the export, as in X=$(false) export X At page 2376 line 75695 [XCU readonly EXIT STATUS], change Zero. to 0 All name operands were successfully marked readonly. >0 At least one name could not be marked readonly, or the -p option was specified and an error occurred. At page 2378 line 25759 [XCU return EXIT STATUS], change If the value of n is greater than 255, the results are undefined. to If n is not an unsigned integer, or is greater than 255, the results are unspecified. At page 2383 line 75944 [XCU set EXIT STATUS], change Zero. to 0 Successful completion. >0 An invalid option was specified, or an error occurred. At page 2389 line 76171 [XCU times EXIT STATUS], change Zero. to 0 Successful completion. >0 An error occurred. Bug #972: PTHREAD_PROCESS_PRIVATE: definition too weak to allow for optimization Accepted as Marked. http://austingroupbugs.net/bug_view_page.php?bug_id=972 This bug is tagged for TC2-2008. An interpretation is required. Interpretation response: The standard states that barriers, condition variables, mutexes, reader-writer locks, semaphores and spin locks using PTHREAD_PROCESS_PRIVATE (or equivalent pshared argument) must be able to treat multiple mappings of an object as the same object, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Rationale: Most implementations of these private barriers, condition variables, mutexes, reader-writer locks, semaphores and spin locks use the address of the object to locate the object when using PTHREAD_PROCESS_PRIVATE (or equivalent pshared argument). The optimizations that can be performed when an object is not shared with other processes disappear if multiple mappings of one of these objects are allowed in this case. (If a process needs multiple mappings of an object, it can use PTHREAD_PROCESS_SHARED instead of PTHREAD_PROCESS_PRIVATE to get the desired behavior.) Notes to the Editor (not part of this interpretation): On page 522 after line 18031 insert a new section: 2.9.9 Synchronization Object Copies and Alternative Mappings For barriers, condition variables, mutexes, and read-write locks, [TSH]if the process-shared attribute is set to PTHREAD_PROCESS_PRIVATE,[/TSH] only the synchronization object at the address used to initialize it can be used for performing synchronization. The effect of referring to another mapping of the same object when locking, unlocking, or destroying the object is undefined. [TSH]If the process-shared attribute is set to PTHREAD_PROCESS_SHARED, only the synchronization object itself can be used for performing synchronization; however, it need not be referenced at the address used to initalize it (that is, another mapping of the same object can be used).[/TSH] The effect of referring to a copy of the object when locking, unlocking, or destroying it is undefined. For spin locks, the above requirements shall apply as if spin locks have a process-shared attribute that is set from the pshared argument to pthread_spin_init(). For semaphores, the above requirements shall apply as if semaphores have a process-shared attribute that is set to PTHREAD_PROCESS_PRIVATE if the pshared argument to sem_init() is zero and set to PTHREAD_PROCESS_SHARED if pshared is non-zero. On page 1576 lines 51134-51136 section pthread_barrier_destroy(), change from: Only the object referenced by barrier may be used for performing synchronization. The result of referring to copies of that object in calls to pthread_barrier_destroy() or pthread_barrier_wait() is undefined. to: See [xref to section 2.9.9] for further requirements. On page 1582 lines 51293-51296 section pthread_barrierattr_getpshared(), change from: If the process-shared attribute is PTHREAD_PROCESS_PRIVATE, the barrier shall only be operated upon by threads created within the same process as the thread that initialized the barrier; if threads of different processes attempt to operate on such a barrier, the behavior is undefined. to: See [xref to section 2.9.9] for further requirements. On page 1596 lines 51751-51753 section pthread_cond_destroy(), change from: Only cond itself may be used for performing synchronization. The result of referring to copies of cond in calls to pthread_cond_wait(), pthread_cond_timedwait(), pthread_cond_signal(), pthread_cond_broadcast(), and pthread_cond_destroy() is undefined. to: See [xref to section 2.9.9] for further requirements. On page page 1611 lines 52252-52255 section pthread_condattr_getpshared(), change from: If the process-shared attribute is PTHREAD_PROCESS_PRIVATE, the condition variable shall only be operated upon by threads created within the same process as the thread that initialized the condition variable; if threads of differing processes attempt to operate on such a condition variable, the behavior is undefined. to: See [xref to section 2.9.9] for further requirements. On page 1643 lines 53256-53258 section pthread_mutex_destroy(), change from: Only mutex itself may be used for performing synchronization. The result of referring to copies of mutex in calls to pthread_mutex_lock(), pthread_mutex_trylock(), pthread_mutex_unlock(), and pthread_mutex_destroy() is undefined. to: See [xref to section 2.9.9] for further requirements. On page 1672 lines 54249-54252 section pthread_mutexattr_getpshared(), change from: If the process-shared attribute is PTHREAD_PROCESS_PRIVATE, the mutex shall only be operated upon by threads created within the same process as the thread that initialized the mutex; if threads of differing processes attempt to operate on such a mutex, the behavior is undefined. to: See [xref to section 2.9.9] for further requirements. On page 1686 lines 54576-54579 section pthread_rwlock_destroy(), change from: Only the object referenced by rwlock may be used for performing synchronization. The result of referring to copies of that object in calls to pthread_rwlock_destroy(), pthread_rwlock_rdlock(), pthread_rwlock_timedrdlock(), pthread_rwlock_timedwrlock(), pthread_rwlock_tryrdlock(), pthread_rwlock_trywrlock(), pthread_rwlock_unlock(), or pthread_rwlock_wrlock() is undefined. to: See [xref to section 2.9.9] for further requirements. On page 1704 lines 55075-55078 section pthread_rwlockattr_getpshared(), change from: If the process-shared attribute is PTHREAD_PROCESS_PRIVATE, the read-write lock shall only be operated upon by threads created within the same process as the thread that initialized the read-write lock; if threads of differing processes attempt to operate on such a read-write lock, the behavior is undefined. to: See [xref to section 2.9.9] for further requirements. On page 1720 lines 55469-55473 section pthread_spin_destroy(), change from: [TSH]If the Thread Process-Shared Synchronization option is supported and the value of pshared is PTHREAD_PROCESS_PRIVATE,[/TSH] or if the option is not supported, the spin lock shall only be operated upon by threads created within the same process as the thread that initialized the spin lock. If threads of differing processes attempt to operate on such a spin lock, the behavior is undefined. to: See [xref to section 2.9.9] for further requirements. On page 1832 lines 59000-59002 section sem_init(), delete: Only sem itself may be used for performing synchronization. The result of referring to copies of sem in calls to sem_wait(), sem_timedwait(), sem_trywait(), sem_post(), and sem_destroy() is undefined. On page 1832 lines 59005-59006 section sem_init(), change from: The use of the semaphore by threads other than those created in the same process is undefined. to (as a new paragraph): See [xref to section 2.9.9] for further requirements. Bug #973: paste -s description omits behaviour for empty files Accepted http://austingroupbugs.net/view.php?id=973 This item is tagged for TC2-2008. An interpretation is required. Interpretation response: The standard does not speak to this issue, and as such no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Rationale: The description of paste -s does not say what happens if an input file is empty. Existing practice is to write an empty line for that file. Notes to the Editor (not part of this interpretation): On Page: 3016 Line: 100085 Section: paste In the OPTIONS section, for the -s option change from: Concatenate all of the lines of each separate input file in command line order. The of every line except the last line in each input file shall be replaced with the , unless otherwise specified by the -d option. to: Concatenate all of the lines from each input file into one line of output per file, in command line order. The of every line except the last line in each input file shall be replaced with a , unless otherwise specified by the -d option. If an input file is empty, the output line corresponding to that file shall consist of only a character. Next Steps ---------- The next call is on August 13, 2015 (a Thursday) Andrew will bring up the bridge Calls are anchored on US time. (8am Pacific) This call will be for the regular 90 minutes. http://austingroupbugs.net An IRC channel will be available for the meeting irc://irc.freenode.net/austingroupbugs An etherpad is usually up for the meeting, with a URL using the date format as below: http://posix@posix.rhansen.org:9001/p/201x-mm-dd password=2115756#