All
Enclosed are the minutes of this weeks meeting
regards
Andrew
-------------------
Minutes of the 10th July 2025 Teleconference Austin-1463 Page 1 of 1
Submitted by Andrew Josey, The Open Group. 12th July 2025
Attendees:
Andrew Josey, The Open Group
Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR
Geoff Clare, The Open Group
Mark Brown
Eric Ackermann, CISPA
Malia Zaman, IEEE-SA
Haelwenn Monnier, The Open Group
Apologies
Eric Blake, Red Hat, The Open Group OR
* General business
We confirmed the calendar for upcoming meetings, the next meeting
is July 17th.
Malia Zaman raised the topic of policies and procedures for an IEEE
meeting, for example a call for declaration of patents. A discussion
followed about the Austin Group being a joint working group of the
three bodies and how we have organizational reps and operate under
the JDOCS procedures.
Andrew will add links to the procedures of the Austin Group,
and the three bodies to the etherpad.
We noted that we had not heard from Don Cragun now for an extended period.
Don is the IEEE-SA organizational representative and has rarely missed
a meeting in over 20+ years participation.
Andrew took an action to reach out to mutual acquaintances.
* Carried Forward
Bug 1927: Add sponge utility
https://www.austingroupbugs.net/view.php?id=1927
[Action to Eric B] Start a 30-day request for comments on whether The Open
Group should sponsor the addition of this interface.
glibc realloc() behavior
[Action to Eric B] - respond to the thread and invite Alejandro to
open a bug against POSIX if we still need to address wording issues
Update 2025-06-26: discussion on mailing lists is still ongoing;
EricB or Alejandro will open a bug soon
* New Business
Bug 1924: New word splitting requirements inappropriate in locales with
non-self-synchronising character encodings
https://www.austingroupbugs.net/view.php?id=1924
Accepted as marked, resolved, tc1-2024 tag
No new feedback had been received on this bug so we accepted the resolution.
In the June 5, 2025 teleconference the issues raised since the
original resolution were discussed. The following is a new proposed
resolution but the issue is being left open for feedback.
After page 79 line 2388 section 3 Definitions, add:
3.328 Self-synchronizing Character Encoding
A character encoding in which no contiguous subset (other than
the encoding of each character) of bytes from the encoding of
any one character or two adjacent characters can also represent
the encoding of any valid character on its own.
and renumber the later subsections.
On page 120 line 3840 section 6.2, change:
Likewise, the byte values used to encode <period>, <slash>,
<newline>, and <carriage-return> shall not occur as part of any
other character in any locale.
to:
Likewise, the byte values used to encode <newline>, <carriage-return>,
<tab>, <space>, <hyphen-minus>, <period>, <slash>, and <colon>
shall not occur as part of any other character in any locale.
On page 2481 line 80454 section 2.5.3 Shell Variables (IFS), after:
If the value of IFS includes any bytes that do not form part
of a valid character, the results of field splitting, expansion
of '*', and use of the read utility are unspecified.
add a sentence:
If the current locale's character encoding is not self-synchronizing
and the value of IFS includes any character for which the byte
encoding can overlap with the byte encoding of any other sequence
of characters, the results of field splitting, expansion of
'*', and use of the read utility are unspecified.
and two small-font notes:
<small>Note: The UTF-8 encoding is self-synchronizing, meaning
that no character's encoding can be confused with any other
sequence of characters, and thus all characters are safe to use
in IFS when the current locale uses this encoding.</small>
<small>Note: [xref to XBD 6.2 Character Encoding] specifies a
set of characters from the portable character set whose byte
values are not allowed to occur as part of any other character
in any locale. These characters are safe to use in IFS with any
locale.</small>
Given the decision to progress the standard through the IEEE PSDO
process we decided to revisit the bugs that had been submitted in
response to the ISO editorial comments.
On a related matter Andrew took an action to contact Jodi Haasz to
get the latest status of the PSDO submission.
Bug 1863: ISO editors Issue 8 comment 015
https://www.austingroupbugs.net/view.php?id=1863
Not needed now we are submitting to ISO via IEEE PSDO? Or worth doing anyway?
Worth doing.
Bug 1864: ISO editors Issue 8 comment 045
https://www.austingroupbugs.net/view.php?id=1864
Not needed now we are submitting to ISO via IEEE PSDO? Or worth doing anyway?
Worth doing.
Bug 1865: ISO editors Issue 8 comment 053
https://www.austingroupbugs.net/view.php?id=1865
Not needed now we are submitting to ISO via IEEE PSDO? Or worth doing anyway?
Worth doing.
Bug 1867: ISO editors Issue 8 comment 046
https://www.austingroupbugs.net/view.php?id=1867
Final accepted text updated to new note (7220).
Not needed now we are submitting to ISO via IEEE PSDO? Or worth doing anyway?
If we make a change here we may also need to revisit bug 1885 (whose resolution
uses the <domain> style for definitions).
GWC: IMO this is just a style thing and not needed, except for the deletion of
unused definition "Local Interprocess Communication (Local IPC)".
On page 59 line 1828 section 3.192, delete:
<blockquote>3.192 Local Interprocess Communication (Local IPC)The transfer
of data between processes in the same system.</blockquote>
Add the following definitions in the appropriate place:
3.xxx BRE
<blockquote>See [xref to 3.43 Basic Regular Expression
(BRE)].</blockquote>
3.yyy ERE
<blockquote>See [xref to 3.134 Extended Regular Expression
(ERE)].</blockquote>
3.zzz Not a Number
<blockquote>See [xref to 3.217 NaN (Not a Number)].</blockquote>
Bug 1885 Definition of "name" omits its use as a verb
https://www.austingroupbugs.net/view.php?id=1868
Accepted as Marked, resolved, tc1-2024 tag
On page 63 line 1928 section 3.216, change:
<blockquote><b>3.216 Name</b>
<blockquote>In the shell command language, a word consisting
solely of underscores, digits, and alphabetics from the portable
character set. The first character of a name is not a digit.
<small><b>Note:</b> The Portable Character Set is defined in
detail in [xref to 6.1].</small></blockquote></blockquote>
to:
<blockquote><b>3.216 Name</b>
<blockquote>In the context of the shell command language, when
used as a noun: a word consisting solely of underscores, digits,
and alphabetics from the portable character set. The first
character of a name is not a digit.
<small><b>Note:</b> The Portable Character Set is defined in
detail in [xref to 6.1].</small>
In the context of file naming, when used as a verb, a pathname
is said to name a particular file (or file type) if the pathname
resolves to a directory entry for that file (or a file of that
type).
<small><b>Note:</b> Pathname resolution is defined in detail
in [xref to 4.16].</small></blockquote></blockquote>
Bug 1868: ISO editors Issue 8 comment 051
https://www.austingroupbugs.net/view.php?id=1868
Withdrawn, closed
Bug 1869: ISO editors Issue 8 comment 055
https://www.austingroupbugs.net/view.php?id=1869
Not needed now we are submitting to ISO via IEEE PSDO? Or worth doing anyway?
Worth doing.
Bug 1870: ISO editors Issue 8 comment 070
https://www.austingroupbugs.net/view.php?id=1870
Not needed now we are submitting to ISO via IEEE PSDO? Or worth doing anyway?
Worth doing.
Bug 1871: ISO editors Issue 8 comment 031
https://www.austingroupbugs.net/view.php?id=1871
Not needed now we are submitting to ISO via IEEE PSDO? Or worth doing anyway?
Worth doing.
Bug 1873: ISO editors Issue 8 comment 114
https://www.austingroupbugs.net/view.php?id=1873
Not needed now we are submitting to ISO via IEEE PSDO? Or worth doing anyway?
Worth doing.
Bug 1874: ISO editors Issue 8 comment 052
https://www.austingroupbugs.net/view.php?id=1874
Not needed now we are submitting to ISO via IEEE PSDO? Or worth doing anyway?
Worth doing.
Bug 1875: ISO editors Issue 8 comment 056
https://www.austingroupbugs.net/view.php?id=1875
Not needed now we are submitting to ISO via IEEE PSDO? Or worth doing anyway?
Worth doing.
Bug 1877: ISO editors Issue 8 comment 068
https://www.austingroupbugs.net/view.php?id=1877
Not needed now we are submitting to ISO via IEEE PSDO? Or worth doing anyway?
Worth doing.
Bug 1878: ISO editors Issue 8 comments 061+072
https://www.austingroupbugs.net/view.php?id=1878
Withdrawn.
Bug 1929: features of SOCK_SEQPACKET in documentation of certain System
Interfaces contradict its definition in the Base Definitions
https://www.austingroupbugs.net/view.php?id=1929
Accepted as marked, resolved, tc1-2024
Changes (reusing wording from XSH 2.10.6) ...
On page 1875 line 61902 section recv(), and
page 1878 line 61997 section recvfrom(), and
page 1881 line 62113 section recvmsg(), change:
For message-based sockets, such as [...], the entire message
shall be read in a single operation.
to:
For message-based sockets, such as SOCK_DGRAM [RS]and SOCK_RAW[/RS],
the entire message shall be read in a single operation.
On page 1875 line 61905 section recv(), and
page 1878 line 62000 section recvfrom(), change:
For stream-based sockets, such as SOCK_STREAM, message boundaries
shall be ignored. In this case, data shall be returned to the
user as soon as it becomes available, and no data shall be
discarded.
to:
For stream-based sockets, such as SOCK_STREAM, record boundaries
shall be ignored; data sent on a stream-based socket using
output operations of one size can be received using input
operations of smaller or larger sizes; data shall be returned
to the user as soon as it becomes available and no data shall
be discarded. For stream-based sockets with maintained record
boundaries, such as SOCK_SEQPACKET, a record can be sent using
one or more output operations and received using one or more
input operations, but a single operation shall never transfer
parts of more than one record; in order to differentiate the
end of a record from a short read, it is necessary to use the
recvmsg() function instead of recv() or recvfrom().
On page 1881 line 62117 section recvmsg(), change:
For stream-based sockets, such as SOCK_STREAM, message boundaries
shall be ignored. In this case, data shall be returned to the
user as soon as it becomes available, and no data shall be
discarded.
to:
For stream-based sockets, such as SOCK_STREAM, record boundaries
shall be ignored; data sent on a stream-based socket using
output operations of one size can be received using input
operations of smaller or larger sizes; data shall be returned
to the user as soon as it becomes available and no data shall
be discarded. For stream-based sockets with maintained record
boundaries, such as SOCK_SEQPACKET, a record can be sent using
one or more output operations and received using one or more
input operations, but a single operation shall never transfer
parts of more than one record; if the received data ends on a
record boundary, MSG_EOR shall be set in the msg_flags member
of the msghdr structure.
Bug 1930: Add flock(1) utility to manage locks from shell scripts
https://www.austingroupbugs.net/view.php?id=1930
We will start on this one next time.
* Next Steps
We will start on the latest open bug or loop back to bug 1616.
The next calls are on
Thu 2025-07-17 (WEBEX meeting - general bugs)
Apologies in advance
2025-07-17 Eric Blake
2025-07-17 Malia Zaman
2025-07-17 Mark Brown
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)
--------
Andrew Josey The Open Group
Austin Group Chair
Email: [email protected]
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
