All
Enclosed are the minutes of this weeks meeting
regards
Andrew
---
Minutes of the 11th October 2018 Teleconference Austin-889 Page 1 of 1
Submitted by Andrew Josey, The Open Group. 12th October 2018
Attendees:
Joerg Schilling, FOKUS Fraunhofer
Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR
Andrew Josey, The Open Group
Geoff Clare, The Open Group
Don Cragun, IEEE PASC OR
Martin Rehak, Oracle, The Open Group OR
Mark Ziegast, SHware Systems
Eric Blake, Red Hat
Apologies:
David Clissold, IBM
* General news
Please note that US daylight saving time ends November 4th so there
will be a week where the offset between Europe and the USA differs.
As a reminder calls are anchored on US time, so that week the call
will be one hour earlier in Europe.
* 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 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.
(update 19 Oct 2018)
There has been no reaction from the Base Working Group and the period for
comments has ended now.
Bug 1138: Add strsignal(), sig2str() and str2sig() to the standard. OPEN
http://austingroupbugs.net/view.php?id=1138
Martin has completed his action. Andrew took an action to chase
the Base Working group members for sponsorship of the two interfaces.
Bug 1139: require RE \] to match ] when outside bracket expressions Accepted as
Marked
http://austingroupbugs.net/view.php?id=1139
Geoff completed his action item to come up with specific editing instructions.
This item is tagged for Issue 8.
Proposed changes ...
On 2016 edition page 183 line 6043 section 9.3.1 change:
A BRE ordinary character, a special character preceded by a
<backslash>, or a <period> shall match a single character.
to:
When not inside a bracket expression, the following shall match
a single character:
a BRE ordinary character
a BRE special character or ']' preceded by an unescaped <backslash>
a <period>.
On 2016 edition page 183 line 6049 section 9.3.2 change:
The interpretation of an ordinary character preceded by an
unescaped <backslash> ('\\') is undefined, except for:
The characters ')', '(', '{', and '}'
The digits 1 to 9 inclusive (see [xref to 9.3.6])
A character inside a bracket expression
to:
When not inside a bracket expression, the interpretation of an
ordinary character preceded by an unescaped <backslash> is
undefined, except for:
The characters ')', '(', '{', and '}'
The digits 1 to 9 inclusive (see [xref to 9.3.6])
The ']' character; "\]" shall match a ']' character
On 2016 edition page 184 line 6056 section 9.3.3 change:
preceded by a <backslash>
to:
preceded by an unescaped <backslash>
On 2016 edition page 184 line 6073 section 9.3.4 change:
A <period> ('.'), when used outside a bracket expression, is ...
to:
When not inside a bracket expression, a <period> ('.') is ...
On 2016 edition page 188 line 6261 section 9.4.1 change:
An ERE ordinary character, a special character preceded by a
<backslash,> or a <period> shall match a single character.
to:
When not inside a bracket expression, the following shall match
a single character:
an ERE ordinary character
an ERE special character, ']', or '}' preceded by an unescaped
<backslash>
a <period>.
On 2016 edition page 188 line 6268 section 9.4.2 change:
The interpretation of an ordinary character preceded by an
unescaped <backslash> ('\\') is undefined, except in the context
of a bracket expression (see [xref to 9.4.5]).
to:
When not inside a bracket expression, the interpretation of an
ordinary character preceded by an unescaped <backslash> is
undefined, except for the ']' and '}' characters; "\]" and "\}"
shall match the ']' and '}' characters, respectively.
On 2016 edition page 189 line 6272 section 9.4.3 change:
preceded by a <backslash>
to:
preceded by an unescaped <backslash>
On 2016 edition page 189 line 6277 section 9.4.3 change:
Outside a bracket expression, a <left-parenthesis> immediately
followed by a <right-parenthesis> produces undefined results.
to:
When not inside a bracket expression, an unescaped <left-parenthesis>
immediately followed by a <right-parenthesis> produces undefined
results.
On 2016 edition page 189 line 6281 section 9.4.3 change:
both outside a bracket expression
to:
both not inside a bracket expression
On 2016 edition page 189 line 6298 section 9.4.4 change:
A <period> ('.'), when used outside a bracket expression, is ...
to:
When not inside a bracket expression, a <period> ('.') is ...
On 2016 edition page 191 line 6364 section 9.4.9 change:
when used anywhere outside a bracket expression
to:
when used anywhere except inside a bracket expression
On 2016 edition page 191 line 6365 section 9.4.9 change:
A <circumflex> ('^') outside a bracket expression shall ...
to:
When not inside a bracket expression, a <circumflex> ('^') shall ...
On 2016 edition page 191 line 6371 section 9.4.9 change:
A <dollar-sign> ('$') outside a bracket expression shall ...
to:
When not inside a bracket expression, a <dollar-sign> ('$') shall ...
On 2016 edition page 192 line 6406 section 9.5.1 change:
In a BRE, one of the character sequences:
\^ \. \* \[ \$ \\
In an ERE, one of the character sequences:
\^ \. \[ \$ \( \) \|
\* \+ \? \{ \\
to:
In a BRE, one of the character sequences:
\^ \. \* \[ \] \$ \\
In an ERE, one of the character sequences:
\^ \. \[ \] \$ \( \) \|
\* \+ \? \{ \} \\
On 2016 edition page 193 line 6416,6417,6418,6425 section 9.5.1 change:
Anywhere outside bracket expressions
to:
Anywhere except inside bracket expressions
Bug 1140: must the encoded output end with a zero-length line? Accepted as
Marked
http://austingroupbugs.net/view.php?id=1139
This item is tagged for TC3-2008
An interpretation is required.
Interpretation response:
The standard states the historical uuencode output format, and conforming
implementations must conform to this. However, concerns have been raised about
this which are being referred to the sponsor.
Rationale:
Almost all uudecode implementations require a line just before the "end" line
specifying a line of zero bytes to be converted. Some historic uuencode
implementations output a <back-quote> while others output of a <space> to
encode this zero length final line. The changes below allow either historic
behavior.
Notes to the Editor (not part of this interpretation):
Make the changes in Note: 0004150.
Note 4150:
On 2016 edition page 3362 line 113245 section uuencode, change:
These octets shall be converted to characters by adding a value
of 0x20 to each octet, so that each octet is in the range
[0x20,0x5f], and then it shall be assumed to represent a printable
character in the ISO/IEC 646:1991 standard encoded character
set. It then shall be translated into the corresponding character
codes for the codeset in use in the current locale. (For example,
the octet 0x41, representing 'A', would be translated to 'A'
in the current codeset, such as 0xc1 if it were EBCDIC.)
to:
These octets shall be converted to characters in the ISO/IEC
646:1991 standard encoded character set by adding a value of
0x20 to each octet, so that each octet is in the range [0x20,0x5f],
and then optionally replacing any 0x20 octets with 0x60. If
necessary, these characters shall then be translated into the
corresponding character codes for the codeset in use in the
current locale. For example, the octet 0x41, representing 'A',
would be translated to 'A' in the current codeset, such as 0xc1
if it were EBCDIC; the octet 0x20, representing <space>, would
optionally be replaced with 0x60, representing '`', and then
translated to either <space> (0x40 if EBCDIC) or '`' (0x79 if
EBCDIC), respectively.
On 2016 edition page 3362 line 113258 section uuencode, change:
These octets then shall be translated into the local character set.
to:
before any replacement of 0x20 with 0x60 and translation into the local
character set.
On 2016 edition page 3362 line 113259 section uuencode, change:
Each encoded line contains a length character, equal to the
number of characters to be decoded plus 0x20 translated to the
local character set as described above, followed by the encoded
characters. The maximum number of octets to be encoded on each
line shall be 45.
to:
Each encoded line shall contain a length character, equal to
the number of characters to be decoded plus 0x20 translated to
the local character set as described above, followed by between
1 and 45, inclusive, encoded characters. The last encoded line,
or the <tt>begin</tt> line if the input is empty, shall be
followed by a line containing only a <space> or '`' character
before the terminating <newline>.
On 2016 edition page 3364 line 113309 section uuencode, add a new paragraph to
RATIONALE:
Historically the encoding used only octets in the range
[0x20,0x5f], and thus the encoded lines could contain trailing
spaces, which were at risk of being stripped by whatever transport
method was used to send the file. To avoid this problem some
implementations use 0x60 instead of 0x20, resulting in '`'
characters instead of spaces in the output, and implementations
are encouraged to do this.
Bug 1141: Add WCOREDUMP(stat) to sys/wait.h OPEN
http://austingroupbugs.net/view.php?id=1141
We started discussing this item and will continue next time.
Next Steps
----------
The next call is on October 25th 2018 (Thursday).
Apologies in Advance:
Eric Blake, 2018-10-25
Martin Rehak, 2018-10-25
Andrew Josey, 2018-11-01
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#
--------
Andrew Josey The 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&listid=2481
