Austin/281
Minutes of the 10th Plenary Meeting of the Austin Group
21-24 February 2006, Standards Council of Canada, Ottawa, ON.
Austin/281
Minutes of the 10th Plenary Meeting of the Austin Group
21-24 February 2006, Standards Council of Canada, Ottawa, ON.
Attendees
| Name | Affiliation | Role |
| Andrew Josey | The Open Group | Chair |
| Nick Stoughton | Usenix | SC 22 OR, Secretary |
| Don Cragun | Sun Microsystems | IEEE OR |
| Doug Locke | Locke Consulting/US Navy (1 day) | |
| Larry Dwyer | HP (teleconference, full) | The Open Group alternate |
| Mark Brown | IBM (3 days) | The Open Group OR |
| Peter Van der Veen | QNX (part) | |
| Glen Seeds | Cognos | |
| Joanna Farley | Citrix (teleconference) | |
| Dave Anglin | National Research Council of Canada (2 days) | |
| Ulrich Drepper | Red Hat | |
| Steve Michell | Maurya Software(part) | |
| Keld Simonsen | DKUUG/Standards Norway (teleconference, part) | SC 22 Alternate |
| Mats Wichmann | Intel/LSB Workgroup (teleconference, part) | |
| Spencer Cheng | Self (part) |
Andrew Josey called the tenth meeting (a.k.a. Austin/M11, since this counting includes a teleconference) of the Austin Group to order at 9:07 am Tuesday, February 20th at The Standards Council of Canada, Ottawa, ON.
Meeting Goals
The goal of this meeting is to
All the participants introduced themselves.
The agenda was approved as published, with the addition of a discussion on approved interpretations/interpretations status (under item 5, Status Reports).
Minutes of the last plenary meeting ( Austin/239, January 11-13, 2005) were reviewed. Approved with no objections.
SD2 No updates.
SD1 - no updates.
Stephen Michell discussed the difficulties that Canada has had holding together a group of experts to review documents, since in his view the ISO part of the process is broken. However, the published ISO process has been followed, and we do use the full 5 stage ballot process etc. There is currently no good way to enforce national body participation in the development of any standard, beyond the requirement for 5 NBs to agree to the initiation of a new project. It was felt that better communication of the Austin Group work to SC 22 national bodies would help. ACTION NS/AJ to make quarterly reports into SC22 numbered documents. The project editor plans to attend the SC22 plenary meeting this fall in London.
No updates.
See attendance list above. Nick Stoughton is no longer the "interim" OR from SC22 - SC22 resolution 05-10 in N3989 made this appointment firm, with Keld Simonsen as alternate.
Committee Draft development procedures. There had been a deadline of Jan 9 for notification of new material for the revision. At that time, only The Open Group had responded with 4 documents containing new APIs. The group decided to extend this deadline until March 31. ACTION AJ to publicize the extension to the proposal submission deadline to March 31. The final text must still be submiited (as an approved document) to the AG by July 31.
Organizational Reps Status - No issues.
A new set of objectives and scope were discussed and a new document is being developed to contain these. One starting point was the slides in pages 36 and 37 of Austin/277.
The Open Group is bringing in four additional API sets for the new revision; these originate from Solaris and GNU glibc, and have existing implementation and application usage. During discussion, a few additional proposals appear to be in preparation.
In dealing with the"backward compatibility" requirement, Larry Dwyer has concerns about forward compatibility in ABI for implementors. The proposed words currently suggest that for implementations it should be possible for an implementation to simultaneously support both the old and new standard, and the HP additional request was to be able to do this without requiring two ABIs. For applications, an app that strictly conforms to the old specification should still conform to the new, though it may no longer be strictly conforming (e.g. it may now use interfaces that have become obsolete).
During the previous plenary meeting, we categorized the differences as follows:
The EOPNOTSUPP v ENOTSUP is on the interps list already.
An aardvark on the fcntl O_LARGEFILE question has been filed.
An aardvark on the *scanf extension has been filed (use %Ms rather than %as to avoid ISO C conflict).
The getopt issue is now acceptable POSIX behavior.
For kill, this will continue to be a problem. Various implementors would not accept a change that permitted both behaviors.
For link, there has been much discussion on the email list about this. One suggestion there was to add a new function posix_link(). In strawman2, there is a linkat() function, which could take a flag argument. This might be a better place to solve this issue. Several things need to happen here:
The regexec diff is no longer relevant.
For strerror_r() there is a fully POSIX conforming available. The ABI actually uses __xpg_strerror_r for this case. The basename() function has similar issues. ACTION NS to file bugs on strerror_r and basename problems.
For strptime, the interpretation has been filed and decided.
It is not possible to resolve the unlink issue at this time. However, Rationale should be added to the unlink page in POSIX to describe the differences.
The waitpid differences are no longer true. ACTION NS to file a bug on waitpid to remove the current differences.
The waitid function is now implemented in Linux, and can be added to the LSB as a POSIX conforming interface.,
ACTION NS to file a bug requesting the waitid function be added to LSB.
Commands And Utilities
What is happening with tar v cpio v pax? Nothing ... only pax is specified in POSIX.
Special built-ins. Mark Brown offered to develop open source exec-able versions of these built-ins and submit them to the upstream maintainers.
The ar utility is deprecated in LSB (it is believed to be a "development" tool). There are other differences in the LSB. The best option here is to ask the LSB to drop the ar utility in a future release (since it is marked as deprecated).
The at utility ... a patch was developed to handle the options (-d/-r and -t), bu tno maintainer found. An aardvark has been filed to handle the XSI specific directory where at/batch.allow/deny to make this implementation defined instead of /usr/lib/cron. Also affects crontab. ACTION: Andrew Josey to submit an aardvark against at, batch and crontab to make the directory used for the allow and deny files implementation defined.
On awk, sed, grep and internationlized REs, Ulrich believes that this difference no longer (if ever) exists. The LSB workhroup is encouraged to remove this difference and align with POSIX here. ACTION Nick Stoughton to file a bug in LSB bugzilla to remove the internationalized REs difference.
It looks like bc uses the POSIXLY_CORRECT environment as well as the --standard option to provide standard behavior. ACTION NS to file bug on bc and the use of POSIXLY_CORRECT.
For chown, and chgrp, these differences are no longer true. ACTION NS to file bug on chown and chgrp differences. CLOSED: Actually this is a bug in the TR.
The cut utility is similar ... the utility now supports the -n option. ACTION NS to file a bug on the cut utility differences.
The df utility appears to support the POSIXLY_CORRECT environment variable to support POSIX behavior. ACTION NS to file bug to re-evaluate the differences in df. (-t is still different) The issue with df on a special file has been handled in XCU ERN 59, which should go down the interps track.
The du utility appears to use POSIXLY_CORRECT correctly. ACTION NS to file a bug on the du differences.
The echo utility. Neither POSIX nor the LSB is going to change in this area. POSIX already contains almost identical warnings about the use of -n and escape sequences, and the strong encouragement to use printf.
In Linux implementations, the file utility does now support -h and -i. The -M and -d are still unimplemented
The find utility now conforms. ACTION NMS to file bug on find differences
The fuser utility - at very least needs an aardvark to clarify the current POSIX wording. The differences described exist, and also fuser on Linux appears not to handle the no option at all case where the operand names a block special file. ACTION Mark Brown to file an aardvark to clarify the wording (change and add examples) to the fuser utility. ACTION NS to file bug noting the additional differences in fuser.
The grep utility problem no longer exists.
The ipcrm differences are actually permitted extensions of the POSIX behavior. No change required for either specification.
No recommendations be made for portable use of the ipcs utility at this point.
No recommendations be made for portable use of the more utility at this point.
The Linux implementation of the newgrp utility could be patched to support POSIX behavior. Mark Brown offered to examine CVS and understand the current implementation, and to provide further information. ACTION NS to submit bug on newgrp (wrong synopsis and -l is now supported).
The od utility is being brought into POSIX alignment by its maintainer. No changes required at this time (a future LSB will remove this from the differences list).
No recommendations be made for portable use of the more utility at this point. Mark Brown offered to investigate the feasibility of developing a patch to implement POSIXLY_CORRECT behavior.
The xargs utility is already resolved (as documented in the LSB Future Directions).
Started with a pass through the doc to sort out which aardvarks need to go into SD-5, and which should be interps.
XBD ERN 1 SD5 XBD ERN 2 Reject XBD ERN 3 Interps XBD ERN 4 SD5 XBD ERN 5 SD5 XBD ERN 6 SD5 XBD ERN 7 Interps XBD ERN 8 Reject XBD ERN 9 Interps XBD ERN 10 SD5 XBD ERN 11 Interps XBD ERN 12 Interps XBD ERN 13 SD5 XBD ERN 14 SD5 XBD ERN 15 SD5 XBD ERN 16 Interps XBD ERN 17 SD5 XBD ERN 18 No action required XBD ERN 19 Interps XBD ERN 20 Withdrawn XBD ERN 21 SD5 XBD ERN 22 SD5 XBD ERN 23 Interps XBD ERN 24 NCR XBD ERN 25 OPEN XBD ERN 26 OPEN XBD ERN 27 OPEN XBD ERN 28 SD5 XBD ERN 29 OPEN XBD ERN 30 OPEN XBD ERN 31 OPEN XBD ERN 32 Interps XBD ERN 33 SD5 XBD ERN 34 OPEN XBD ERN 35 SD5 XBD ERN 36 SD5 XBD ERN 37 Interps XBD ERN 38 SD5 XBD ERN 39 SD5 XBD ERN 40 Interps XBD ERN 41 SD5 XBD ERN 42 SD5 XBD ERN 43 SD5 XBD ERN 44 SD5 XBD ERN 45 OPEN XBD ERN 46 OPEN XBD ERN 47 OPEN XBD ERN 48 SD5 XBD ERN 49 SD5 XBD ERN 50 SD5 XBD ERN 51 SD5 XBD ERN 52 SD5 XBD ERN 53 OPEN XBD ERN 54 Interps XBD ERN 55 SD5 XBD ERN 56 SD5 XBD ERN 57 SD5 XBD ERN 58 SD5 XBD ERN 59 OPEN XBD ERN 60 SD5 XBD ERN 61 SD5 XBD ERN 62 SD5 XBD ERN 63 OPEN
SD/5 Review
Now take a pass through SD5 to see if there are unresolved items that we can address.
SD5 XSH ERN 113: mark as obsolete. Add sighold and sigrelese to the App Usage (replaced by sigprocmask and
pthread_sigmask).
SD5 XBD ERN 4: several changes ... an Editor's Notes document describing detailed changes is being developed. This will be published as Austin/279. {OPEN_MAX} is a hard limit, while {FOPEN_MAX} is a soft limit. Therefore the language around {FOPEN_MAX} does not require similar changes, though there does need to be coalescing of FOPEN_MAX and STREAM_MAX wording.
SD5 XSH ERN 30: see editor's notes.
SD5 XCU ERN 25: We are unaware of a normatively referencable document that describes the format, and we are unwilling/unable to describe the format within POSIX. We do not know of any unrestricted source from which we can develop a specification of the format that would match existing practice.
SD5 XSH ERN 39: Various emails relevant to this topic, particularly 7017. Dave Butehof had an action on this that does not appear to have been completed. Suggested action: use first paragraph of alternative b, with modifications (see Ed Note document).
SD5 XSH ERN 42: We have already decided to mark these functions as obsolescent (see SD5 XSH ERN 113).
SD5 XSH ERN 46: We need the full text for the proposed new function (tremove); if the original submitter can provide such material, we could consider it. However, some feel that all these tree traversal functions could be marked as obsolete; but we do not have alternatives in the standard. ACTION: AJ to contact Louis Strous (louis@yahoo.com) to request full text for tremove and any other related changes required.
SD5 XCU ERN 46: The uucp interfaces could be marked as obsolescent in the revision. There are alternatives, but not in the standard. Propose to make the uucp utilities optional.
XBD ERN __ - discussion
ACTION - Andrew Josey to create interpretation requests as necessary for thise items marked as interps track.
XBD aardvark
Following the sorting of XBD aardvark earlier (see above), we have the following open XBD aardvarks:
XBD ERN 25: Accept as Marked: This refers to XBD page 100, line 3131-3132. Add "The pthread_mutex_lock() function need not
synchronize memory if the mutex type is PTHREAD_MUTEX_RECURSIVE and the calling thread already owns the mutex.
The pthread_mutex_unlock() function need not synchronize memory if the mutex type is PTHREAD_MUTEX_RECURSIVE
and the mutex has a lock count greater than 1."
Also, for each function in lines 3122-3130, add a "See Also" to XBD setion 4.10.
We do not believe any action is required for read-write locks.
XBD ERN 26: Reject: The group struggled to understand the problem statement. The standard is written in C terms, and expressing problems in C++ does not help the group to understand the issue. 4.10 states (in relevant part) "Such access is restricted using functions that synchronize thread execution and also synchronize memory with respect to other threads." The aardvark is confusing the two aspects of "synchronization" to try to stress a misinterpretation.
The application is responsible for ensuring that two threads cannot access the same "memory location" at the same time. However, there are many ways to accomplish this without explicit "thread execution" synchronization (e.g., mutexes, semaphores, etc.) It is in fact sufficient to ensure that only one thread can call a function that modifies some memory location. This satisfies the application requirement quoted.
What it doesn't ensure is that any other thread will be able to read the modified value, because we don't (and by intent) require any form of implicit memory synchronization. The specification, however, makes it clear that calling any of the listed functions provides memory synchronization.
Therefore, the standard currently provides for pthread_cond_signal and pthread_cond_broadcast to be used essentially as memory barriers. The group is actually not particularly happy with the implications of this; but that's what the standard says all the same.
The issue here isn't whether the aardvark is "theoretically correct", but whether the change proposed is justifiable ("safe and of sufficient value") at this point in the life of the standard. Previous attempts at this revision have been rejected because the working group felt the risk of breaking existing applications depending on this inadvertent "memory barrier" behavior was too great to justify the benefit of slightly simpler or more efficient implementation code. The group does not see how that has changed.
XBD ERN 27: Reject: The working group does not believe that the suggested replacement is justified or helps clarify the intent.
XBD ERN 29: Ulrich believes that this might well break implementations. Dave Butenhof in 7642 states that this might be acceptable. However, since there are no atomic operations and hence memory barriers necessary to implement this function, it could cause problems for existing implementations. The proposed change would break currently conforming implementations. Reject
XBD ERN 30: Accept as Marked. Rationale in 7631 seems appropriate. Add semop and semctl to the list of sync functions.
XBD ERN 31: Reject: the problem statement does not describe the problem, and so does not permit the group to evaluate the suggested action. Submitters of aardvark defect reports should refer to http://www.opengroup.org/austin/aardvark/format.html
XBD ERN 34: Reject. If an application misuses locks, the standard cannot prevent data corruption, and should not be expected to do so.
XBD ERN 45: pending ISO C
XBD ERN 63: Accept.
XSH aardvark
XSH ERN 93: Accept as marked: see linkat discussion above.
XSH ERN 95: remains open pending WG14 action, no change required.
XSH ERN 122: Accept as marked. Editor has text (in xshbug2.txt). Also includes similar text for sigsuspend. ACTION Ulrich to provide example code for keeping signal cleanup handlers in a defined state for use in pselect and sigsuspend.
XSH ERN 124: Interp. "Is this interpretation correct?" - No! Answers to detailed questions are Yes, Undefined, Does not apply.
XSH ERN 126: Accept as marked. The behavior is unspecified ... not undefined. Interps track.
XSH ERN 127: Accept as marked. Rewrite the "Note" for getnameinfo, at least partly as normative text. Also remove the "under all circumstances" in both places it is used. ACTION Andrew Josey to request feedback on proposed new words for XSH ERN 127 from network experts.
XSH ERN 128: Accept as marked. It is not necessary to discuss tmpfile actions here.
XCU aardvark
XCU ERN 1: ACTION Mark Brown to propose new words for XCU ERN 1. Interps track.
XCU ERN 22: The intent is to keep the recognition of fp numbers in XCU6 the same as it was in XCU5, i.e. following c89 rather than c99. This is possible fix 2.
POSIX Certification Status Report
Joint IEEE/Open Group effort to certify POSIX implementations. Andrew presented a status report on certification (Austin/278).
Work Plan Update
Need to get the PAR out in 6-2006 for approval by PASC-SEC, so it get to SAB in September-06. ACTION DWC to contact Lowell to check electronic procedures etc for this. ACTION AJ to contact IEEE staff to advise them of our plans for the revision. The next teleconference is March 9 at the regular timeslot. We do not expect the next face to face meeting until February 2007, handling ballot resolution from Draft 2, but will review this periodically.
We developed a draft schedule, with 5 or 6 drafts, concluding late in 2007 if all goes according to plan. This is available as Austin/280.
The meeting adjourned at 12:05, Friday February 24.