Austin Group Minutes of the 2 September Teleconference Austin-221 Page 1 of 1 Submitted by Andrew Josey, The Open Group. September 3, 2004 Attendees Andrew Josey, The Open Group Nick Stoughton, USENIX, WG15 OR Don Cragun , Sun, PASC OR Apologies Mark Brown, IBM, TOG OR Dave Butenhof, HP Ulrich Drepper, Red Hat Joanna Farley, Sun Defect Report Processing ------------------------- The group picked up on the latest batch of defect reports, which are available at the following URL: http://www.opengroup.org/austin/aardvark/latest/ We revisited the following item from last week which had had some followup discussion on the list: XCU ERN 31 cp wording unclear Accept as Marked Don had proposed the following response previously. 1. The Page and Line numbers referenced (relative to draft 7) should be changed as follows (all using the 2004 edition as a reference): Page: 2470 should be changed to Page: 269 Line: 10391 should be changed to Line: 10511 2. The references to lines 10316-10317 and lines 10391-10392 in the Problem statement should be changed to page 267, lines 10433-10434 and page 269, lines 10511-10512 respectively. 3. The submitter (alex.neyman@auriga.ru) states that he has no access to more recent versions of the standard [than draft 7], but says the text appears in SUSv3. We need to let Mr. Neyman know that SUSv3 is the same standard as IEEE Std 1003.1 and the ISO/IEC 9945 family of standards. 4. The standard is felt to be clear and correct. It was agreed that the following editorial change could provide more clarification and remove confusion. Change 10511 to If source_file is a file of type symbolic link, and the options require the symbolic link itself to be acted on, the pathname... XSH ERN 29 strfmon alignment of "()" OPEN This item was reopened at the request of the submitter who had said: (start quote) This does not seem to address my objection. My bug report was about an unclear specification for strfmon formatting of numbers with "()" as the negative number indicator. My point was that the positive and negative numbers should be aligned also when using format strings like "%(#5n" and "%!(#5n". Changing the example to use the POSIX example will not help in this regard. The standard seem to allow two different interpretations on how these format strings should be handled. I've seem implementation doing both aligned (Solaris) and unaligned (GNU libc) output for these strings. I believe the aligned output make most sense, and my suggestion was to (1) update the spec to make it clear that aligned output is the correct way to implement this, and (2) update the example to make it even clearer that the aligned output is the intended output. Changing the locale from en_US to POSIX in the example will only make a new set of strings, it will not change the alignment of the output. (end quote) This is being left open for further consideration. XSH ERN 51 posix_openpt() editorial error in example Accept XSH ERN 52 Bug in sched_setscheduler language OPEN The group felt they needed more input on this item, especially related to the the wording about moving the process to the end of the thread list. XSH ERN 53 closelog/openlog/syslog.h descriptions Accept as marked below It was agreed that the wording on closelog() and syslog.h could be better and suggest that the complete pages be revised in the regular normative style as part of the next revision. Add to SD/5 XSH ERN 54 editorial error in sem_trywait() error section Accept XSH ERN 55 strptime and leading zeroes Accept as marked below The standard is unclear and no conformance distinction can be made between different implementations because of this. Proposed wording for a future revision: Insert towards the end of paragraph 2 in the description (after ...between any two conversions.) "In the following list, where numeric ranges of values are given (represented by the pattern [x,y]), the value shall fall within the range given (both bounds being inclusive), and the number of characters scanned (excluding the one matching the next directive) shall be no more than the maximum number required to represent any value in the range without leading zeroes." Remove the text "leading zeroes are permitted but not required" on the "%w" conversion specifier (this text causes the ambiguity). Add a new 2nd paragraph into APPLICATION USAGE "It should be noted that that dates constructed by the strftime() function with the %Y or %C%y conversion specifiers may have values larger than 9999 and that strptime() may truncate these values to four digits." Next Steps ----------- Andrew will update the aardvark reports with the latest inbound defect reports. There are a number of open action items outstanding: 1. Don Cragun Pathname Resolution proposal 2. Larry Dwyer system() and threads 3. Joerg Schilling wording for XCU ERN 1 pax The next teleconference call is scheduled for Sep 23 2004