Minutes of the 12 November 2009 Teleconference Austin-470 Page 1 of 1 Submitted by Andrew Josey, The Open Group. November 13 , 2009 Attendees Andrew Josey, The Open Group Don Cragun, PASC OR Geoff Clare, The Open Group Mark Brown, IBM, TOG OR Nick Stoughton, USENIX, ISO/IEC OR Ulrich Drepper, Red Hat Andrew had circulated a number of interpretations for review, with the comments period set to end on December 7th. Some comments had been made on Mantis #156. Mantis #156 df -k and free inodes http://austingroupbugs.net/view.php?id=156 We discussed the comments raised in bugnotes 292 and 296 and it was agreed that the position put forward in 296 was what was agreed on. Bugnote 296: Currently the only standard way to find out the number of free inodes is to use df without -P or -k. If we remove the requirement for df to output the number of free inodes when invoked this way, we would have to add a -i option so that there is still a way to obtain this information. We cannot add an option in a TC; it would have to wait for the next revision. Therefore I don't believe we can consider making such a change in this interpretation (because we need to fix the -k problem in TC1, but can't add -i). However, we could certainly consider it for the next revision. If you would like to set the ball rolling on that, please submit a new aardvark with the type field set to "Enhancement Request". We looked at the Mantis bugs Mantis #173 Executing programs with "bad" file descriptors 0,1,2 Accept as marked http://austingroupbugs.net/view.php?id=173 See bugnote 297. This should go down the interpretations track for a 30 day review. Mantis #174 fputs() for strings longer than INT_MAX Accept as marked http://austingroupbugs.net/view.php?id=174 A change to APPLICATION USAGE is recommended Bugnote 298: Add the following to the Application Usage section of puts(), p1723 after line 55077: "In some implementations puts() returned the number of bytes written. However, this convention cannot be adhered to for strings longer than INT_MAX bytes as the value would not be representable in the return type of the function. For backwards compatibility, implementations can return the number of bytes for strings of up to INT_MAX bytes, and return INT_MAX for all longer strings." Also the same on page 908 after line 30373, with puts() changed to fputs(). Mantis #177 mismatch between example description and code Accept as marked http://austingroupbugs.net/view.php?id=177 It was agreed that the EXAMPLE should be replaced as described in bugnote 293. Mantis #178 dlsym page style issues Duplicate of 74 http://austingroupbugs.net/view.php?id=177 The dlsym() and dlopen() pages are being completely rewritten to fix the problem reported in 0000074 The editorial problems with these function references have been corrected in the new text. See Note: 0000205 This bug is marked as a dup of 74. We moved onto the Onlinepubs category of bugs Mantis #160 web page issue (requires login when should not) Accept http://austingroupbugs.net/view.php?id=160 (fix has been made to onlinepub) Mantis #175 html problem in sleep example Accept http://austingroupbugs.net/view.php?id=175 Mantis #179 POSIX 2008 word search looks at 2004 spec Accept http://austingroupbugs.net/view.php?id=179 (fix has been made to onlinepub) We reviewed the mailing list and discussed several of the issues. As a result a number of new bugs were agreed to be filed: Mantis #180 code formatting (onlinepubs) http://austingroupbugs.net/view.php?id=180 Mantis #181 does each thread have to have its own floating point environment http://austingroupbugs.net/view.php?id=181 Mantis #182 unsafe use of LINE_MAX in fgets() example http://austingroupbugs.net/view.php?id=182 We discussed the issue raised on inet_ntop() and RFC 2553 in mail seq 13101. It was agreed that this ought to be discussed. Action: Andrew to contact the submitter and ask him to raise a defect report. Next Steps ---------- The next call will be on December 3 at 16:00 UK time/08:00 Pacific to carry on with the defect reports http://austingroupbugs.net See the calendar for the list of dialup numbers. An IRC channel will be available for the meeting irc://irc.freestandards.org #austin ICAL: http://www.google.com/calendar/ical/nvctqtstkuni3fab9k3jqtrt4g@group.calendar.google.com/public/basic XML: http://www.google.com/calendar/feeds/nvctqtstkuni3fab9k3jqtrt4g@group.calendar.google.com/public/basic