Austin Group Minutes of the 9 February Teleconference Austin-276 Page 1 of 1
Submitted by Andrew Josey, The Open Group.              February 10, 2006

Attendees
Andrew Josey, The Open Group
Don Cragun , Sun, PASC OR
Nick Stoughton, USENIX, ISO/IEC OR
Jerry Heyman, IBM
Mark Brown, IBM, TOG OR 
Doug Locke
Mats Wichmann, Intel
Ulrich Drepper, Red Hat


Next Meeting preparation:

At the moment we expect between 10 to 12 attendees.

Sometime was spent reviewing and discussing the meeting
agenda. A number of updates were made to it
see http://www.opengroup.org/austin/agenda.html

Action item review 
---------------------
Just the updates on Austin/240r1 are noted here.

ACTION AI-2005-01-09 Andrew Josey & Mats Wichmann to propose a time and place
for a joint Austin group/LSB Workgroup meeting to consider LSB/POSIX
conflicts, to be held as soon as conveniently possible.
Status: Closing, the Feb 2006 Ottawa is the time and place
This has now been scheduled for the Wednesday morning of the meeting

ACTION:Nick has an action to prepare an agenda for a teleconference.
Status: Closing:This will be at the Ottawa meeting.
ACTION Andrew: Final TR typeset and will be sent to Sally Seitz.
Status: Closed. 


Proposed Input to the Revision
---------------------------------
The Open Group has a company review in progress and others to follow
soon. Austin Group members are invited to participate in the review.
They can do so at http://www.opengroup.org/platform/doc-review/ You
need to use your Open Group web id and password to get a copy of the
draft. Further  API sets are there, note that API set 3 has a slight
delay and will be pushed back at least 1 week.


Defect Report Processing
-------------------------
The group picked up on the latest batch of defect
reports, which are available at the following URL:
http://www.opengroup.org/austin/aardvark/latest/

XCU ERN 83 (previously closed)

Dave Korn had raised the following concern on the reflector:

> 1.  Add at end of P910, L35297 (not shaded):
>         "On systems not supporting the X/Open System Interfaces
>         Extension, the results are unspecified if $1 is '(' and
>         $3 is ')'."

This could cause currently strictly conforming scripts to fail
on systems with the XSI extension.  This means that XSI is not
an extension but a change to the standard.  In the 1992 standard,
the meaning of
        test "1" = "$3"
is unambigously defined no matter what $1 and $2 are.

If $1 is ( and $2 is ), then the result is false.

Similarly,
        test '(" !=  ")"
must be true.

Response:
It was felt that the previous wording in the standard was ambiguous
and now by this change we are restricting the choices available to
applications in this area. Perhaps Dave could elaborate more on the issue
and what a recommended course should be.

XCU ERN 82 printf OPEN

Leave open until the next meeting

XSH ERN 122  pselect OPEN

Leave open until the next meeting. We would like input from Dave B on
this item Action: Andrew to request input from Dave Butenhof

XCU ERN 84 Accept as marked below

 Reword the cited paragraph to be:                                                                                
     "The search for the matching backquote shall be
      satisfied by the first unquoted non-escaped backquote".

XCU ERN 85 Accept as marked below

Handle as an interpretation request (not a defect).
The standards states the requirements, and conforming implementations must
conform to this. However, concerns have been raised about this
which are being referred to the sponsor.
The suggested changes to be put forward as proposed text for
a future revision.


XSH ERN 124 OPEN

We need to look for guidance from the SSWG or Dave B

XSH ERN 125 system() thread-safety Accept as marked below
                                                                                
 In System Interfaces, p50 section 2.9.1, line 2089, add "system()" to the
 list of functions that need not be thread-safe (in alpha order).
                                                                                
 In System Interfaces, Chapter 3, p1500 after line 45670, add "This function
 need not be reentrant.  A function that is not required to be reentrant
 is not required to be thread-safe."
                                  


Next Steps
-----------
Andrew  will update the aardvark reports with the latest inbound
defect reports.

The next call will be during the face to face meeting in Ottawa
irc://irc.freestandards.org/austin