Minutes of the 7 August 2014 Teleconference Austin-669 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 8 August 2014 Attendees: Andrew Josey, The Open Group Richard Hansen, BBN Don Cragun, IEEE PASC OR Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR Geoff Clare, The Open Group Joerg Schilling FOKUS Fraunhofer Mark Ziegast, SHware Systems David Clissold, IBM Matthew Dempsky, OpenBSD Mark Brown, Canonical Eric Blake, Red Hat Apologies Martin Rehak, Oracle * General news Approval of the PAR within the PASC SEC is still stalled while some procedural issues related to SEC membership are resolved. Nick has an action to send Don the list of voting members of the SEC. * Outstanding actions +Bug 0000251: Forbid newline, or even bytes 1 through 31 (inclusive), in filenames OPEN http://austingroupbugs.net/view.php?id=251 Don has an action to produce a proposal. +Bug 0000561: NUL-termination of sun_path in Unix sockets OPEN http://austingroupbugs.net/view.php?id=561 Eric has an action to update the proposal. +Bug 0000573: Please add '+' to the portable filename character set OPEN http://austingroupbugs.net/view.php?id=573 Joerg has an action to prepare a proposed change. +Bug 0000592: consistent use of struct timespec OPEN http://austingroupbugs.net/view.php?id=592 Jim had provided additional information in bugnote 1627. This was discussed and Jim took an action to provide further information. +Bug 0000598: OH shading and new interfaces OPEN http://austingroupbugs.net/view.php?id=598 Eric has an action to propose a new solution with self-contained headers. +Bug 0000517: EBNF support OPEN http://austingroupbugs.net/view.php?id=517 Action on Joerg to look at this. +Bug 0000633: SIGEV_THREAD delivery renders many signal interfaces unsafe OPEN http://austingroupbugs.net/view.php?id=633 We noted that feedback has settled down on the mailing list, and will discuss next session. +Bug 0000657: Conditions under which fmemopen() write a NUL to the buffer are insufficiently specified OPEN http://austingroupbugs.net/view.php?id=657 Eric has an action to propose wording to clarify the behavior for fmemopen(), and also to contact the glibc developers to get their feedback. +Bug 0000658: Undefined/unspecified behavior clauses in description of open have race conditions OPEN http://austingroupbugs.net/view.php?id=658 It was noted that there is some overlap with changes in TC1. Eric took an action to update the proposal to resolve the overlaps appropriately. +Bug 0000615: pthread_setcancelstate should be async-signal-safe OPEN http://austingroupbugs.net/view.php?id=615 We now have reports on AIX and Apple. Jim to report back on whether pthread_cancelstate() is async-signal-safe on Solaris. Andrew to ask HP whether pthread_cancelstate() is async-signal-safe on HP-UX. +Bug 0000672: Necessary step(s) to synchronize filename operations on disk OPEN http://austingroupbugs.net/view.php?id=672 Geoff has a new proposed resolution in note 1618. Decided to solicit input from FS developers. Eric to go to Linux, David to AIX and Jim to Solaris. Jim has completed his action (see bugnote 1691). Andrew should chase HP and Apple for input. +Bug 0000663: Specification of str[n]casecmp is ambiguous reopened http://austingroupbugs.net/view.php?id=663 Action on David to follow up with the IBM developers about the EBCDIC collation sequence. Bug 696 either NAME_MAX shouldn't be optional, or readdir_r() needs clarification http://www.austingroupbugs.net/view.php?id=696 Don has an action to propose a resolution. Bug 0000721: Internal storage vs static storage OPEN http://austingroupbugs.net/view.php?id=721 This item is still open. Bug 0000375: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef OPEN http://austingroupbugs.net/view.php?id=375 This is still left open due to discussions pending on the reflector. Bug 0000789: Add set -o pipefail OPEN http://austingroupbugs.net/view.php?id=789 * Current Business We discussed C11 alignment. Matthew has posted a document at https://docs.google.com/a/dempsky.org/document/d/15lJFVak_anX_E6j96xp_juX6MbIhdodNTfQKeRNNBt8/edit C11 has introduced thrreading and low level memory handling. There have been different approaches to how to handle on POSIX systems. It was agreed that it would be a good idea to develop a white paper addressing alignment of POSIX systems with C11. Andrew took an action to setup a separate reflector for the topic - austin-c11-alignment. (completed after the meeting) Existing Austin Group participants can join the new austin-c11-alignment list by accessing https://collaboration.opengroup.org/platform/single_unix_specification/protected/mailinglists.php This has the set of additional lists that Austin Group members can self subscribe to (you will need to login first - in the left panel). Bug #851: pthread_atfork orphans handlers in unloaded shared libraries OPEN http://www.austingroupbugs.net/view.php?id=851 Action item: Andrew should try and contact to Finnbarr Murphy. (Status: Andrew has sent a query to Finnbarr via linked.in) Bug #852: Clarify MAP_FIXED semantics when replacing existing locked mappings Accepted as Marked http://www.austingroupbugs.net/view.php?id=852 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: We believe this is a clarification of existing practice; removing locks when remapping existing regions is important to applications but the standard does not clearly specify what is supposed to happen in this case. Notes to the Editor (not part of this interpretation): On page 1324 lines 43807-43808 (mmap() description), change: If a MAP_FIXED request is successful, the mapping established by mmap() replaces any previous mappings for the pages in the range [pa,pa+len) of the process. to: If a MAP_FIXED request is successful, then any previous mappings [ML|MLR]or memory locks[/] for those whole pages containing any part of the address range [pa,pa+len) shall be removed, as if by an appropriate call to munmap(), before the new mapping is established. On page 1326 lines 43928-43937 (mmap() rationale) change: If an application requests a mapping that would overlay existing mappings in the process, it might be desirable that an implementation detect this and inform the application. However, the default, portable (not MAP_FIXED) operation does not overlay existing mappings. On the other hand, if the program specifies a fixed address mapping (which requires some implementation knowledge to determine a suitable address, if the function is supported at all), then the program is presumed to be successfully managing its own address space and should be trusted when it asks to map over existing data structures. Furthermore, it is also desirable to make as few system calls as possible, and it might be considered onerous to require an munmap() before an mmap() to the same address range. This volume of POSIX.1-2008 specifies that the new mappings replace any existing mappings, following existing practice in this regard. to: If an application requests a mapping that overlaps existing mappings in the process, it might be desirable that an implementation detect this and inform the application. However, if the program specifies a fixed address mapping (which requires some implementation knowledge to determine a suitable address, if the function is supported at all), then the program is presumed to be successfully managing its own address space and should be trusted when it asks to map over existing data structures. Furthermore, it is also desirable to make as few system calls as possible, and it might be considered onerous to require an munmap() before an mmap() to the same address range. This volume of POSIX.1-2008 specifies that the new mapping replaces any existing mappings (implying an automatic munmap() on the address range), following existing practice in this regard. The standard developers also considered whether there should be a way for new mappings to overlay existing mappings, but found no existing practice for this. On page 1328 line 43983 (mmap() rationale) change MEMLOCK_FUTURE to MCL_FUTURE. Bug #854: requirement for additional built-in utilities to be searched for via $PATH was not and is not existing practice OPEN http://austingroupbugs.net/view.php?id=854 Action: Andrew to ask David Korn to comment on this bug and the previous email discussion of the issue (seq 21270). Bug #855: Tiny wording clarifications on "the" versus "a" startup file Accepted http://austingroupbugs.net/view.php?id=855 Bug #857: Make rules which do not create the target file or do unexpected things with its timestamp OPEN http://austingroupbugs.net/view.php?id=857 It was noted that case 1 is covered by http://austingroupbugs.net/view.php?id=523 This item will be continued on the next call Next Steps ---------- The next call is on August 14, 2014 (a Thursday) 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#