Andrew Josey
2014-06-07 05:19:46 UTC
All
Enclosed are the minutes of the 5th June 2014 Teleconference
regards
Andrew
------
Minutes of the 5th June 2014 Teleconference Austin-658 Page 1 of 1
Submitted by Andrew Josey, The Open Group. 6th June 2014
Attendees:
Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR
Geoff Clare, The Open Group
Don Cragun, IEEE PASC OR
Andrew Josey, The Open Group
David Clissold, IBM
Richard Hansen, BBN
Eric Blake, Red Hat
Mark Brown, Canonical
Joerg Schilling
Apologies
Mark Ziegast, SHware Systems
Martin Rehak, Oracle
* General news
Geoff now has write access to the SVN repository and so is continuing the
edits to the current TC2 defects.
We discussed when we might have the cutoff for TC2 defect reporting.
This will be driven by when the IEEE PAR is approved.
Andrew took an action to draft the PAR (based on the previous PAR)
and also to draw up an outline timeline, so we can make a decision
on when to submit.
(The following occurred after the meeting)
Regarding the action below - Andrew reported back by email to the core team
that we could action captions to the tables, but that would probably
be best done for issue 8:
"A query was raised about table labelling in the specification.
Andrew took an action to check with our editor and report back to the group."
* 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 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.
Bug 0000375: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef OPEN
http://austingroupbugs.net/view.php?id=375
This is still left open due to discussions pending on the reflector.
Bug 0000789: Add set -o pipefail OPEN
http://austingroupbugs.net/view.php?id=789
* Current Business
Bug #811: precondition for mutex destruction unclear; example contradicts normative text OPEN
http://www.austingroupbugs.net/view.php?id=811
We have left this item open pending further input from Dave Butenhof on
supplying a new example.
Bug #622: Disallow loophole for asynchronous cancellation of any function Accepted as Marked
http://austingroupbugs.net/view.php?id=622
This item is tagged for TC2-2008
At page 515 line 17840 section 2.9.5.4 Async-Cancel Safety add two paragraphs:
If a thread has asynchronous cancellation enabled and is cancelled
during execution of a function that is not async-cancel-safe,
the behavior is undefined.
If a thread has deferred cancellation enabled, a signal catching
function is called in that thread during execution of a function
that is not async-cancel-safe, and the signal catching function
calls any function that is a cancellation point while a
cancellation is pending for the thread, the behavior is undefined.
Change "None." at page 1694, line 54327 section APPLICATION USAGE in pthread_setcancelstate() to:
In order to write a signal handler for an asynchronous signal
which can run safely in a cancellable thread, pthread_setcancelstate()
must be used to disable cancellation for the duration of any
calls that the signal handler makes which are cancellation
points. However, the standard does not permit strictly conforming
applications to call pthread_setcancelstate() from a signal
handler since it is not currently required to be async-signal-safe.
On implementations where pthread_setcancelstate() is not
async-signal-safe, alternatives are to ensure either that the
corresponding signals are blocked during execution of functions
that are not async-cancel-safe or that cancellation is disabled
during times when those signals could be delivered. Implementations
are strongly encouraged to make pthread_setcancelstate()
async-signal-safe.
Bug 0000841: pthread_setcancelstate should be async-signal-safe Accepted as Marked
http://austingroupbugs.net/view.php?id=841
This item is tagged for Issue 8
This bug was updated (previously it had been Accepted)
At page 489 lines 16722-16755 (XSH 2.4.3) insert:
pthread_setcancelstate()
After applying the changes from 0000615, at page 489 line 16756
(XSH 2.4.3 Signal Actions), change:
Implementations may make other interfaces async-signal-safe.
to:
It is implementation-defined which additional interfaces, if
any, are also async-signal-safe.
After applying the changes from 0000622, at page 515 line 17840
section 2.9.5.4 Async-Cancel Safety, change:
If a thread has deferred cancellation enabled, a signal catching
function is called in that thread during execution of a function
that is not async-cancel-safe, and the signal catching function
calls any function that is a cancellation point while a
cancellation is pending for the thread, the behavior is undefined.
to:
If a thread has deferred cancellation enabled, a signal catching
function is called in that thread during execution of a function
that is not async-cancel-safe, and the signal catching function
calls any function that is a cancellation point while a
cancellation is pending for the thread, without first disabling
cancellation, the behavior is undefined.
After applying the changes from 0000622, at page 1694 line 54327
(pthread_setcancelstate() application usage), change:
In order to write a signal handler for an asynchronous signal
which can run safely in a cancellable thread, pthread_setcancelstate()
must be used to disable cancellation for the duration of any
calls that the signal handler makes which are cancellation
points. However, the standard does not permit strictly conforming
applications to call pthread_setcancelstate() from a signal
handler since it is not currently required to be async-signal-safe.
On implementations where pthread_setcancelstate() is not
async-signal-safe, alternatives are to ensure either that the
corresponding signals are blocked during execution of functions
that are not async-cancel-safe or that cancellation is disabled
during times when those signals could be delivered. Implementations
are strongly encouraged to make pthread_setcancelstate()
async-signal-safe.
to:
In order to write a signal handler for an asynchronous signal
which can run safely in a cancellable thread, pthread_setcancelstate()
must be used to disable cancellation for the duration of any
calls that the signal handler makes which are cancellation
points. However, earlier versions of the standard did not permit
strictly conforming applications to call pthread_setcancelstate()
from a signal handler since it was not required to be
async-signal-safe. On non-conforming implementations where
pthread_setcancelstate() is not async-signal-safe, alternatives
are to ensure either that the corresponding signals are blocked
during execution of functions that are not async-cancel-safe
or that cancellation is disabled during times when those signals
could be delivered.
(keep first sentence, change second and third sentences, delete
fourth sentence).
At page 1694 after line 54312 (XSH pthread_setcancelstate()
description) insert a new paragraph:
The pthread_setcancelstate() function shall be async-signal-safe.
After applying the changes in 0000615, at page 1695 line 54349 (XSH
pthread_setcancelstate() future directions), change:
The pthread_setcancelstate() function may be added to the table
of async-signal-safe functions in section 2.4.3 on page 489.
to:
None.
Bug 0000842: meaning of "enclosing loop" with break/continue unclear Accepted as Marked
http://austingroupbugs.net/view.php?id=842
This item is tagged for TC2-2008
At page 2358 lines 75117-75121 (XCU 2.14 break description), change:
The break utility shall exit from the smallest enclosing for,
while, or until loop, if any; or from the nth enclosing loop
if n is specified. The value of n is an unsigned decimal integer
greater than or equal to 1. The default shall be equivalent to
n=1. If n is greater than the number of enclosing loops, the
outermost enclosing loop shall be exited. Execution shall
continue with the command immediately following the loop.
to:
If n is specified, the break utility shall exit from the nth
enclosing for, while, or until loop. If n is unspecified, break
shall behave as if n was specified as 1. Execution shall continue
with the command immediately following the exited loop. The
value of n is a positive decimal integer. If n is greater than
the number of enclosing loops, the outermost enclosing loop
shall be exited. If there is no enclosing loop, the behavior
is unspecified.
A loop shall enclose a break or continue command if the loop
lexically encloses the command. A loop lexically encloses a
break or continue command if the command is:
executing in the same execution environment (see section 2.12) as the compound-list of the loop's do-group (see section 2.10.2), and
contained in a compound-list associated with the loop (either in the compound-list of the loop's do-group or, if the loop is a while or until loop, in the compound-list following the while or until reserved word), and
not in the body of a function whose function definition command (see section 2.9.5) is contained in a compound-list associated with the loop.
If n is greater than the number of lexically enclosing loops
and there is a non-lexically enclosing loop in progress in the
same execution environment as the break or continue command,
it is unspecified whether that loop encloses the command.
After page 2359 line 75155 (XCU 2.14 break examples), insert:
The results of running the following example are unspecified:
There are two loops in progress when the break command is
executed, and they are in the same execution environment, but
neither loop is lexically enclosing the break command. (There
are no loops lexically enclosing the continue commands, either.)
foo() {
for j in 1 2; do
echo 'break 2' >/tmp/do_break
echo " sourcing /tmp/do_break ($j)..."
# the behavior of the break from running the following command
# results in unspecified behavior:
. /tmp/do_break
do_continue() { continue 2; }
echo " running do_continue ($j)..."
# the behavior of the continue in the following function call
# results in unspecified behavior (if execution reaches this
# point):
do_continue
trap 'continue 2' USR1
echo " sending SIGUSR1 to self ($j)..."
# the behavior of the continue in the trap invoked from the
# following signal results in unspecified behavior (if
# execution reaches this point):
kill -USR1 $$
sleep 1
done
}
for i in 1 2; do
echo "running foo ($i)..."
foo
done
At page 2362 lines 75244-75250 (XCU 2.14 continue description), change:
The continue utility shall return to the top of the smallest
enclosing for, while, or until loop, or to the top of the nth
enclosing loop, if n is specified. This involves repeating the
condition list of a while or until loop or performing the next
assignment of a for loop, and re-executing the loop if appropriate.
The value of n is a decimal integer greater than or equal to
1. The default shall be equivalent to n=1. If n is greater than
the number of enclosing loops, the outermost enclosing loop
shall be used.
to:
If n is specified, the continue utility shall return to the top
of the nth enclosing for, while, or until loop. If n is
unspecified, continue shall behave as if n was specified as 1.
Returning to the top of the loop involves repeating the condition
list of a while or until loop or performing the next assignment
of a for loop, and re-executing the loop if appropriate. The
value of n is a positive decimal integer. If n is greater than
the number of enclosing loops, the outermost enclosing loop
shall be used. If there is no enclosing loop, the behavior is
unspecified.
The meaning of "enclosing" shall be as specified in the description
of the break utility.
Next Steps
----------
The next call is on June 12, 2014 (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:
http://posix-aA9aGynHYqB/thfjNshNs9i2O/***@public.gmane.org:9001/p/201x-mm-dd
password=2115756#
--------
Andrew Josey The Open Group
Austin Group Chair Apex Plaza, Forbury Road
Email: a.josey-7882/***@public.gmane.org Reading,Berks.RG1 1AX,England
Tel:+44 118 9023044 US fax: +1 415 276 3760
Mobile:+44 774 015 5794 UK fax: +44 870 131 0418
Enclosed are the minutes of the 5th June 2014 Teleconference
regards
Andrew
------
Minutes of the 5th June 2014 Teleconference Austin-658 Page 1 of 1
Submitted by Andrew Josey, The Open Group. 6th June 2014
Attendees:
Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR
Geoff Clare, The Open Group
Don Cragun, IEEE PASC OR
Andrew Josey, The Open Group
David Clissold, IBM
Richard Hansen, BBN
Eric Blake, Red Hat
Mark Brown, Canonical
Joerg Schilling
Apologies
Mark Ziegast, SHware Systems
Martin Rehak, Oracle
* General news
Geoff now has write access to the SVN repository and so is continuing the
edits to the current TC2 defects.
We discussed when we might have the cutoff for TC2 defect reporting.
This will be driven by when the IEEE PAR is approved.
Andrew took an action to draft the PAR (based on the previous PAR)
and also to draw up an outline timeline, so we can make a decision
on when to submit.
(The following occurred after the meeting)
Regarding the action below - Andrew reported back by email to the core team
that we could action captions to the tables, but that would probably
be best done for issue 8:
"A query was raised about table labelling in the specification.
Andrew took an action to check with our editor and report back to the group."
* 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 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.
Bug 0000375: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef OPEN
http://austingroupbugs.net/view.php?id=375
This is still left open due to discussions pending on the reflector.
Bug 0000789: Add set -o pipefail OPEN
http://austingroupbugs.net/view.php?id=789
* Current Business
Bug #811: precondition for mutex destruction unclear; example contradicts normative text OPEN
http://www.austingroupbugs.net/view.php?id=811
We have left this item open pending further input from Dave Butenhof on
supplying a new example.
Bug #622: Disallow loophole for asynchronous cancellation of any function Accepted as Marked
http://austingroupbugs.net/view.php?id=622
This item is tagged for TC2-2008
At page 515 line 17840 section 2.9.5.4 Async-Cancel Safety add two paragraphs:
If a thread has asynchronous cancellation enabled and is cancelled
during execution of a function that is not async-cancel-safe,
the behavior is undefined.
If a thread has deferred cancellation enabled, a signal catching
function is called in that thread during execution of a function
that is not async-cancel-safe, and the signal catching function
calls any function that is a cancellation point while a
cancellation is pending for the thread, the behavior is undefined.
Change "None." at page 1694, line 54327 section APPLICATION USAGE in pthread_setcancelstate() to:
In order to write a signal handler for an asynchronous signal
which can run safely in a cancellable thread, pthread_setcancelstate()
must be used to disable cancellation for the duration of any
calls that the signal handler makes which are cancellation
points. However, the standard does not permit strictly conforming
applications to call pthread_setcancelstate() from a signal
handler since it is not currently required to be async-signal-safe.
On implementations where pthread_setcancelstate() is not
async-signal-safe, alternatives are to ensure either that the
corresponding signals are blocked during execution of functions
that are not async-cancel-safe or that cancellation is disabled
during times when those signals could be delivered. Implementations
are strongly encouraged to make pthread_setcancelstate()
async-signal-safe.
Bug 0000841: pthread_setcancelstate should be async-signal-safe Accepted as Marked
http://austingroupbugs.net/view.php?id=841
This item is tagged for Issue 8
This bug was updated (previously it had been Accepted)
At page 489 lines 16722-16755 (XSH 2.4.3) insert:
pthread_setcancelstate()
After applying the changes from 0000615, at page 489 line 16756
(XSH 2.4.3 Signal Actions), change:
Implementations may make other interfaces async-signal-safe.
to:
It is implementation-defined which additional interfaces, if
any, are also async-signal-safe.
After applying the changes from 0000622, at page 515 line 17840
section 2.9.5.4 Async-Cancel Safety, change:
If a thread has deferred cancellation enabled, a signal catching
function is called in that thread during execution of a function
that is not async-cancel-safe, and the signal catching function
calls any function that is a cancellation point while a
cancellation is pending for the thread, the behavior is undefined.
to:
If a thread has deferred cancellation enabled, a signal catching
function is called in that thread during execution of a function
that is not async-cancel-safe, and the signal catching function
calls any function that is a cancellation point while a
cancellation is pending for the thread, without first disabling
cancellation, the behavior is undefined.
After applying the changes from 0000622, at page 1694 line 54327
(pthread_setcancelstate() application usage), change:
In order to write a signal handler for an asynchronous signal
which can run safely in a cancellable thread, pthread_setcancelstate()
must be used to disable cancellation for the duration of any
calls that the signal handler makes which are cancellation
points. However, the standard does not permit strictly conforming
applications to call pthread_setcancelstate() from a signal
handler since it is not currently required to be async-signal-safe.
On implementations where pthread_setcancelstate() is not
async-signal-safe, alternatives are to ensure either that the
corresponding signals are blocked during execution of functions
that are not async-cancel-safe or that cancellation is disabled
during times when those signals could be delivered. Implementations
are strongly encouraged to make pthread_setcancelstate()
async-signal-safe.
to:
In order to write a signal handler for an asynchronous signal
which can run safely in a cancellable thread, pthread_setcancelstate()
must be used to disable cancellation for the duration of any
calls that the signal handler makes which are cancellation
points. However, earlier versions of the standard did not permit
strictly conforming applications to call pthread_setcancelstate()
from a signal handler since it was not required to be
async-signal-safe. On non-conforming implementations where
pthread_setcancelstate() is not async-signal-safe, alternatives
are to ensure either that the corresponding signals are blocked
during execution of functions that are not async-cancel-safe
or that cancellation is disabled during times when those signals
could be delivered.
(keep first sentence, change second and third sentences, delete
fourth sentence).
At page 1694 after line 54312 (XSH pthread_setcancelstate()
description) insert a new paragraph:
The pthread_setcancelstate() function shall be async-signal-safe.
After applying the changes in 0000615, at page 1695 line 54349 (XSH
pthread_setcancelstate() future directions), change:
The pthread_setcancelstate() function may be added to the table
of async-signal-safe functions in section 2.4.3 on page 489.
to:
None.
Bug 0000842: meaning of "enclosing loop" with break/continue unclear Accepted as Marked
http://austingroupbugs.net/view.php?id=842
This item is tagged for TC2-2008
At page 2358 lines 75117-75121 (XCU 2.14 break description), change:
The break utility shall exit from the smallest enclosing for,
while, or until loop, if any; or from the nth enclosing loop
if n is specified. The value of n is an unsigned decimal integer
greater than or equal to 1. The default shall be equivalent to
n=1. If n is greater than the number of enclosing loops, the
outermost enclosing loop shall be exited. Execution shall
continue with the command immediately following the loop.
to:
If n is specified, the break utility shall exit from the nth
enclosing for, while, or until loop. If n is unspecified, break
shall behave as if n was specified as 1. Execution shall continue
with the command immediately following the exited loop. The
value of n is a positive decimal integer. If n is greater than
the number of enclosing loops, the outermost enclosing loop
shall be exited. If there is no enclosing loop, the behavior
is unspecified.
A loop shall enclose a break or continue command if the loop
lexically encloses the command. A loop lexically encloses a
break or continue command if the command is:
executing in the same execution environment (see section 2.12) as the compound-list of the loop's do-group (see section 2.10.2), and
contained in a compound-list associated with the loop (either in the compound-list of the loop's do-group or, if the loop is a while or until loop, in the compound-list following the while or until reserved word), and
not in the body of a function whose function definition command (see section 2.9.5) is contained in a compound-list associated with the loop.
If n is greater than the number of lexically enclosing loops
and there is a non-lexically enclosing loop in progress in the
same execution environment as the break or continue command,
it is unspecified whether that loop encloses the command.
After page 2359 line 75155 (XCU 2.14 break examples), insert:
The results of running the following example are unspecified:
There are two loops in progress when the break command is
executed, and they are in the same execution environment, but
neither loop is lexically enclosing the break command. (There
are no loops lexically enclosing the continue commands, either.)
foo() {
for j in 1 2; do
echo 'break 2' >/tmp/do_break
echo " sourcing /tmp/do_break ($j)..."
# the behavior of the break from running the following command
# results in unspecified behavior:
. /tmp/do_break
do_continue() { continue 2; }
echo " running do_continue ($j)..."
# the behavior of the continue in the following function call
# results in unspecified behavior (if execution reaches this
# point):
do_continue
trap 'continue 2' USR1
echo " sending SIGUSR1 to self ($j)..."
# the behavior of the continue in the trap invoked from the
# following signal results in unspecified behavior (if
# execution reaches this point):
kill -USR1 $$
sleep 1
done
}
for i in 1 2; do
echo "running foo ($i)..."
foo
done
At page 2362 lines 75244-75250 (XCU 2.14 continue description), change:
The continue utility shall return to the top of the smallest
enclosing for, while, or until loop, or to the top of the nth
enclosing loop, if n is specified. This involves repeating the
condition list of a while or until loop or performing the next
assignment of a for loop, and re-executing the loop if appropriate.
The value of n is a decimal integer greater than or equal to
1. The default shall be equivalent to n=1. If n is greater than
the number of enclosing loops, the outermost enclosing loop
shall be used.
to:
If n is specified, the continue utility shall return to the top
of the nth enclosing for, while, or until loop. If n is
unspecified, continue shall behave as if n was specified as 1.
Returning to the top of the loop involves repeating the condition
list of a while or until loop or performing the next assignment
of a for loop, and re-executing the loop if appropriate. The
value of n is a positive decimal integer. If n is greater than
the number of enclosing loops, the outermost enclosing loop
shall be used. If there is no enclosing loop, the behavior is
unspecified.
The meaning of "enclosing" shall be as specified in the description
of the break utility.
Next Steps
----------
The next call is on June 12, 2014 (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:
http://posix-aA9aGynHYqB/thfjNshNs9i2O/***@public.gmane.org:9001/p/201x-mm-dd
password=2115756#
--------
Andrew Josey The Open Group
Austin Group Chair Apex Plaza, Forbury Road
Email: a.josey-7882/***@public.gmane.org Reading,Berks.RG1 1AX,England
Tel:+44 118 9023044 US fax: +1 415 276 3760
Mobile:+44 774 015 5794 UK fax: +44 870 131 0418