Minutes of the 27th June 2013 Teleconference Austin-617 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 28th June 2013 Attendees Don Cragun, PASC OR Geoff Clare, The Open Group Nick Stoughton, USENIX, ISO/IEC OR Joerg Schilling, Fraunhofer Society Mark Brown, IBM, TOG OR Andrew Josey, The Open Group Richard Hansen, BBN Jim Pugsley, Oracle Eric Blake, Red Hat * General news The annual 9945 Project Editor report and the Austin Group Organizational Representative Report have been submitted to ISO for the SC22 plenary meeting. These are available in the document register as documents 615 and 616 respectively. * Outstanding actions +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 (**updated**) 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, Mark to AIX and Jim to Solaris. * Current Business Bug 714 0000714: yn(n,0) is incorrect for odd n<0 Accepted As Marked http://austingroupbugs.net/view.php?id=714 This issue is tagged for Issue 8. Interpretation response The standard states that -HUGE_VAL shall be returned, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Rationale: The standard does not match the mathematical behavior of yn(). Notes to the Editor (not part of this interpretation): At line 72758 after: The y0(), y1(), and yn() functions shall compute Bessel functions of x of the second kind of orders 0, 1, and n, respectively. append: y0(x) shall be equivalent to yn(0,x), and y1(x) shall be equivalent to yn(1,x). At line 72770 change: If x is 0.0, -HUGE_VAL shall be returned and a pole error may occur. to: If x is 0.0, y0() and y1() shall return -HUGE_VAL and a pole error may occur. If x is 0.0 and n is not both negative and odd, yn() shall return -HUGE_VAL and a pole error may occur. If x is 0.0 and n is negative and odd, yn() shall return +HUGE_VAL and a pole error may occur. Bug 711 0000711: Are the stdarg.h macros async-signal-safe? Accepted as Marked http://austingroupbugs.net/view.php?id=711 Nick had completed his action to propose wording changes to make the va_*() macros async-signal-safe in issue 8. We discussed Note: 0001656 during the June 27, 2013 conference call. If additional function-like macros need to be added to the table, please submit a bug report (or reports) with the additional macros that need to be addressed. This bug is going through the interpretations track, so if some implementations have a problem with making va_* macros async-signal safe, they can note the issue during the interpretation review process. 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: None Notes to the Editor (not part of this interpretation): At line 16841, change "or if the signal handler calls any function defined in this standard other than one of the functions listed in the following table" to "or if the signal handler calls any function or function-like macro defined in this standard other than one of the functions and macros listed in the following table" At line 16843, change "a set of functions" to "a set of functions and function-like macros" and add va_arg va_copy va_end va_start to the list in proper alphabetical order. At line 16880, change "All functions" to "All functions or function-like macros" At line 16883, change "signal interrupts an unsafe function and the signal-catching function calls an unsafe function, the behavior is undefined." to "signal interrupts an unsafe function or function-like macro and the signal-catching function calls an unsafe function or function-like macro, the behavior is undefined." Bug 713 0000713: in remquo quo should be unspecified when the result is NaN OPEN http://austingroupbugs.net/view.php?id=713 Nick had completion his action to raise with the C committee. We will await on a response before acting further. Bug 0000716: Atomicity specification of rename() uses the word "processes" but means "threads" Accepted http://austingroupbugs.net/view.php?id=716 This item is tagged for TC2-2008 Next Steps ---------- The next call is on July 11 2013 (a Thursday) Calls are anchored on US time. This call will be for the regular 90 minutes. http://austingroupbugs.net We will use the webex bridge. See the calendar for the list of dialup numbers. An IRC channel will be available for the meeting irc://irc.freenode.net/austingroupbugs