Austin Group Minutes of the 31 March Teleconference Austin-252 Page 1 of 1
Submitted by Andrew Josey, The Open Group.              April 1, 2005

Attendees

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


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: OPEN

Andrew has updated the report for 2.9-xxx and will update it again
shortly for the 3.0 preview1. The plan for LSB 3.0 is for a 15 day 
review on 3.0 preview1 and if there are no major bugs then
there will be a 30 day review on rc1.

Nick still has an action to prepare an agenda for a teleconference.


ACTION AI-2005-01-06: AJ to contact Jack McCann at HP for views on
getnameinfo document, and for any other networking issues that may
concern us. 
Status: OPEN, looking for a volunteer to acts as a liaison to
the networking folks at IETF


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/


XSH ERN 87 sem_open ENOMEM and ENOSPC errors Accept

This should be sent down the interpretations track with the
interpretation that the standard is silent on the issue of running out
of memory, hence no distinctions can be made between conforming
implementations. Concerns are being forwarded to the sponsor.

XSH ERN 88 rename  Reject

All existing implementations of rename() behave as specified.

"If the old argument and the new argument resolve to the same existing
file, rename() shall return successfully and perform no other action."

So there would be breakage to existing  applications and
implementations to change rename() as requested.


XBD ERN 52 fma ISO C TC2 #47 Accept

XBD ERN 53 OPEN

Action on Mark to come up with a proposal

XBD ERN 54 

Action on Nick to send out a mail with a proposal.
Action completed and included below:

---start email
Following today's teleconference, we agreed that the correct approach is
first to warn everybody that this change is coming, and then to remove
it at the next revision after the warning has been out there.

It is my contention (though not held by everyone on the call) that there
are so few applications that conform strictly to POSIX but have no
intention or plan to port to Linux (where EOPNOTSUPP is the same value
as ENOTSUP), and those that do fall in this category would only in
exceptional cases use "switch" on errno with these two values as
distinct cases, that the proposed change would cause no problems.

If such apps exist, they probably wouldn't want to port to anything
other than their current hardware/os choice anyway ... and therefore
would need no change in the light of the proposed change.

I therefore propose a three-pronged attack! 
1. Put this down the interps track. "The standard is clear, and
conforming implementations must provide these symbols with distinct
values. Concerns have been raised and sent to the sponsor."

2. In the next TC (if we ever do one) On p 221, line 7777, change
[ENOTSUP] Not supported.

to

[ENOTSUP] Not supported (in a future revision, this may be the same
value as [EOPNOTSUPP]).

and at line 7780, change

[EOPNOTSUPP] Operation not supported on socket.

to

[EOPNOTSUPP] Operation not supported on socket (in a future revision
may be the same value as [ENOTSUP]).

3. In the next revision (SUSv4), make the change as specified.
---end email

-----------

Andrew  will update the aardvark reports with the latest inbound
defect reports.

The next call is  April 14 2005
We will also try to have an IRC channel open, irc.freestandards.org
#austin (thanks to Mat for volunteering )