Minutes of the 25th September 2023 Teleconference Austin-1346 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 27 September 2023 Attendees: Nick Stoughton, Logitech/USENIX, ISO/IEC JTC 1/SC 22 OR Don Cragun, IEEE PASC OR Eric Ackermann, HPI, University of Potsdam Eric Blake, Red Hat, The Open Group OR Tom Thompson, IEEE Andrew Josey, The Open Group Mark Ziegast, SHware Systems Dev. Apologies Geoff Clare, The Open Group * General news Tom reported that the PASC policies and procedures had been approved, also the PAR extension request is on the agenda for the next IEEE approval meeting in October. He also reported that the dissolution of the PASC had been approved and that the project would be moving soon under the Microprocessor Committee as the new sponsor. We asked Tom to keep us informed of the move. * Current Business Note for issue resolution all items are tagged for Issue 8 unless noted otherwise or disposition is reject or duplicate. Bug 1649: Field splitting is woefully under specified, and in places, simply wrong https://austingroupbugs.net/view.php?id=1649 Accepted as Marked This item was reopened and revisions made. Replace XCU section 2.6.5 on issue 8 draft 3 P2476, L80478-80504 with: After parameter expansion (Section 2.6.2), command substitution (Section 2.6.3), and arithmetic expansion (Section 2.6.4), and if the shell variable IFS [xref XCU 2.5.3] is set and its value is not empty, or if the IFS variable is unset, the shell shall scan each field containing results of expansions and substitutions that did not occur in double-quotes for field splitting; zero, one or multiple fields can result. For the remainder of this section, any reference to the results of an expansion, or results of expansions, shall be interpreted to mean the results from one or more unquoted variable or arithmetic expansions, or unquoted command substitutions. If the IFS variable is set and has an empty string as its value, no field splitting occurs. However if an input field which contained the results of an expansion is entirely empty, it shall be removed. Note that this occurs before quote removal, any input field that contains any quoting characters can never be empty at this point. After the removal of any such fields from the input, the possibly modified input field list becomes the output. Each input field is considered in sequence, first to last, with the results of the algorithm described in this section causing output fields to be generated, which remain in the same order as the input fields from which they originated. Fields which contain no results from expansions shall not be affected by field splitting, and shall remain unaltered, simply moving from the list of input fields to be next in the list of output fields. In the remainder of this description, it is assumed that there is present in the field at least one expansion result, this assumption will not be restated. Field splitting only ever alters those parts of the field. For the purposes of this section, the term "IFS white space" shall mean any of the white-space bytes [xref to XBD 3.412, 3.413, and 3.414] , or from the Portable Character Set [xref XBD 6.1] which are present in the value of the IFS variable, and perhaps other white-space characters. It is implementation defined whether other white-space characters which appear in the value of IFS are also considered as "IFS white space". The three characters above specified as IFS white-space bytes are always IFS white space, when they occur in the value of IFS, regardless of whether they are white-space characters in any relevant locale. For other locale specific white-space characters allowed by the implementation it is unspecified whether the character is considered as IFS white space if it is white space at the time it is assigned to the IFS variable, or if it is white space at the time field splitting occurs (the locale may have changed between those events). If the IFS variable is unset, then for the purposes of this section, but without altering the value of the variable, its value shall be considered to contain the three single byte characters , and from the portable character set, all of which are IFS white-space characters. The shell shall use the byte sequences that form the characters in the value of the IFS variable as delimiters. Each of the characters and which appears in the value of IFS shall be a single byte delimiter. The shell shall use these delimiters as field terminators to split the results of expansions, along with other adjacent bytes, into separate fields, as described below. Note that these delimiters terminate a field, they do not, of themselves, cause a new field to start, subsequent data bytes that are not from the results of an expansion, or that do not form IFS white-space characters are required for a new field to begin. Note that the shell processes arbitrary bytes from the input fields, there is no requirement that those bytes form valid characters. If results of the algorithm are that no fields are delimited, that is, if the input field is wholly empty or consists entirely of IFS white space, the result shall be zero fields (rather than an empty field). For the purposes of this section, when a field is said to be delimited, the the candidate field, as generated below shall become an output field. When the algorithm transforms a candidate into an output field it shall be appended to the current list of output fields. Each field containing the results from an expansion shall be processed in order, intermixed with fields not containing the results of expansions, processed as described above, as if as follows, examining bytes in the input field, from beginning to end: Begin with an empty candidate field and the input as specified above. When instructed to start the next iteration of the loop, this is the start of the loop. While the input (as modified by earlier iterations of this loop) is not empty: Consider the leading remaining byte or byte sequence of the input. No such byte sequence shall contain data such that some bytes in the sequence resulted from an expansion, and others did not, or which contains bytes resulting from the results of more than one expansion. If the byte or sequence of bytes is: A byte (or sequence of bytes) in the input that did not result from an expansion: Append this byte (or sequence) to the candidate, and remove it from the input. Start the next iteration of the loop. A byte sequence in the input which resulted from an expansion that does not form a character in IFS: Append the first byte of the sequence to the candidate, and remove that byte from the input. Start the next iteration of the loop. A byte sequence in the input which resulted from an expansion that forms an IFS white space character: Remove that byte sequence from the input, consider the new leading input byte sequence, and repeat this step. A byte sequence in the input that resulted from an expansion that forms an IFS character, which is not IFS white space: Remove that byte sequence from the input, but note it was observed. At this point, if the candidate is not empty, or if a sequence of bytes representing an IFS character that is not IFS white space was seen at step 4, then a field is said to have been delimited, and the candidate becomes an output field. Empty (clear) the candidate, and start the next iteration of the loop. Once the input is empty, the candidate becomes an output field if and only if it is not empty. The ordered list of output fields so produced, which may be empty, replaces the list of input fields. Bug 1406: clarification of SEEK_END when current pointer doesn't match buffer size Accepted as Marked https://austingroupbugs.net/view.php?id=1406 New text that allows both behaviours, as an Issue 8 compromise: Add a new paragraph after issue8 draft 3 P1617. L50906 (in open_memstream()) The fseek() and fseeko() functions can be used to set the file position beyond the current buffer length. It is implementation-defined whether this extends the buffer to the new length. If it extends the buffer, the added buffer contents shall be set to null bytes for open_memstream(), or null wide characters for open_wmemstream(); if it does not extend the buffer, then if data is later written at this point, the buffer contents in the gap shall be set to null bytes for open_memstream(), or null wide characters for open_wmemstream(). If fseek() or fseeko() is called with SEEK_END as the whence argument, it is implementation-defined whether the file position shall be adjusted either relative to the current buffer length or relative to the buffer size that would be set by an fflush() call made immediately before the fseek() or fseeko() call. Next Steps ---------- We will pick up on 251 (if Don's proposal is ready) The next call is on: Thu 2023-09-28 (Zoom meeting - general bugs/ballot resolution) Mon 2023-10-02 (Zoom meeting - general bugs/ballot resolution) Apologies in advance: Geoff Clare 2023-09-11 through 2023-09-28, maybe 2023-10-02 Eric Blake 2023-10-09, 2023-10-12 The calls are for 90 minutes Calls are anchored on US time. (8am Pacific) Please check the calendar invites for dial in details. Bugs are at: https://austingroupbugs.net An etherpad is usually up for the meeting, with a URL using the date format as below: https://posix.rhansen.org/p/20xx-mm-dd (For write access this uses The Open Group single sign on, for those individuals with gitlab.opengroup.org accounts. Please contact Andrew if you need to be setup)