Minutes of the 23 January 2014 Teleconference     Austin-641 Page 1 of 1
Submitted by Andrew Josey, The Open Group.  24  January 2014

Attendees:
    David Clissold, IBM
    Don Cragun IEEE PASC OR
    Andrew Josey, The Open Group
    Eric Blake, Red Hat
    Martin Rehak, Oracle, The Open Group OR
    Geoff Clare, The Open Group
    Jörg Schilling Fraunhofer FOKUS
    Richard Hansen, BBN
    Nick Stoughton, USENIX
    Mark Ziegast, Shware Systems
Apologies
    David A. Wheeler, IDA
    Mark Brown, Canonical

* General news

Martin Rehak from Oracle will be acting as The Open Group Organizational Rep.

Work on preparing a TC2-2008 draft is still in progress.  Andrew
will raise a query with the IEEE support staff whether the changes
have to be against the 2008 edition (as well as the 2013 edition).

We noted that when we circulate the TC for the IEEE ballot we should
also circulate the base standard so as to avoid the delay we
encountered with TC1.

A question was raised as to where the most recent TC1 can be obtained
from. The URL is
https://www2.opengroup.org/ogsys/catalog/U130

* 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

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
    
We agreed to leave this item open pending input from David Korn.


Bug 0000794: Add a function series for formatted error messages  OPEN
http://austingroupbugs.net/view.php?id=794

It was agreed that The Open Group OR will forward this to The Open
Group Base Working group to see if they would be willing to sponsor
this proposal for new interfaces.


Bug #0000796:  Editorial adjustments for the ’C’ and ’POSIX’ locale     Accepted as Marked   
http://austingroupbugs.net/view.php?id=796

This item is tagged for TC2-2008


XBD 7.2 POSIX Locale
  On page 136, line 3882, after:
    Conforming systems shall provide a POSIX locale, also known as the C locale.

  add:
    In POSIX.1 the requirements for the POSIX locale are more
    extensive than the requirements for the C locale as specified
    in the C standard. However, in a conforming POSIX implementation,
    the POSIX locale and the C locale are identical.

XSH 3., getdate()
  On page 1012, line 34234, change:
    is Mon Sep 22 12:19:47 EDT 1986 and the LC_TIME category is set to the default C locale:

  to:
    is Mon Sep 22 12:19:47 EDT 1986 and the LC_TIME category is set
    to the default C or POSIX locale:

XCU 4., tr
  On page 3277, line 110021, change:
    the top bit set) would have no effect because, in the C locale,
    bytes with the values octal 200 to

  to:
    the top bit set) would have no effect because, in the C or POSIX
    locale, bytes with the values octal 200 to

XRAT A.7.2 POSIX Locale
On page 3486, lines 117642-117644, change:
    The POSIX locale is equal to the C locale.

  to:
    On POSIX.1 implementations the POSIX locale is equal to the C
    locale, even though the requirements for the POSIX locale are
    more extensive than the C standard's requirements for the C
    locale.

XRAT A.8.2 Internationalization Variables
  On page 3497, line 118151, change:
    If this were omitted, the ISO C standard specifies that the C locale would be used.

  to:
    If this were omitted, the ISO C standard specifies that the C
    (or POSIX) locale would be used.

XSH 3., strftime()
  On page 2027, line 64791, change:
    In the C locale, the E and O modifiers are ignored and the
    replacement strings for the following

  to:
    In the C [CX]or POSIX[/CX] locale, the E and O modifiers are
    ignored and the replacement strings for the following

XSH 3., strtod()
  On page 2051, line 65544, change:
    In other than the C [CX]or POSIX[/CX] locale[CX]s[/CX], other
    implementation-defined subject sequences may be

  to:
    In other than the C [CX]or POSIX[/CX] locale, additional
    locale-specific subject sequence forms may be

XSH strtol()
  On page 2059, line 65838, change:
    In other than the C [CX]or POSIX[/CX] locale[CX]s[/CX], other
    implementation-defined subject sequences may be

  to:
    In other than the C [CX]or POSIX[/CX] locale, additional
    locale-specific subject sequence forms may be

XSH strtoul()
  On page 2065, line 65950, change:
    In other than the C [CX]or POSIX[/CX] locale[CX]s[/CX], other
    implementation-defined subject sequences may be

  to:
    In other than the C [CX]or POSIX[/CX] locale, additional
    locale-specific subject sequence forms may be

XSH wcstod()
  On page 2246, line 71199, change:
    In other than the C [CX]or POSIX[/CX] locale[CX]s[/CX], other
    implementation-defined subject sequences may be

  to:
    In other than the C [CX]or POSIX[/CX] locale, additional
    locale-specific subject sequence forms may be

XSH wcstol()
  On page 2253, line 71409, change:
    In other than the C [CX]or POSIX[/CX] locale[CX]s[/CX], other
    implementation-defined subject sequences may be

  to:
    In other than the C [CX]or POSIX[/CX] locale, additional
    locale-specific subject sequence forms may be

XSH wcstoul()
  On page 2260, line 71571, change:
    In other than the C [CX]or POSIX[/CX] locale[CX]s[/CX], other
    implementation-defined subject sequences may be

  to:
    In other than the C [CX]or POSIX[/CX] locale, additional
    locale-specific subject sequence forms may be

Bug #0000800:  Add support for the recursive printf() format %r         OPEN
http://austingroupbugs.net/view.php?id=800

A lot of discussion occurred. Note from the discussion
were recorded as follows:

printf("%r", newfmt, va_list); // same as vprintf(newfmt, va_list)

In $ notation, %r always consumes a pair of consecutive arguments,
with only the format argument listed in the $ notation:

    printf("%1$r %3$d", newfmt, va_list, 7); // "... 7"

Use (or not) of $ modifiers is per-format string (outer string is
not aware of whether inner string used $, nor how many arguments
were used by inner string):
    if va_list1 contains 2 elements "str", 1, then: printf("%r %d",
    "%2$d %1$s", va_list1, 2); // "1 str 2"

It is probably okay to allow reuse a format argument as both the
format arg of a %r and as a %s via $ notation:
    printf("%1$s %1$r %3$d", "string", va_list1, 3); // "string
    string 3"
But not a good idea to allow reuse the va_list arg in any other $
specifier:
    printf("%1$r %2$p", "fmt", va_list1); // undefined behavior if
    sizeof(void*) != sizeof(va_list)

Okay to use %r twice in one format string:
    printf("%r %d %r\n", fmt1, va_list1, 5, fmt2, va_list2); // "fmt1... 5 fmt2..."
But be careful that the same va_list is not fed through two different
parameters; use va_copy so that there is no risk of traversing the
list in one instance affecting what the second instance sees for
the list

How would flags work? If va_list1 contains the int 1, would
printf("%-3r", "%d", va_list1) result in "1 ", as if by "%-3s",
"1"? Probably best to leave %r as not required to support flags,
field width, or precision in the standard (although these can be
added as extensions), perhaps with note that if implementations DO
support any of these fields, it should be a similar effect as if
those fields had appeared to the %s corresponding to the string
output of the %r

Narrow (char*) vs. wide (wchar_t*) arrays: we'd definitely want to
standardize both approaches, with both usable from printf and
wprintf:

%r - format string is char * (as if processed by printf then fed through %s)
%lr or %R format string is a wchar_t * (as if processed by wprintf then fed through %S)

Thus, with va_list1 containing 2 elements "narrow", L"wide", then:
    va_start(va_list1, foo);
    va_copy(va_list2, va_list1);
    va_copy(va_list3, va_list1);
    va_copy(va_list4, va_list1);
    printf("%r %lr", "%s %ls", va_list1, L"%s %ls", va_list2); // "narrow wide narrow wide"
    wprintf(L"%r %lr", "%s %ls", va_list3, L"%s %ls", va_list4); // L"narrow wide narrow wide"
    va_end(va_list1);
    va_end(va_list2);
    va_end(va_list3);
    va_end(va_list4);


The Open Group OR will forward this to The Open Group Base Working
group to see if they would be willing to sponsor this proposal.

Next Steps
----------

The next call is on January 30th, 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@posix.rhansen.org:9001/p/201x-mm-dd
password=2115756#