All
Enclosed are the minutes for this weeks call. We have a two week break before
the next call.
Happy Holidays!
regards
Andrew
------------------------------
Minutes of the 14th December 2017 Teleconference Austin-848 Page 1 of 1
Submitted by Andrew Josey, The Open Group. 15th December 2017
Attendees:
Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR
Don Cragun, IEEE PASC OR
Geoff Clare, The Open Group
Andrew Josey, The Open Group (partial)
Andreas Grapentin, University of Potsdam, HPI
Joerg Schilling FOKUS Fraunhofer
David Clissold, IBM (2nd half)
Eric Blake, Red Hat
Martin Rehak, Oracle, The Open Group OR
Richard Hansen, Google
Mark Ziegast, SHware Systems Dev. Co.
* General news
Andrew and Nick reported that they had been on a call with the ISO
secretariat. This was related to the standardization at ISO. Some
concerns had been raised at SC22. We agreed that we would revert
back to the previous paths for future editions (ISO/IEC), but the
latest publication was ISO/IEC/IEEE. Nick and Andrew need to hold
a meeting with Keld regarding status.
There will be a two week break before we pick up in the New Year.
* 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 28 Jan 2016)
Bug 0000249: Add standard support for $'...' in shell Reopened
http://austingroupbugs.net/bug_view_page.php?bug_id=249
We will return to bug 249 on a future call.
Bug 0000953: Alias expansion is under-specified Was Accepted as Marked
http://austingroupbugs.net/view.php?id=953
Richard has an action to propose new wording to discuss in a future telecon.
* Current Business
Bug 1064: basename() and dirname(): Specification is not complete enough to
allow existing thread-unsafe implementations Accept as Marked
http://austingroupbugs.net/bug_view_page.php?bug_id=1064
This item is tagged for issue 8.
(All page and line numbers are for the 2016 edition)
On page 513 lline 17908,17921 XSH section 2.9.1, remove basename()
and dirname() from the list of functions that need not be thread-safe.
>From the basename() and dirname() pages, remove the following two
sentences:
The basename() function need not be thread-safe.
from P624, L21565, and:
The dirname() function need not be thread-safe.
from P736, L25075.
In basename(), page 624 line 21557-21558, change:
the string "/". If the string pointed to by path is exactly
"//", it is implementation-defined whether '/' or "//" is
returned.
to:
the string "/", except that if the string pointed to by path
is exactly "//", it is implementation-defined whether "/" or
"//" is returned.
In the basename() article on P624, L21561-21564, change this sentence:
The basename() function may modify the string pointed to by
path, and may return a pointer to internal storage. The returned
pointer might be invalidated or the storage might be overwritten
by a subsequent call to basename().
to:
The basename() function may modify the string pointed to by
path, and may return a pointer into the input string. The
returned pointer might be invalidated if the input string is
subsequently modified or freed. If path is a null pointer or
points to an empty string, or if the string pointed to by path
consists entirely of the '/' character, the returned pointer
may point to constant data that cannot be modified.
On page 624 line 21567 section basename() add a new paragraph to
the RETURN VALUE section:
The basename() function shall always be successful and no return
value is reserved to indicate an error.
In APPLICATION USAGE on page 625 line 21598 change:
None.
to:
Note that in some circumstances (in particular, when the returned
string is required to be "/" or "."), the returned pointer might
point into constant data. Therefore, if the application needs
to modify the returned data, it should be copied first.
On P736 L25069-25071 change:
Trailing <tt>'/'</tt> characters in the path that are not also
leading <tt>'/'</tt> characters shall not be counted as part
of the path.
If path does not contain
to:
Trailing <tt>'/'</tt> characters in the pathname that are not
also leading <tt>'/'</tt> characters shall not be counted as
part of the pathname.
If the pathname does not contain
In the dirname() article on P736, L25073-25074, change this sentence:
The dirname() function may modify the string pointed to by path,
and may return a pointer to static storage that may then be
overwritten by a subsequent call to dirname().
to:
The dirname() function may modify the string pointed to by path,
and may return a pointer into the input string. The returned
pointer might be invalidated if the input string is subsequently
modified or freed. If path does not contain a '/', is a null
pointer, or points to an empty string the returned pointer may
point to constant data that cannot be modified.
On page 736 line 25078 section dirname(), in RETURN VALUE change:
The dirname( ) function may modify the string pointed to by
path, and may return a pointer to internal storage. The returned
pointer might be invalidated or the storage might be overwritten
by a subsequent call to dirname( ). The returned pointer might
also be invalidated if the calling thread is terminated.
to:
The dirname() function shall always be successful and no return
value is reserved to indicate an error.
In dirname() APPLICATION USAGE, P737, L25110-25111 change:
Since the meaning of the leading "//" is implementation-defined,
dirname("//foo) may return either "//" or '/' (but nothing
else).
to:
Since the meaning of the leading "//" is implementation-defined,
dirname("//foo") may return either "//" or "/" (but nothing
else).
Note that in some circumstances, the returned pointer might
point into constant data. Therefore, if the application needs
to modify the returned data, it should be copied first.
(note two quoting fixes: the closing double quotes character after
//foo, and change from single quote marks to double quote marks
around the returned single /)
Change P625, L21600 AND P737, L25113 basename() and dirname()
RATIONALE sections from:
None.
to:
Earlier versions of this standard seemed to allow thread-safe
and non-thread-safe implementations of basename() and dirname(),
but did not allow implementations to return a NULL pointer and
require that errno be set when that happened. The standard now
requires thread-safe behavior for both of these functions and
clearly states that they are always successful.
Bug 1065: Clarification request on invocations Rejected
http://austingroupbugs.net/bug_view_page.php?bug_id=1065
Rejected for the reasons stated in bugnote:3361.
eblake (manager)
2016-08-25 15:29
The general use of '--help' is unspecified; applications can do
whatever they want with it (the two most common behaviors are to
reject the second '-' as an unknown short option character, or to
display help text, but there is no required behavior). Remember,
XBD 12.2 guideline 3 states that an option must have an alphanumeric
character after the '-', but '--help' does not fit that bill; and
the standard then goes on to state that the guidelines are requirements
on standard utilities that do not specify otherwise (and true does
not specify otherwise); but also specifically allows for extensions:
"On some implementations, the utilities accept usage in violation
of these guidelines for backwards-compatibility as well as accepting
the required form."
GNU's 'true --help' behavior is not specified by the standard,
because the mere use of '--help' puts the usage outside the realm
of defined behavior. Once you invoke an application with arguments
that do not have specified behavior, you are no longer guaranteed
a particular exit status. Likewise, you are correct in noting that
even 'true garbage' is undefined behavior by the standard for passing
an argument where the standard did not document one as permitted,
and thus is not portably required to have exit status 0. The whole
point of unspecified options is that they are unspecified, and we
cannot portably define behavior for them.
Bug 1067: missing socket() error for unsupported socket type OPEN
http://austingroupbugs.net/bug_view_page.php?bug_id=1067
if ((type != SOCK_RAW) && (type != SOCK_DGRAM)) {
*errorp = ESOCKTNOSUPPORT;
return (NULL);
}
Action on Geoff to propose wording which allows all three existing
behaviours for Issue 8 but with the EPROTOTYPE and EPROTONOSUPPORT
errors marked OB with the aim of requiring ESOCKTNOSUPPORT in Issue
9.
Bug 1068: Binding to a system-assigned port. OPEN
http://austingroupbugs.net/bug_view_page.php?bug_id=1068
We started discussions and will continue next time.
Next Steps
----------
The next call is on January 4th, 2017 (a Thursday)
Calls are anchored on US time. (8am Pacific)
This call will be for the regular 90 minutes.
http://austingroupbugs.net
An IRC channel will be available for the meeting
irc://irc.freenode.net/austingroupbugs
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
