Minutes of the 26 May 2011 Teleconference     Austin-523 Page 1 of 1
Submitted by Andrew Josey, The Open Group.    May 28 , 2011

Attendees
Andrew Josey, The Open Group
Don Cragun,  PASC OR
Jim Pugsley, Oracle
Geoff Clare, The Open Group
Mark Brown, IBM, TOG OR 
Eric Blake, Red Hat
Nick Stoughton, USENIX, ISO/IEC OR

* Old Business

Eric had completed his action from the previous meeting related
to the shell case statement (the ;& fall through) and
submitted bug 449.

* New Business

We picked up on Bug processing for bugs reported against project
Issue 7.


Bug 0000394: longjmp clarification Accepted
http://austingroupbugs.net/view.php?id=394

This item is tagged for TC1-2008. An interpretation is required.

Interpretation response

The standard states that implementations must perform as stated
even though no known implementation is able to do so, and conforming
implementations must conform to this. However, concerns have been
raised about this which are being referred to the sponsor.

Rationale:
The latest C1x draft has adopted wording equivalent to the proposed
change.

The changes suggested document existing practice and are, therefore,
suitable for a TC.

Notes to the Editor (not part of this interpretation):
Make the changes listed in the Desired Action. 


Bug 0000395: getc_unlocked editorial improvements Accept as Marked
http://austingroupbugs.net/view.php?id=395

This item is tagged for TC1-2008.

This is the new resolved set of actions:

After line 33321 [XSH getc_unlocked DESCRIPTION], add a new paragraph:
"If getc_unlocked or putc_unlocked are implemented as macros they
may evaluate stream more than once, so the stream argument should
never be an expression with side-effects."

At line 33331 [XSH getc_unlocked APPLICATION USAGE], change
"putc_unlocked(*f++)" to "putc_unlocked(c,*f++)".

At line 33375 [XSH getc_unlocked SEE ALSO], add a reference to flockfile().

Bug 0000396: fmemopen vs. 'b' mode flag  Accepted
http://austingroupbugs.net/view.php?id=396

This item is tagged for TC1-2008. An interpretation is required.

Interpretation response:
The standard states that the character 'b' shall have no effect, and
conforming implementations must conform to this. However, concerns have
been raised about this which are being referred to the sponsor.

Rationale:
Existing practice at the time of final acceptance of POSIX.1:2008 had
expanded to include use of the letter 'b' as the second
character in mode. This provides "binary" mode: writes don't
implicitly add a terminating null byte, and fseek(3) SEEK_END is
relative to the end of the buffer (i.e., the value specified by
the size argument), rather than the current string length.

Notes to the Editor (not part of this interpretation):
See Desired Action. 

Action: Eric to create a enhancement request for Issue 8 to
consider standardizing existing practice in this area.


Bug 0000398: mandatory ERANGE failures on insufficient buffer size  Accepted
http://austingroupbugs.net/view.php?id=398

This item is tagged for Issue 8. An interpretation is required.

Interpretation response:
The standard is unclear on this issue, and no conformance distinction
can be made between alternative implementations based on this. This
is being referred to the sponsor.

Rationale:
Without requiring these conditions to fail, it is extremely difficult
for applications to determine what to do.

Notes to the Editor (not part of this interpretation):
Make the changes suggested in the Desired Action. 

Bug 0000414: "val" should scan directories like other SCCS commands rejected
http://austingroupbugs.net/view.php?id=414

While this behavior is available in some implementations, it is not
common existing practice across all implementations. Since the
standard accurately documents what is common, and current wording
does not reject the proposed behavior as a valid extension, the
consensus was to reject this request.


Next Steps
----------
The next call will be on June 2nd at 08:00 Pacific and
will continue processing defect reports.
This call will be for the regular 90 minutes.

http://austingroupbugs.net

See the calendar for the list of dialup numbers.

An IRC  channel will be available for the meeting
 irc://irc.freestandards.org #austin

ICAL: http://www.google.com/calendar/ical/nvctqtstkuni3fab9k3jqtrt4g@group.calendar.google.com/public/basic
XML: http://www.google.com/calendar/feeds/nvctqtstkuni3fab9k3jqtrt4g@group.calendar.google.com/public/basic