2005 was a busy year for me as of POSIX was published (the the USENIX standards represen- Shell and Utilities volume), and tative. There are three major it became a second ISO standard. NICHOLAS M. STOUGHTON standards that I watch carefully: Amendments to these standards I POSIX, which also incorpo- were also under development, USENIX rates the Single UNIX Specifi- and led to the addition of real- cation time interfaces, including Standards I ISO-C pthreads, to the core system call I The Linux Standard Base (LSB) set. Many of the other projects Activities died away as the people involved In order to do that, USENIX lost interest or hit political road- funds my participation in the blocks (most of which were Nick is the USENIX Standards committees that develop and reported in ;login: at the time). Liaison and represents the maintain these standards. Association in the POSIX, ISO C, Throughout 2005, the Free Until the end of the twentieth and LSB working groups. He is century, POSIX was developed the ISO organizational repre- Standards Group (FSG) also sentative to the Austin Group, helped fund these activities. For and maintained by IEEE exclu- a member of INCITS commit- each of these, let’s look at the his- sively. At the same time, the tees J11 and CT22, and the Open Group (also known as Specification Authority sub- tory of the standards, then at group leader for the LSB. what has happened over the past X/Open) had an entirely separate but 100% overlapping standard, [email protected] 12 months or so, and, finally, what is on the agenda for this known as the Single UNIX year. Each of these standards is Specification. This specification critical to a large proportion of started from the same place in our members. Without these history, and many of the partici- standards, open source software pants around the table at an as we know it today would be X/Open meeting were the exact very, very different! same people who had met a few weeks before at an IEEE POSIX meeting to discuss the same set POSIX of issues! The POSIX family of standards This duplication of effort became was first developed by the IEEE, so annoying that a new, collabo- arising from earlier work from rative, group was formed to pro- /usr/group and the System V duce a single document that Interface Definition (SVID), would have equal standing for and was published as a “trial use” each of ISO, IEEE, and the Open standard in 1986. In 1988, the Group. That group held its first first full-use standard was pub- meeting in Austin, Texas, in lished. The difference between 1998, and was therefore named “trial” and “full” use is principal- the “Austin Group.” The Austin ly in the use of the term “should” Group published a full revision rather than “shall” in the require- of the POSIX and Single UNIX ments for any interface. specifications as a single docu- ment in 2001. It was adopted by In 1990, the 1988 API standard all three organizations and is was revised, clarifying a number maintained by the same team, of areas and expanding them. At which represents the interests of the same time, the API standard all three member organizations. became an ISO standard. At this point in history, there were about Since the 2001 revision, work 10 separate POSIX projects under has been steadily progressing development, ranging from the maintaining this 3762-page mas- basic OS system calls and libra- terpiece. Every week, there is a ries, through commands and util- steady stream of “defect reports,” ities, to security, remote file which range from typos in the access, super-computing, and HTML version (the document is more. In 1992, the second part freely available in HTML on the 72 ;LO GIN: V OL. 31, NO. 2 Web; see http://www.unix.org nal files, getline and getdelim, ISO C /single_unix_specification), some multibyte string-handling through major issues with functions, robust mutexes, and The first version of the ISO C ambiguous definitions, and so versions of functions that take standard, then known as ANSI- on. Some of these defects can be pathnames relative to a directory C, was published in 1989. It quickly and cleanly fixed, and file descriptor rather than plain took the original language from two “Technical Corrigenda” pathnames (this helps avoid cer- Kernighan and Ritchie’s book documents have been approved, tain race conditions and helps and tightened it up in a num- which alter the wording for with really long pathnames). ber of places. It added function some of the interfaces to clarify I would expect to see official prototypes and considerably their meanings. drafts of this new revision this improved on the standard C Every ISO standard (and every summer, and the final version in library. The first versions of IEEE standard, too) has a five- 2008. POSIX used this language as the underlying way to describe inter- year “reaffirm/revise/withdraw” POSIX has long had support process, where the document faces, and included a c89 com- beyond the C language world. mand to invoke the compiler. is examined to see if it is still There are Ada and Fortran offi- relevant, whether it needs revi- cial “bindings” to POSIX. How- Between 1989 and 1999, the C sion to meet current needs, or ever, there has never been a real committee added wide character whether it is now outdated and connection between the C++ support and addressed several should be withdrawn. For world and the POSIX world; language “defects”—internal POSIX, the Austin Group has C++ programs can use C to call discrepancies in the way various elected to revise the specifica- POSIX functions. But this leads features were described. The tion during 2006. to all sorts of complications for committee included a number Under the Austin Group rules, C++ programmers and, more of compiler vendors, who were the group as a whole cannot seriously, to much reinvention also keen to have the language invent new material. One of its of the wheel in providing map- permit ways to guide an opti- sponsor groups (IEEE, ISO, and pings between C++ constructs mizer: features such as con- the Open Group) must have and those of POSIX. The Austin stants, volatile variables and prepared a document and had it Group has received several restrict pointers were added to adopted under its own organiza- defects from C++ programmers the language for this purpose. tion rules before it can be pre- who want to know why they In 1999, a new revision came sented to the group as a whole. can’t do x, to which the tradi- out which included several new Therefore, the Open Group has tional answer has been “don’t features such as these, along been developing, and is now in use C++, use C”! And to make with major rework for floating the final stages of approving, a matters worse, the C++ language point support (including things number of documents which committee is also going through such as complex numbers). include new APIs to become a a revision at present, and they At this point, the committee is possible future part of a UNIX want to add all sorts of features fairly happy with the state of branding program. Once ap- to the language that might make the core language and is fight- proved, these documents can it harder to access some of the ing back against proposals to then be examined by the Austin fine-grained features of POSIX change it. However, they have Group (OK, so it’s still the same (since they want the language not stopped working! They are group of people who developed to work on other platforms, currently preparing several tech- the set in the first place) for they deliberately try to be OS- nical reports that optionally inclusion into the POSIX neutral). extend the C language in a revision. All that may change soon. A number of directions. Of these, The new interfaces under con- study group has recently been by far the most significant to sideration are ones that have formed to look into the need most USENIX members is the been popular in the GNU-C for, and desire to build, a C++ report formerly known as the library (glibc) and Solaris for binding to POSIX. USENIX is “Security TR.” I say formerly some time, but have not been hosting the wiki for this group, because the term “Security” formally standardized before. and you are welcome to join: (and it turns out, many other They include support for stan- http://standards.usenix.org/posix related words) are so overloaded dard I/O functions to operate on ++wiki. and charged with meaning that memory buffers as well as exter- ;LOGIN: APRI L 2006 USENIX STANDARDS ACTIVITIES 73 by far the most objections to the to prevent buffer overflows, but buffers, and the application document were to its title. it hasn’t! slowly leaks memory. However, I The report formerly called the It will also likely change the ABI believe this is a smaller problem “Security TR” actually attempts of third-party libraries that want than the use of static buffers to deal with the fairly common to use this; they must now have with guessed sizes. problem of buffer overflow. It a way of receiving the size to Back to the name of this report: does so in a very simple fashion: check against. This suggests to as I said , “Secure Library” got every interface in the ISO-C me that this library will have lit- a ringing “no” vote.