All
Enclosed are the minutes from yesterday's call
regards
Andrew
---------------------
Minutes of the 24th June 2021 Teleconference Austin-1140 Page 1 of 1
Submitted by Andrew Josey, The Open Group. 25th June 2021
Attendees:
Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR
Joerg Schilling
Mark Ziegast, SHware Systems Dev.
Don Cragun, IEEE PASC OR
Andrew Josey, The Open Group
Geoff Clare, The Open Group
Eric Ackermann, HPI, University of Potsdam
Eric Blake, Red Hat, The Open Group OR
Richard Hansen
Apologies:
Tom Thompson
* General news
This was a call dedicated to Issue 8 D2 bugs.
* 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 13th June 2019 and earlier)
Bug 1254: "asynchronous list" description uses "command" instead of "AND-OR
list" OPEN
https://austingroupbugs.net/view.php?id=1254
Action: Joerg to investigate how his shell behaves.
Bug 713 - Nick to raise with the C committee.
This item raised in Austin/1129 and submitted to the C committee in May 2021.
* Current Business
Bug 1448: Misleading text in description of poll() Accepted as Marked
https://austingroupbugs.net/view.php?id=1448
This item is tagged for Issue 8.
Page and line numbers are for draft 1.1 but the changes account for the
addition of ppoll() in draft 2.
In the sentence beginning on line 46801, change:
on which an application can read or write data
to:
on which an application can make an attempt to read or write data without
blocking
At line 46807, change:
POLLIN Data other than high-priority data may be read without blocking.
to:
POLLIN The file descriptor is ready for reading data other than
high-priority data.
In line 46808 change:
POLLRDNORM Normal data may be read without blocking.
to:
POLLRDNORM The file descriptor is ready for reading normal data.
In line 46809 change:
POLLRDBAND Priority data may be read without blocking.
to:
POLLRDBAND The file descriptor is ready for reading priority data.
In line 46810 change:
POLLPRI High-priority data may be read without blocking.
to:
POLLPRI The file descriptor is ready for reading high-priority data.
In line 46811 change:
POLLOUT Normal data may be written without blocking.
to:
POLLOUT The file descriptor is ready for writing normal data.
In line 46813 change:
POLLWRBAND Priority data may be written.
to:
POLLWRBAND The file descriptor is ready for writing priority data.
In line 46814 change:
An error has occurred on the device or stream.
to:
An error condition is present on the file descriptor. All error
conditions that arise solely from the state of the object
underlying the open file description and would be diagnosed by
a return of -1 from a read() or write() call on the file
descriptor shall be reported as a POLLERR event.
On line 46820 delete the words (and punctuation):
; a stream can never be writable if a hangup has occurred
On line 46824 change:
is invalid
to:
is not an open file descriptor
Before line 46826 insert a new paragraph:
A file descriptor shall be considered ready for reading when a
call to an input function with O_NONBLOCK clear would not block,
whether or not the function would transfer data successfully.
(The function might return data, an end-of-file indication, or
an error other than one indicating that it is blocked, and in
each of these cases the descriptor is considered ready for
reading.) A file descriptor shall be considered ready for writing
when a call to an output function with O_NONBLOCK clear would
not block, whether or not the function would transfer data
successfully. How much data could be written without blocking
depends upon the object underlying the open file description
and its current state.
On line 46826-7 after:
The significance and semantics of normal, priority, and
high-priority data are file and device-specific.
add:
The semantics of device disconnection are device-specific.
On line 46867 change APPLICATION USAGE from:
None
to:
When a poll() or ppoll() call indicates a file descriptor is
ready for reading, this means that if an attempt to read data
had been made at the time that the status of the file descriptor
was checked, it would have returned at least one byte of data,
an end-of-file indication, or an error, without blocking (even
if O_NONBLOCK is clear). When a poll() or ppoll() call indicates
that a file descriptor is ready for writing, this means that
if an attempt to write one byte of data had been made at the
time that the status of the file descriptor was checked, it
would have written that byte or returned an error, without
blocking. However, if an attempt to write more than one byte
had been made, it might have blocked (if O_NONBLOCK is clear).
In both cases, by the time the call returns and a subsequent
I/O operation is attempted, the state of the file descriptor
might have changed (for example, because another thread read
or wrote some data) and, if O_NONBLOCK is clear, there is no
guarantee that the operation will not block (unless it would
not block for some other reason, such as setting MIN=0 and
TIME=0 for a terminal in non-canonical mode). Therefore it is
recommended that applications always set O_NONBLOCK on file
descriptors whose readiness for I/O they query with poll() or
ppoll().
The error conditions specified for read() and write() that are
reported as POLLERR events are only those that arise solely
from the state of the object underlying the open file description.
They do not include, for example, [EAGAIN] as this relates to
the state of the open file description not (solely) the object
underlying it.
Application writers should note that repeating a poll() or
ppoll() call which indicated that I/O was possible on one or
more of the file descriptors given, without causing some change
to the state, either by altering the fds array or causing
appropriate input or output to occur on at least one file
descriptor indicated as ready, will result in ``busy waiting''
- a subsequent call will always return immediately indicating
the same (or perhaps more) events as the previous one.
On page 1480 line 49261 section pselect(), change APPLICATION USAGE from:
None
to:
When a pselect() or select() call indicates a file descriptor
is ready for reading, this means that if an attempt to read
data had been made at the time that the status of the file
descriptor was checked, it would have returned at least one
byte of data, an end-of-file indication, or an error, without
blocking (even if O_NONBLOCK is clear). When a pselect() or
select() call indicates a file descriptor is ready for writing,
this means that if an attempt to write one byte of data had
been made at the time that the status of the file descriptor
was checked, it would have written that byte or returned an
error, without blocking. However, if an attempt to write more
than one byte had been made, it might have blocked (if O_NONBLOCK
is clear). In both cases, by the time the call returns and a
subsequent I/O operation is attempted, the state of the file
descriptor might have changed (for example, because another
thread read or wrote some data) and, if O_NONBLOCK is clear,
there is no guarantee that the operation will not block (unless
it would not block for some other reason, such as setting MIN=0
and TIME=0 for a terminal in non-canonical mode). Therefore it
is recommended that applications always set O_NONBLOCK on file
descriptors whose readiness for I/O they query with pselect()
or select().
Bug 1476: Missing '+' character in the second example explanation Accept as
Marked
https://austingroupbugs.net/view.php?id=1476
This item is tagged for Issue 8
After line 104302 on page 3085 (XCU 2.14, printf, EXAMPLES), add:
The command:
printf '%d\n' 10 010 0x10
produces:
<table>
<tr><th>Output Line</th><th>Explanation</th></tr>
<tr><td><tt>10</tt></td><td>Decimal representation of the numeric value of
decimal integer constant 10</td></tr>
<tr><td><tt>8</tt></td><td>Decimal representation of the numeric value of
octal integer constant 010</td></tr>
<tr><td><tt>16</tt></td><td>Decimal representation of the numeric value of
hexadecimal integer constant 0x10</td></tr>
</table>
If the implementation supports floating-point conversions, the command:
LC_ALL=C printf '%.2f\n' 10 010 0x10 10.1e2 010.1e2 0x10.1p2
produces:
<table>
<tr><th>Output Line</th><th>Explanation</th></tr>
<tr><td><tt>10.00</tt></td><td>The string "10" interpreted as a decimal
value, with 2 digits of precision.</td></tr>
<tr><td><tt>10.00</tt></td><td>The string "010" interpreted as a decimal
(not octal) value, with 2 digits of precision.</td></tr>
<tr><td><tt>16.00</tt></td><td>The string "0x10" interpreted as a
hexadecimal value, with 2 digits of precision.</td></tr>
<tr><td><tt>1010.00</tt></td><td>The string "10.1e2" interpreted as a
decimal floating-point value, with 2 digits of precision.</td></tr>
<tr><td><tt>1010.00</tt></td><td>The string "010.1e2" interpreted as a
decimal (not octal) floating-point value, with 2 digits of precision.</td></tr>
<tr><td><tt>64.25</tt></td><td>The string "0x10.1p2" interpreted as a
hexadecimal floating-point value, with 2 digits of precision.</td></tr>
</table>
On page 3086 replace lines 104317-104325 with:
In a locale that uses a codeset based on ISO/IEC 646: 1991, the command:
printf "%d\n" 3 +3 -3 \'3 \"+3 "'-3"
produces:
<table>
<tr><th>Output Line</th><th>Explanation</th></tr>
<tr><td><tt>3</tt></td><td>Decimal representation of the numeric value
3</td></tr>
<tr><td><tt>3</tt></td><td>Decimal representation of the numeric value
+3</td></tr>
<tr><td><tt>-3</tt></td><td>Decimal representation of the numeric value
-3</td></tr>
<tr><td><tt>51</tt></td><td>Decimal representation of the numeric value of
the character <tt>'3'</tt> in the ISO/IEC 646: 1991 standard codeset</td></tr>
<tr><td><tt>43</tt></td><td>Decimal representation of the numeric value of
the character <tt>'+'</tt> in the ISO/IEC 646: 1991 standard codeset</td></tr>
<tr><td><tt>45</tt></td><td>Decimal representation of the numeric value of
the character <tt>'-'</tt> in the ISO/IEC 646: 1991 standard codeset</td></tr>
</table>
In the paragraph at line 104326, move the second sentence ("Since
the last two ...") to before the first sentence ("Note that in a
locale ...").
Bug 1478: clarify ${@?error}, ${@+set}, "${@+set}", "${*+set}"... etc.
expansions OPEN
https://austingroupbugs.net/view.php?id=1478
We started this item and will pick this up on the next thursday call.
The next call will be a gettext call.
The gettext draft in the etherpad is at
https://posix.rhansen.org/p/gettext_draft
https://posix.rhansen.org/p/gettext_split
The next D2 bugs call will be July 1st.
Next Steps
----------
The next calls are on:
June 28 2021 (Monday) Gettext
This call will be for 90 minutes.
July 1st 2021 (Thursday) General Bugs (D2 bugs)
This call will be for 90 minutes.
July 5th (Monday) NO MEETING
Calls are anchored on US time. (8am Pacific)
Apologies in advance:
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)
--------
Andrew Josey The Open Group
Austin Group Chair
Email: a.jo...@opengroup.org
Apex Plaza, Forbury Road,Reading,Berks.RG1 1AX,England
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&listid=2481
