Minutes of the 4th October 2018 Teleconference Austin-888 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 5th October 2018 Attendees: Don Cragun, IEEE PASC OR Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR Geoff Clare, The Open Group Mark Ziegast, SHware Systems Dev. Eric Blake, Red Hat Joerg Schilling, FOKUS Fraunhofer Andrew Josey, The Open Group Apologies: Martin Rehak, Oracle, The Open Group OR David Clissold, IBM * General news Andrew has started some interpretations for 30 day review, but was unclear on the status of some (as they had discussions in the bug reports after the draft interpretation). He took an action to send a list of those to Austin Core for feedback. (action completed after the meeting) * 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) * Current Business 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. Bug 1134: Add getentropy interface OPEN http://austingroupbugs.net/view.php?id=1134 Action: Andrew to add boilerplate response regarding a proposal for new interface, and also to ask The Open Group OR if they would sponsor this addition. Both Actions now Completed. Bug 1136: awk: missing case where a bare array name may be used Accepted as Marked http://austingroupbugs.net/view.php?id=1136 This item is tagged for TC3-2008. Add a new bullet to the list on P2489 after L80018: * An implementation may allow the operand to the delete statement to be an array name Move the paragraph starting on P2499, L80458 to follow P2496, L80325. (This moves the discussion of array parameters from the user defined functions section to the section that applies to all functions.) Add a new paragraph after P2494, L80242: Implementations may also accept the statement: delete array as a synonym for the above loop. Add a new line to the grammar after P2502, L80593: | Delete NAME /* See footnote 1.*/ with footnote 1 being: A future version of this standard may require the delete statement with an unsubscripted array name to be accepted. This version of the standard allows but does not require support for this syntax. See also bug 0000544 for changes to be applied in the next revision of this standard. Bug 0000544: extend awk delete statement to delete entire array Accepted as Marked This item is tagged for Issue 8. On 2016 edition page 2489 after line 80018 change the new bullet item added by bug 1136 from: An implementation may allow the operand to the delete statement to be an array name. to: The NAME token following the keyword Delete without a subscript as specified in the grammar (see Grammar, on page XXX); if the name used in this context is not an array name, the behavior is undefined. On 2016 edition page 2494 line 80239 change: The delete statement shall remove an individual array element. Thus, the following code deletes an entire array: for (index in array) delete array[index] to: The delete statement shall remove either a specified individual array element or, if no element is specified, all array elements. Thus, the following code: for (index in array) delete array[index] is equivalent to: delete array Both delete all elements of the array. After 2016 edition P2494, L80242, delete the text added by bug 1136 Implementations may also accept the statement: delete array as a synonym for the above loop. On 2016 edition page 2502 line 80593, change: | Delete NAME /* See footnote 1. */ to: | Delete NAME and delete footnote 1. Add after 2016 edition page 2516 line 81222: Deleting all elements of an array one element at a time, via: for (index in array) delete array[index] is usually not efficient. This standard requires delete array to have the same effects, and this was supported in most implementations as a more efficient operation. It is also possible to use split("", array) to achieve the same effect and efficiency. Bug 0001137: problems with numbered and unnumbered conversion specifications Accepted as Marked http://austingroupbugs.net/view.php?id=1137 This item is tagged for TC3-2008 NOTE page and line numbers quoted for the 2013 edition (TC1). Page is 900 (fprintf) and 982 (fwprintf). 1) Change the sentence on lines 30186-30187 from: The format can contain either numbered argument conversion specifications (that is, "%n$" and "*m$"), or unnumbered argument conversion specifications (that is, % and *), but not both. to: The format can contain either numbered argument conversion specifications (that is, those introduced by "%n$" and optionally containing the "*m$" forms of field width and precision), or unnumbered argument conversion specifications (that is, those introduced by the % character and optionally containing the * form of field width and precision), but not both. 2) Change the text on line 30207 from: The field width takes the form of an ('*'), described below, or a decimal integer. to: The field width takes the form of an ('*'), [CX] or in conversion specifications introduced by "%n$" the "*m$" string,[/CX] described below, or a decimal integer. 3) Change the text on lines 30213-30215 from: The precision takes the form of a ('.') followed either by an ('*'), described below, or an optional decimal digit string, where a null digit string is treated as zero. to: The precision takes the form of a ('.') followed either by an ('*'), [CX] or in conversion specifications introduced by "%n$" the "*m$" string,[/CX] described below, or an optional decimal digit string, where a null digit string is treated as zero." 4) Change the text on line 30224 from: In format strings containing the "%n$" form of a conversion specification, a field width or precision may be indicated by the sequence "*m$", where m is a decimal integer ... to: In format strings containing conversion specifications introduced by "%n$", in addition to being indicated by the decimal digit string, a field width may be indicated by the sequence "*m$" and precision by the sequence ".*m$", where m is a decimal integer ... 5) Repeat all of the above on the equivalent lines in the fwprintf description (page 982). Next Steps ---------- The next call is on October 11th 2018 (Thursday). Calls are anchored on US time. (8am Pacific) This call will be for the regular 90 minutes. 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#