Austin Group Minutes of the 2 June Teleconference Austin-259 Page 1 of 1 Submitted by Andrew Josey, The Open Group. June 3, 2005 Attendees Andrew Josey, The Open Group Don Cragun , Sun, PASC OR Nick Stoughton, USENIX, ISO/IEC OR Mark Brown, IBM, TOG OR Apologies: Mats Wichmann Ulrich Drepper, Red Hat We also had an IRC channel open for this call irc://irc.freestandards.org/austin 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 LSB 3.0 is still in review, it is now release candidate 3. There are still a number of issues to resolve but expect to close fairly soon. One issue has been the late introduction of a new utility to handle installation of system specific data such as rc scripts, inet services etc. This is likely to be dropped from the requirements for LSB core so as not to put the ISO submission at risk. 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 Nick reported that he might have some possible candidates. 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 89 setpgrp OPEN Andrew has the action (completed) to contact the requestor and request more information on the problem that has been encountered with the current wording. Also ask whether he believes the wording of setsid() needs to be changed. This item remains open pending response from original requestor. XSH ERN 92 SEEK_ namespace A/M Corrected minutes from last week, now reworded as follows: There was concern about extending the namespace. If this feature was standardized it was felt that an alternative could be to use an alternative name beginning the posix_ or POSIX_ prefix. Until it is standardized another name will need to be chosen by the implementation that does not violate the namespace rules. For this reason an interpretation allowing its use in the current standard would state that this was nonconforming. However it was felt that reservation of the SEEK_ namespace should be considered in a future revision. This item should be submitted down the interpretations track. Standard is clear, concerns are being forwarded to the sponsor. Suggested changes as per the original request. XSH ERN 95 perror This is on hold pending a DR against ISO C TC2 , requesting that it be reversed The DR text is Austin/258 XSH ERN 96 limits.h values Accept as marked below For clarification on the requirements of the standard see page 249 lines 8713-8715 Quoting POSIX limits.h: "Runtime Invariant Values (Possibly Indeterminate) A definition of one of the symbolic names in the following list shall be omitted from on specific implementations where the corresponding value is equal to or greater than the stated minimum, but is unspecified. This indetermination might depend on the amount of available memory space on a specific instance of a specific implementation. The actual value supported by a specific instance shall be provided by the sysconf() function. For your case remove CHILD_MAX from the limits.h header, or have sysconf() return the same value as CHILD_MAX. XSH ERN 97 Accept this is editorial XSH ERN 97 Editorial cross reference Accept XCU ERN 60 pax -x Accept as marked below Remove on page 708: 27497 In copy mode, if no -x format is specified, pax shall behave as if -xpax were 27498 specified. On Page 700 27173 Replace "an archive" with "a pax format archive" XCU ERN 62 tail Accept as marked This is an interpretation of the standard. The standard is clear. No change to the standard is required. The standard clearly states the requirements for the tail utility,and conforming implementations must conform to this. Rationale: The standard explicitly defines required behavior, except for tail -0f and tail -0 , which are unspecified. In particular, tail -n 0 and tail -n -f 0 are clearly specified. Implementations that treat tail -n 0 the same as tail -n +0 are not conforming. Next Steps ----------- Andrew will update the aardvark reports with the latest inbound defect reports. The next call is Thursday June 9 2005 irc://irc.freestandards.org/austin ----- Andrew Josey The Open Group Austin Group Chair Thames Tower, 37-45 Station Road, Email: a.josey@opengroup.org Reading,Berks.RG1 1LX,England Tel: +44 118 9508311 ext 2250 Fax: +44 118 9500110