Austin, October 2000 Plenary for D4 Issue Resolution

Glen Seeds is an employee of Cognos Inc. and a long-time participant in POSIX standards at both the IEEE and ISO level.

This was quite a week. Going through comments received on a 3,500-page document in 3 1/2 days is an interesting exercise. We managed to actually do about 90% of it there and will have to finish the rest by email this week.

Here are the highlights of things that may be of interest to this group. (Caveat: "interesting" is a value judgment on my part. To be safe, you should look at the complete aardvarks and minutes — at <http://www.opengroup.org/austin/>.)

SEEKDIR(), ETC.

We have long been concerned that putting these in the standard would prevent people from implementing "interesting" file systems. However, Ulrich Drepper told us it is not an issue — the GNU code supports 12 different types of file systems, including binary trees, and was able to implement these APIs on all of them. Given that, and the fact that there seem to be many applications out there that use them, we decided to keep them in, even though their reliability for fully portable applications is in some doubt. We hope that this closes the issue permanently (after over 10 years!).

LEAP SECONDS

As many of you may be aware, the issue of where and how to handle UTC leap seconds is raging in a number of forums. For POSIX, however, there seems to be an incontrovertible weight of evidence that making the POSIX clock deal directly with leap seconds would break way too many existing applications.

The compromise we arrived at was to specify that a POSIX day is exactly 24*60*60 seconds, but to leave the mechanism by which the system clock deals with UTC unspecified. This recognizes the fact of life that in most real implementations, UTC is not actually used, and the operator periodically corrects the system time manually, according to a wall clock. We also left the seconds field of the time structure able to hold from 0 to 60 seconds inclusive, to allow it to be used for proprietary or future APIs that deal with leap seconds. If you are interested in other related issues, there is a general discussion group on time that you can subscribe to: <pasc-time-study@pasc.org>.

RANGE EXPRESSIONS

We decided not to standardize the "collating sequence" mechanism, and hence now have no need for an API for it. In the POSIX locale, there is no problem. The behavior outside the POSIX locale is unspecified.

C99 RESTRICT

If you have not noticed it by now, take a look at the new "restrict" keyword in C99. All of the APIs in the new UNIX standard make use of this keyword where appropriate. We should all be looking for places where it is missing, or used incorrectly.

C99 MATH ERRORS

C99 also has revamped the handling of floating point errors, especially with regard to NaN. We have an open action item to make sure we are doing this properly. What is a character? Our definition of character seem to have some problems: it is radically different from C99's. It seems to exclude wide characters.

This may have been deliberate, but I have not yet figured out why. I imagine it has to do with the definition of APIs. I noticed this too late for us to be able to deal with it at this meeting, even as an action item. I am going to try to look at it and submit an aardvark (if necessary) for the next draft. Look, and see what you think.

AARDVARKS

If you want to point out a problem in this draft standard that you want fixed, you have to submit an aardvark (bug report). If you have never done one before, you will find instructions on the Web site: <http://www.opengroup.org/austin/aardvark/> and <http://www.opengroup.org/austin/bugreport.html>.

Warning: If you want to avoid having it rejected out of hand, take a look at the pro forma rejection types listed in the minutes below, and make sure that (as far as you can tell) your objection doesn't fall under one of those categories.

R1. Reject: the requirement is from a base document and to change it is out of scope. Bringing it in scope would require an interpretation, corrigendum, or resolution from the appropriate body.

R2. Reject: this interface is not a candidate for Legacy; the list of Legacy interfaces considered in March 1999 is now final. It is widely used in historic practice and deprecating this interface would break the contract with the application developer.

R3. Reject: we cannot see the problem at the referenced lines; as such, this comment is non-responsive.

R4. Reject: no action specified in the aardvark comment.

R5. Reject: the review team disagrees with the problem statement because . . . (further rationale needed).

R6. Reject: the review team believes that accepting the proposed change would decrease consensus.

R7. Reject: this is out of scope.