Minutes of the 12th September 2013 Teleconference Austin-626 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 13th September 2013 Attendees Don Cragun, PASC OR Geoff Clare, The Open Group Eric Blake, Red Hat Andrew Josey, The Open Group Mark Brown Richard Hansen, BBN David Clissold, IBM Mark Ziegast Nick Stoughton, USENIX, ISO/IEC OR Apologies Joerg Schilling, Fraunhofer Society * General news No news. * 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 622 left open pending resolution of 615. http://austingroupbugs.net/view.php?id=622 +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. * Current Business Andrew has circulated a response to the following below: (mail sequence 19739) Action: Andrew to ask David Korn whether ksh 'test ! = -o a' is a bug in ksh vs. the standard (for XSI, standard appears to require "! \( = -o a \)", ksh appears to use "\( ! = \) -o a") (completed after the meeting) Response: When test was about to be standardized, I pointed out that there were several differences between at&t and bsd and more importantly there was no way to know whether an argument was an operator or an operand for test since (, ), !, -o, and -a and = are all valid file names. I recommented replacing test and [...] with [[...]] which was built into the shell grammar and did not have these problems. This idea was put into an early posix draft and removed because it was too much invention and so many script already used test and [. The standard decided to standarized a subset of test which would account for the vast majority of it use, This covered all three argument tests and 4 argument tests beginning with !. However, subsequent to the original standard, XSI-conformant systems added two other requirement. One of these is to handle the case of 4 argument test command where the first argument is '('. I was unaware of this until I read the current standard. I will fix ksh to adhere to this. The second requirement which tries to standarize behavior beyond 4 arguments in my option is nonsense and will only lead to ambiguous behavior. Subsequent to the standard, most, if not all, shells have added [[ ...]]. I would encourange this to be standarized and remove the standarization of test beyond the four arguments in the standard. -- We agreed to pick up on this item next time. Bug 0000741: Add a NSIG constant (or, alternatively, SIGMAX) Accepted as Marked http://austingroupbugs.net/view.php?id=741 The rest of the call was spent on this item. This item is tagged for Issue 8. http://austingroupbugs.net/view.php?id=741#c1834 Changes: in page 282 after line 9359, add: {NSIG_MAX} Maximum possible return value of sysconf(_SC_NSIG). See [cross-ref to XSH sysconf()]. The value of {NSIG_MAX} shall be no greater than the number of signals that the sigset_t type (see [cross-ref to ]) is capable of representing, ignoring any restrictions imposed by sigfillset() or sigaddset(). Add to RATIONALE on P283, before L9380: {NSIG_MAX} Some historical implementations provided compile-time constants NSIG or SIGMAX to define the maximum number of signals the implementation supported, but these values did not neccessarily reflect the number of signals that could be handled using a sigset_t. With the addition of real-time signals and the desire by some applications to be able to allocate additional real-time signals at run-time, neither of these constants provided a useable, portable value. NSIG_MAX was added to the standard to allow applications to determine the maxiumum number of signals that an implementation will support based on the size of the sigset_t type (defined in ). in page 332 line 11083 after: The range SIGRTMIN through SIGRTMAX inclusive shall include at least {RTSIG_MAX} signal numbers. append: The value of SIGRTMAX shall be less than the value returned by sysconf(_SC_NSIG). in page 332 line 11087 change: The macros shall expand to positive integer constant expressions with type int and distinct values. to: The macros shall expand to positive integer constant expressions with type int and distinct values [CX]less than the value of {NSIG_MAX} defined in [/CX]. in page 444 after line 15055 add: _SC_NSIG in sysconf() [XSH] to the table between page 2077 and 2079 in an appropriate place (e.g. at the end) add the following: Highest supported signal number +1 _SC_NSIG To the Rationale, Add after p 2081 line 66479: Note that sysconf(_SC_NSIG) is less than or equal to {NSIG_MAX}. A future version may allow it to be larger. Next Steps ---------- The next call is on September 19, 2013 (a Thursday) We should pick up on the email item and also bug 714. Calls are anchored on US time. 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 We are now using an Etherpad for note taking - the URL is given at the start of the meeting in IRC