Minutes of the 4th June 2009 Teleconference Austin-455 Page 1 of 1 Submitted by Andrew Josey, The Open Group. June 5 , 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 * ISO status We discussed the request from IEEE regarding the designation of the joint IEEE/ISO edition and agreed it would be ok. We will raise a question as to what this might mean for the designation of TC1. * Bugzilla We continued discussing the new bug reporting system. Mark hopes to make a update prior to the next meeting. Don has entered some live bugs into that system and tagged them with a keyword so we can identify them. * Aardvark review We picked up again on the latest rdvk reports. http://www.opengroup.org/austin/aardvark/latest/ XSHbug3.txt ERN 39 memchr Accept as marked below A number of changes were agreed as follows Change p1284 lines 42163-42164 In the DESCRIPTION remove "of the object" from The memchr( ) function shall locate the first occurrence of c (converted to an unsigned char) in the initial n bytes (each interpreted as unsigned char) of the object pointed to by s. In the RETURN VALUE section The memchr( ) function shall return a pointer to the located byte, or a null pointer if the byte does not occur in the object. to The memchr( ) function shall return a pointer to the located byte, or a null pointer if the byte is not found. Also Nick will let the C committee know about the issue Add to DESCRIPTION Implementations shall behave as if they read the memory byte by byte from the beginning of the bytes pointed to by s and stop at the first occurrence of c (if it is found in the initial n bytes). XSHbug3 ERN 38 Accept as mark below Don had taken the action. Add mblen(), mbstowcs(), and mbtowc() in subclause 2.9.1 in alphabetic order to the list of functions that need not be thread-safe in the table on P507, L17490-17510. Change the list of functions that need not be thread-safe if called with a NULL ps argument in subclause 2.9.1 on P507, L17512 from: "wcrtomb() and wcsrtombs()" to: "mbrlen(), mbrtowc(), mbsnrtowcs(), mbsrtowcs(), wcrtomb(), wcsnrtombs(), and wcsrtombs()" Add a new paragraph to the mblen() DESCRIPTION after P1270, L41765: "The mblen() function need not be thread-safe." with CX shading. Add a new paragraph to the mbrlen() DESCRIPTION after P1272, L41808: "The mbrlen() function need not be thread-safe if called with a NULL ps argument." with CX shading. Add a new paragraph to the mbrtowc() DESCRIPTION after P1274, L41871: "The mbrtowc() function need not be thread-safe if called with a NULL ps argument." with CX shading. Add a new paragraph to the mbsnrtowcs() and mbsrtowcs() DESCRIPTION after P1277, L41989: "The mbsnrtowcs() and mbsrtowcs() functions need not be thread-safe if called with a NULL ps argument." with CX shading. Add a new paragraph to the mbtowc() DESCRIPTION after P1281, L42094: "The mbtowc() function need not be thread-safe." with CX shading. Change: "The wcsrtombs() function" in the DESCRIPTION of wcsnrtombs() and wcsrtombs() on P2219, L69818 to: "The wcsnrtombs() and wcsrtombs() functions" keeping the CX shading. Remove wcstombs() from the current table of non thread safe functions On page 2235 remove line 70283 "need not be thread-safe" Send this down the interpretations track with the normal boilerplate for "standard is clear; standard is wrong". Concerns Austin Interpretation AI-122 ------------------------------- Geoff had circulated mail sequence austin-group-l:archive/latest/12142 There is a bit of unfinished business left over from the revision, namely AI-122. Instead of approving this interpretations with the others that were applied in the revision, we decided that the proposed resolution was wrong and left it open. It is the one about timers for high resolution clocks requiring privilege because of the potential for denial of service. The last time it was discussed, I believe the consensus was that: 1. The denial of service issue does not occur on timer creation, but when the timer is set. Specifically, it relates to setting small repeat intervals. 2. The issue applies to all real time clocks, including CLOCK_REALTIME. (It does not apply to CPU time clocks.) Since that discussion, it has also occurred to me that for extremely high resolution clocks there may be intervals that even a privileged process should not be able to set. An error for this is probably already allowed as an extension, but it would be worth standardising the error number to be used. I propose the use of ENOTSUP, to distinguish this case from a completely invalid timer value (EINVAL). This is similar to how pthread_setschedprio() distinguishes between unsupported and invalid priority values. I have made an attempt at producing a set of changes. One problem that I encountered was how applications can determine the minimum repeat interval they can use. Possibly we should add a sysconf() variable for this, but I haven't gone that far. At the moment there is just a fixed "maximum minimum" for the limit(s). I have set it at 10ms to correspond to the traditional HZ=100 timer resolution. At page 2114 line 66936 section timer_getoverrun, after: When a timer is armed with a non-zero it_interval, a periodic (or repetitive) timer is specified. add: Implementations may impose a minimum limit on the time interval specified in it_interval when timerid identifies a timer created for a clock measuring real time. The limit is implementation-defined and may be different for processes with appropriate privileges and those without. In both cases the limit, if any, shall be less than or equal to 10 milliseconds. At page 2115 line 66975 section timer_getoverrun, add to the timer_setting "may fail" error list: [ENOTSUP] The timer was created for a clock measuring real time and the it_interval member of value is greater than zero and less than the implementation-defined limit allowed for processes with appropriate privileges. [EPERM] The timer was created for a clock measuring real time, the calling process does not have appropriate privileges, and the it_interval member of value is greater than zero and less than the implementation-defined limit allowed for processes without appropriate privileges. The changes as proposed by Geoff were accepted. Action:Andrew to redraft the proposed interpretation and recirculate XSHbug3 ERN 40 Withdrawn by submitter XCUBug3.txt Shell Grammar ERN 10 Accept Send this down the interpretations track. The standard is clear, however concerns are being forwarded to the sponsor. XBDBug ERN 7 trace_attr_t Accept XBDBug ERN 8 XSI shading grp.h Accept Next Steps ---------- The next call will be on June 25 at 16:00 UK time/08:00 Pacific to carry on with the aardvark. 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