[1003.1(2016)/Issue7+TC2 0001216]: Adding clockid parameter to functions that accept absolute struct timespec timeouts
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1216 == Reported By:mikecrowe Assigned To:ajosey == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1216 Category: System Interfaces Type: Enhancement Request Severity: Comment Priority: normal Status: Under Review Name: Mike Crowe Organization: User Reference: Section:pthread Page Number:0 Line Number:0 Interp Status: --- Final Accepted Text: == Date Submitted: 2018-11-26 18:53 UTC Last Modified: 2019-01-19 04:08 UTC == Summary:Adding clockid parameter to functions that accept absolute struct timespec timeouts == Relationships ID Summary -- related to 0001164 Correct C++11 std::condition_variable r... == -- (0004215) mikecrowe (reporter) - 2019-01-19 04:08 http://austingroupbugs.net/view.php?id=1216#c4215 -- Here's my suggested wording for pthread_cond_clockwait (with a single hint to the other new functions too.) It would be great to receive feedback on whether the changes are broadly appropriate, and whether there is a better way to describe the changes. Once I know whether I'm on the right track, I can add the remaining functions (which will hopefully require fewer changes.) (I have glibc implementations of sem_clockwait, pthread_mutex_clockwait, pthread_cond_clockwait, pthread_rwlock_clockrdlock and pthread_rwlock_clockwrlock working. I just need to get the commit messages into shape before posting them to the glibc list.) Thanks. Mike. *** Add to lists at lines 3070, 10833, 18119, 52281, 52599, 52710, 55292, 124395, 130171: pthread_cond_clockwait() *** After line 10727 insert: int pthread_cond_clockwait(pthread_cond_t *restrict, pthread_mutex_t *restrict, clockid_t, const struct timespec *restrict); *** After line 10767 insert: It calls pthread_cond_clockwait() with m as the mutex argument and the call returns zero or certain error numbers (see pthread_cond_clockwait()). *** After line 17972 insert: It blocks in a call to pthread_cond_clockwait() with m as the mutex argument. *** Line 30449 Change "and pthread_cond_timedwait" to ", pthread_cond_timedwait and pthread_cond_clockwait". *** Lines 52513, 52515, 52519, 52582, 124488 Change "or pthread_cond_timedwait" to ", pthread_cond_timedwait or pthread_cond_clockwait". *** After line 52743 insert: int pthread_cond_clockwait(pthread_cond_t *restrict cond, pthread_mutex_t *restrict mutex, clockid_t clock_id, const struct timespec *restrict abstime); *** Lines 52747, 52762, 52763, 52766, 52781, 52783, 52786, 52848, 52882 Add ", pthread_cond_clockwait()" after "pthread_cond_timedwait()" *** After line 52797 insert: The pthread_cond_clockwait() function shall be equivalent to pthread_cond_timedwait(), except that the absolute time specified by abstime is measured against the clock indicated by clock_id rather than the clock specified in the condition variable's clock attribute. All implementations shall support passing CLOCK_REALTIME to pthread_cond_clockwait() as the clock_id parameter. If the Monotonic Clock option is supported, all implementations shall support a clock_id of CLOCK_MONOTONIC. *** Line 52822: Change to "The pthread_cond_timedwait() and pthread_cond_clockwait() functions shall fail if:" *** Line 52823, 52850: Change "pthread_cond_timedwait()" to "pthread_cond_timedwait() or pthread_cond_clockwait()" *** Line 52825: Add "or the clock_id parameter passed to pthread_cond_clockwait is invalid or not supported." *** Insert after line 52879: Choice of clock Care should be taken to decide which clock is most appropriate when waiting with a timeout. The system clock, CLOCK_REALTIME, as used by default with pthread_cond_timedwait() may be subject to jumps forwards and backwards in order to correct it against actual time. CLOCK_MONOTONIC is guaranteed not to jump backwards and must also advance in real time, so using it via pthread_cond_clockwait() or pthread_condattr_setclock() may be more appropriate.
[1003.1(2013)/Issue7+TC1 0000953]: Alias expansion is under-specified
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=953 == Reported By:wpollock Assigned To:ajosey == Project:1003.1(2013)/Issue7+TC1 Issue ID: 953 Category: Shell and Utilities Type: Clarification Requested Severity: Objection Priority: normal Status: Interpretation Required Name: Wayne Pollock Organization: User Reference: Section:2.3.1 Alias Substitution Page Number:2322 Line Number:73690-73705 Interp Status: Pending Final Accepted Text:See http://austingroupbugs.net/view.php?id=953#c3113 == Date Submitted: 2015-06-04 00:22 UTC Last Modified: 2019-01-18 11:48 UTC == Summary:Alias expansion is under-specified == Relationships ID Summary -- related to 736 grammatically accept zero or more Shell... related to 0001048 deprecate alias and unalias related to 0001055 unspecified how much is parsed before e... == -- (0004214) geoffclare (manager) - 2019-01-18 11:48 http://austingroupbugs.net/view.php?id=953#c4214 -- Alternative resolution, based on kre's suggestion on the mailing list. All page and line numbers are for the 2016 and 2018 editions. On page 2348 line 74794-74805 (XCU 2.3.1 Alias Substitution), change:After a token has been delimited, but before applying the grammatical rules in Section 2.10, a resulting word that is identified to be the command name word of a simple command shall be examined to determine whether it is an unquoted, valid alias name. However, reserved words in correct grammatical context shall not be candidates for alias substitution. A valid alias name (see XBD Section 3.10) shall be one that has been defined by the alias utility and not subsequently undefined using unalias. Implementations also may provide predefined valid aliases that are in effect when the shell is invoked. To prevent infinite loops in recursive aliasing, if the shell is not currently processing an alias of the same name, the word shall be replaced by the value of the alias; otherwise, it shall not be replaced. If the value of the alias replacing the word ends in a , the shell shall check the next command word for alias substitution; this process shall continue until a word is found that is not a valid alias or an alias value does not end in a .to:After a token has been categorized as type TOKEN (see [xref to 2.10.1]), including (recursively) any token resulting from an alias substitution, the TOKEN shall be subject to alias substitution if: the TOKEN does not contain any quoting characters, the TOKEN is a valid alias name (see XBD Section 3.10), an alias with that name is in effect, and the TOKEN did not result from an alias substitution of the same alias name at any earlier recursion level, except that if the TOKEN meets the above conditions and would be recognized as a reserved word (see [xref to 2.4 Reserved Words]) if it occurred in an appropriate place in the input, it is unspecified whether the TOKEN is subject to alias substitution. When a TOKEN is subject to alias substitution, the value of the alias shall be processed as if it had been read from the input instead of the TOKEN, with token recognition (see [xref to 2.3 Token Recognition]) resuming at the first character of the alias value. When the end of the alias value is reached, the shell may behave as if an additional character had been read from the input after the TOKEN that was replaced. If it does not add this , and the last character of the alias value could be part of an operator token, it is unspecified whether the current token is delimited before token recognition is applied to the character (if any) that followed the TOKEN in the input. Note: a future version of this standard may disallow adding this . If the value of the alias replacing the TOKEN ends in a that would be unquoted after substitution, and optionally if it ends in a that would be quoted after substitution, the shell shall check the next token in the input, if it is a TOKEN,
Re: The alias rescanning issue affects some simple commands
I will shortly be adding a new note to bug 953 with an alternative resolution based on kre's suggestion below, but with wording that I believe better matches the existing wording in other related parts of the standard. Note that I'm on vacation next week, so if any edits are needed to this new note, they will have to wait until w/b 28th Jan. Regards, Geoff. Robert Elz wrote, on 17 Jan 2019: > > What we might want to have the standard say, after the part about > recognising the alias in the input, and the part aboutreserved word > tokens being unspecified, but to make clearer what is actually > intended there, change it to ... > > except that if the TOKEN meets the above conditions > and would if it occurred in an appropriate place in the > input, be recognized as a reserved word (see [xref to > 2.4 Reserved Words]), it is unspecified whether the TOKEN > is subject to alias substitution. > > The "is recognised" can be read as only applying when the TOKEN > is in the position where a reserved word is possible, where the > intent of specifying it this way is to deal with the case where an > alias found after a previous alias ends in a space is char for char > equal to a reserved word - but isn't because it is not in the place > where a reserved work can occur. > > I'd defer the next (note 4201) paragraph (the one about when changes > to aliases take effect) until lower down, rather then occurring right in > the middle of processing, and then delete the next bullet list, and the > text leading up to it, and following it, entirely, and instead continue > with the "When a TOKEN is subject to alias substitution, ..." paragraph, > except change it to say > > When a TOKEN is subject to alias substitution, that TOKEN > is deleted from the input. The value of the alias named by > that TOKEN is inserted into the input stream, ahead of the > character that delimited the alias TOKEN, and lexical > processing resumes with the first character of the alias > value, and continues for the remainder of the value, after > which the previous delimiting character will be observed > again, however perhaps with a different interpretation. > It is unspecified whether a single space character is > inserted between the value of the alias and the characters > that followed the alias TOKEN. > > and then continue with the text from note 4201 ... > > If the value of the alias replacing the TOKEN ends in a > (etc). > > Then assuming it remains part of this bug interpretation, and isn't > simply moved to 1055 (where it would fit better) the paragraph about > deferring the effective visibility of changes to alias (the effects of the > alias and unalias commands) can be added. > > This looks, from the discussions we have been having, as if it will > handle all existing shells, and result in the minimum possible > "unspecified" cases. > > In the rationale the effects of the extra (unspecified) added space can > be explained, and perhaps implementations encouraged not to do that. > > kre -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Minutes of the 17th January 2019 Teleconference
All Enclosed are the minutes from yesterdays call regards Andrew --- Minutes of the 17th January 2019 Teleconference Austin-901 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 18th January 2019 Attendees: Andrew Josey, The Open Group Don Cragun, IEEE PASC OR Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR Eric Blake, Red Hat Geoff Clare, The Open Group Joerg Schilling, FOKUS Fraunhofer Mark Ziegast, SHware Systems Apologies None * General news There is still a discussion running on the list about alias implementations; we agreed to let the discussion run on the list before discussing on a call. * Outstanding actions (Please note that this section has been flushed to shorten the minutes - to locate the previous set of outstanding actions, look to the minutes from 9 March 2018 and earlier) Bug 1077: Recommend support for wide-character regcomp and regexec and/or specify multi-byte behavior OPEN http://austingroupbugs.net/bug_view_page.php?bug_id=1077 Andrew has completed the action to ping his Apple contact and is awaiting a reply. Bug 1122: POSIX should include gettext() and friends OPEN http://austingroupbugs.net/view.php?id=1122 Left open as an action is still in progress to flesh out a complete proposal. * Current Business Bug 1159: Is termination after receipt of SIGINT in dd(1) an error? OPEN http://austingroupbugs.net/bug_view_page.php?bug_id=1159 This was discussed at length on the call, and will continue on the next call. Next Steps -- The next calls are on: January 21st 2019 (Monday). This call will be for 60 minutes. January 24th 2019 (Thursday) This call will be for 90 minutes. Apologies in advance: Geoff Clare (2019-01-21 and 2019-01-24) Don Cragun (2019-01-28) Andrew Josey (2019-01-28, 2019-01-31) Calls are anchored on US time. (8am Pacific) http://austingroupbugs.net An etherpad is usually up for the meeting, with a URL using the date format as below: https://posix.rhansen.org/p/201x-mm-dd username=posix password=2115756# Andrew JoseyThe Open Group Austin Group Chair Email: a.jo...@opengroup.org Apex Plaza, Forbury Road,Reading,Berks.RG1 1AX,England Tel:+44 118 9023044 To learn how we maintain your privacy, please review The Open Group Privacy Statement at http://www.opengroup.org/privacy. To unsubscribe/opt-out from this mailing list login to The Open Group collaboration portal at https://collaboration.opengroup.org/operational/portal.php?action=unsub=2481
Austin Group teleconference +1-888-426-6840 PIN: 2115756
BEGIN:VCALENDAR VERSION:2.0 PRODID:-//opengroup.org//NONSGML kigkonsult.se iCalcreator 2.22.1// CALSCALE:GREGORIAN METHOD:REQUEST BEGIN:VTIMEZONE TZID:America/New_York X-LIC-LOCATION:America/New_York BEGIN:DAYLIGHT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 TZNAME:EDT DTSTART:20120311T02 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:-0400 TZOFFSETTO:-0500 TZNAME:EST DTSTART:20121104T02 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT UID:5c41b020ef...@opengroup.org DTSTAMP:20190118T105321Z ATTENDEE;ROLE=CHAIR:MAILTO:a.jo...@opengroup.org CREATED:20190118T00Z DESCRIPTION:Web/Project: Single UNIX Specification\nTitle: Austin Group tel econference +1-888-426-6840 PIN: 2115756\nDate/Time: 24-Jan-2019 at 11:00 America/New_York\nDuration: 1.50 hours\nURL: https://collaboration.opengro up.org/platform/single_unix_specification/events.php\n\n** All calls are a nchored on US time **\n\nTopic: Austin Group teleconference\n- --\nAudio conference information\n ---\nCall-in toll free number (US/Canada): +1-888-426-6840\nParticipant PIN: 2115756.\n\nAll Aus tin Group participants are most welcome to join the call.\nThe call will l ast for 1.5 hours .\nThis call is handling defect report processing.\n\nAn etherpad is usually up for a meeting\, with a URL using the date format a s below:\n\nhttp://posix.rhansen.org/p/201x-mm-dd\nusername=posix password =2115756#\n\nAdditional Call-in numbers:\nGermany Caller P aid0-69-2443-2290\nGermany Toll-Free 0800-000-1018\nUnited Kingdom Caller Paid 0-20-305964 51\nUnited Kingdom Toll-Free 0800-368-0638\nUSA Caller Paid 215-861-6239\nUSA Toll-Free 888-426-6840\nDenmark Caller Paid32711870\nDenmark Toll-Free 80-717000\nCzech Republic Caller Paid 2-39016353\nCz ech Republic Toll-Free 800-143-484\nCall-in numbers for other countries are available on request\n\nBug reports are available at:\nhttp://www.austingroupbugs.net\n DTSTART;TZID=America/New_York:20190124T11 DURATION:PT1H30M0S LAST-MODIFIED:20190118T055321Z ORGANIZER;CN=Single UNIX Specification:MAILTO:do-not-re...@opengroup.org SEQUENCE:0 STATUS:CONFIRMED SUMMARY:Austin Group teleconference +1-888-426-6840 PIN: 2115756 TRANSP:OPAQUE URL:https://collaboration.opengroup.org/platform/single_unix_specification/ events.php X-MICROSOFT-CDO-ALLDAYEVENT:FALSE X-VISIBILITY:40 X-JOINBEFORE:5 X-CATEGORY:Teleconference X-PLATO-SITE:Single UNIX Specification X-PLATO-SITEID:136 END:VEVENT END:VCALENDAR meeting.ics Description: application/ics
