Minutes of the 12th September 2013 Teleconference Austin-626 Page 1 of 1
Submitted by Andrew Josey, The Open Group. 13th September 2013
Attendees
Don Cragun, PASC OR
Geoff Clare, The Open Group
Eric Blake, Red Hat
Andrew Josey, The Open Group
Mark Brown
Richard Hansen, BBN
David Clissold, IBM
Mark Ziegast
Nick Stoughton, USENIX, ISO/IEC OR
Apologies
Joerg Schilling, Fraunhofer Society
* General news
No news.
* Outstanding actions
+Bug 0000251: Forbid newline, or even bytes 1 through 31 (inclusive), in filenames OPEN
http://austingroupbugs.net/view.php?id=251
Don has an action to produce a proposal.
+Bug 0000561: NUL-termination of sun_path in Unix sockets OPEN
http://austingroupbugs.net/view.php?id=561
Eric has an action to update the proposal.
+Bug 0000573: Please add '+' to the portable filename character set OPEN
http://austingroupbugs.net/view.php?id=573
Joerg has an action to prepare a proposed change.
+Bug 0000592: consistent use of struct timespec OPEN
http://austingroupbugs.net/view.php?id=592
Jim had provided additional information in bugnote 1627.
This was discussed and Jim took an action to provide further information.
+Bug 0000598: OH shading and new interfaces OPEN
http://austingroupbugs.net/view.php?id=598
Eric has an action to propose a new solution with self-contained headers.
+Bug 0000517: EBNF support OPEN
http://austingroupbugs.net/view.php?id=517
Action on Joerg to look at this.
+Bug 0000633: SIGEV_THREAD delivery renders many signal interfaces unsafe
OPEN
http://austingroupbugs.net/view.php?id=633
We noted that feedback has settled down on the mailing list, and
will discuss next session.
+Bug 0000657: Conditions under which fmemopen() write a NUL to the buffer
are insufficiently specified OPEN
http://austingroupbugs.net/view.php?id=657
Eric has an action to propose wording to clarify the behavior for
fmemopen(), and also to contact the glibc developers to get their
feedback.
+Bug 0000658: Undefined/unspecified behavior clauses in description of
open have race conditions OPEN
http://austingroupbugs.net/view.php?id=658
It was noted that there is some overlap with changes in TC1. Eric took an
action to update the proposal to resolve the overlaps appropriately.
+Bug 0000615: pthread_setcancelstate should be async-signal-safe OPEN
http://austingroupbugs.net/view.php?id=615
We now have reports on AIX and Apple. Jim to report back on whether
pthread_cancelstate() is async-signal-safe on Solaris. Andrew to ask
HP whether pthread_cancelstate() is async-signal-safe on HP-UX.
+Bug 622 left open pending resolution of 615.
http://austingroupbugs.net/view.php?id=622
+Bug 0000672: Necessary step(s) to synchronize filename operations on disk
OPEN
http://austingroupbugs.net/view.php?id=672
Geoff has a new proposed resolution in note 1618. Decided to solicit input
from FS developers. Eric to go to Linux, David to AIX and Jim to Solaris.
Jim has completed his action (see bugnote 1691).
Andrew should chase HP and Apple for input.
+Bug 0000663: Specification of str[n]casecmp is ambiguous reopened
http://austingroupbugs.net/view.php?id=663
Action on David to follow up with the IBM developers about the EBCDIC
collation sequence.
Bug 696 either NAME_MAX shouldn't be optional, or readdir_r() needs clarification
http://www.austingroupbugs.net/view.php?id=696
Don has an action to propose a resolution.
Bug 0000721: Internal storage vs static storage OPEN
http://austingroupbugs.net/view.php?id=721
This item is still open.
* Current Business
Andrew has circulated a response to the following below:
(mail sequence 19739)
Action: Andrew to ask David Korn whether ksh 'test ! = -o a' is a bug in ksh vs.
the standard (for XSI, standard appears to require "! \( = -o a \)", ksh
appears to use "\( ! = \) -o a") (completed after the meeting)
Response:
When test was about to be standardized, I pointed out that there were
several differences between at&t and bsd and more importantly there
was no way to know whether an argument was an operator or an operand
for test since (, ), !, -o, and -a and = are all valid file names.
I recommented replacing test and [...] with [[...]] which was built into
the shell grammar and did not have these problems. This idea was put into
an early posix draft and removed because it was too much invention
and so many script already used test and [.
The standard decided to standarized a subset of test which would account
for the vast majority of it use, This covered all three argument tests
and 4 argument tests beginning with !.
However, subsequent to the original standard, XSI-conformant systems
added two other requirement. One of these is to handle the case of 4
argument test command where the first argument is '('. I was unaware
of this until I read the current standard. I will fix ksh to adhere
to this. The second requirement which tries to standarize behavior beyond 4
arguments in my option is nonsense and will only lead to ambiguous behavior.
Subsequent to the standard, most, if not all, shells have added [[ ...]].
I would encourange this to be standarized and remove the standarization
of test beyond the four arguments in the standard.
--
We agreed to pick up on this item next time.
Bug 0000741: Add a NSIG constant (or, alternatively, SIGMAX) Accepted as Marked
http://austingroupbugs.net/view.php?id=741
The rest of the call was spent on this item.
This item is tagged for Issue 8.
http://austingroupbugs.net/view.php?id=741#c1834
Changes:
in page 282 after line 9359, add:
{NSIG_MAX}
Maximum possible return value of sysconf(_SC_NSIG). See
[cross-ref to XSH sysconf()]. The value of {NSIG_MAX} shall
be no greater than the number of signals that the sigset_t
type (see [cross-ref to ]) is capable of representing,
ignoring any restrictions imposed by sigfillset() or
sigaddset().
Add to RATIONALE on P283, before L9380:
{NSIG_MAX}
Some historical implementations provided compile-time
constants NSIG or SIGMAX to define the maximum number of
signals the implementation supported, but these values did
not neccessarily reflect the number of signals that could
be handled using a sigset_t. With the addition of real-time
signals and the desire by some applications to be able to
allocate additional real-time signals at run-time, neither
of these constants provided a useable, portable value.
NSIG_MAX was added to the standard to allow applications
to determine the maxiumum number of signals that an
implementation will support based on the size of the sigset_t
type (defined in ).
in page 332 line 11083 after:
The range SIGRTMIN through SIGRTMAX inclusive shall include at
least {RTSIG_MAX} signal numbers.
append:
The value of SIGRTMAX shall be less than the value returned by
sysconf(_SC_NSIG).
in page 332 line 11087 change:
The macros shall expand to positive integer constant expressions
with type int and distinct values.
to:
The macros shall expand to positive integer constant expressions
with type int and distinct values [CX]less than the value of
{NSIG_MAX} defined in [/CX].
in page 444 after line 15055 add:
_SC_NSIG
in sysconf() [XSH] to the table between page 2077 and 2079 in an
appropriate place (e.g. at the end) add the following:
Highest supported signal number +1 _SC_NSIG
To the Rationale, Add after p 2081 line 66479:
Note that sysconf(_SC_NSIG) is less than or equal to {NSIG_MAX}.
A future version may allow it to be larger.
Next Steps
----------
The next call is on September 19, 2013 (a Thursday)
We should pick up on the email item and also bug 714.
Calls are anchored on US time.
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
We are now using an Etherpad for note taking
- the URL is given at the start of the meeting in IRC