Technical Report (informative) Topic: Conflicts between ISO/IEC 9945 (POSIX) and the Linux Standard Base. Status: Unapproved Draft Author: Andrew Josey, The Open Group Version 1.2.4 Date: 21 October 2004 Change History: This version is updated to report against the the Linux Standard Base Core Specification 2.0.1 (21 October 2004) 001 1.Introduction 002 1.1 Purpose 003 The purpose of this Type 3 Technical Report (informative) is to document 004 the areas of conflict between ISO/IEC 9945 (POSIX) and the Free Standards 005 Group's Linux Standard Base specification such that it can be utilized 006 by the appropriate technical committees when considering harmonization 007 between the standards efforts. 008 ISO/IEC 9945 (POSIX) is an important standard in use throughout the world. 009 There is a significant investment in applications developed for the ISO 010 POSIX standard. With the emergence of a standardization initiative for 011 the Linux operating system there are some areas of conflict that have 012 been identified between the Linux Standard Base specification and the 013 ISO POSIX standards. There is an essential market requirement that the 014 conflicts be resolved so that an application can be written to conform 015 to both standards. Hundreds of millions of dollars of applications are 016 built upon these standards. This report is intended as a starting point 017 to look at resolution of this issue. 018 1.2 Scope 019 The JTC 1/SC 22 Linux Study Group meeting (May 2003) recommended future 020 action towards adopting Linux as a JTC1 standard, and most likely 021 adopting the Linux Standard Base (LSB) specification as a Publicly 022 Available Specification (PAS). The Free Standards Group has attained PAS 023 submitter status to JTC 1. The Free Standards Group intend to submit the 024 LSB for PAS approval. The scope of this technical report is to identify 025 areas of conflict between the LSB 2.0 specification and the ISO/IEC 9945 026 (POSIX) standard. 027 This report is based on the Linux Standard Base Core Specification 2.0.1 028 dated October 2004, and ISO/IEC 9945:2003 edition dated 15th August 2003 029 with ISO/IEC 9945:2003/Cor.1:2004 (published 15 Sep 2004). 030 1.3 Intended Audience 031 032 This document is intended to be submitted to JTC1 as a Technical Report. 033 It is anticipated that they should distribute it to workgroups such 034 as the Austin Group and the Linux Standard Base for which it is in 035 scope. It is also intended to be of interest to systems engineers, 036 technical managers and procurement officers. 037 1.4 Document Overview 038 This document is organized in the following ways: Section two provides 039 a list of differences that could be possible conflicts or extensions in 040 the System Interfaces. Section three provides a list of differences that 041 could be possible conflicts or extensions in the Shell and Utilities. 042 1.5 Acknowledgements 043 Extracts of this document are quoted from the ISO/IEC 9945:2003 and 044 Linux Standard Base documents. 045 Thanks to Paul Eggert for detailed feedback on the Utility Interfaces 046 section of the document. 047 Linux is a registered trademark of Linus Torvalds. 048 LSB is a trademark of the Free Standards Group. 049 POSIX is a registered trademark of the IEEE. 050 2. System Interfaces 051 This section describes possible areas of conflict between the LSB and 052 ISO/IEC 9945 (POSIX) for the System Interfaces. 053 This description is based on the Linux Standard Base Core Specification 054 2.0.1. Note that the descriptions of the known conflicts are taken from 055 the LSB and have not been verified by the Austin Group, thus they may be 056 subject to interpretation of the standard. In some cases, the differences 057 may be upward compatible extensions. In cases where the LSB provides its 058 own API manual page rather than referencing ISO/IEC 9945 then that is 059 noted here and its possible that further investigation might determine 060 that there is no conflict. 061 2.1 Headers and Interface definitions 062 2.1.1 unistd.h 063 LSB requires _XOPEN_VERSION to be defined as 500, whereas 064 ISO/IEC 9945 (for systems supporting the XSI extension) requires 065 the symbolic constant to be defined as 600. 066 2.1.2 creat 067 LSB permits implementations to return ENODEV or ENXIO 068 for non-existent devices, whereas ISO/IEC 9945 requires ENXIO. 069 2.1.3 errno 070 LSB requires ENOTSUP to be defined the same as EOPNOTSUP, 071 whereas ISO/IEC 9945 requires that these errno values be unique. 072 2.1.4 fcntl 073 LSB permits implementation to set O_LARGEFILE 074 According to ISO/IEC 9945, only an application sets fcntl flags, such 075 as O_LARGEFILE. However, the LSB specification also allows implementations 076 to set O_LARGEFILE in a case in which the default behavior matches 077 the O_LARGEFILE behavior, for example off_t is 64 bits. The impact 078 is that applications when calling fcntl with the F_GETFL command may 079 receive the O_LARGEFILE flag set as well as the flags explicitly set by 080 the application. 081 2.1.5 fopen 082 LSB permits implementations to return ENODEV or ENXIO 083 for non-existent devices, whereas ISO/IEC 9945 requires ENXIO. 084 085 2.1.6 freopen 086 LSB permits implementations to return ENODEV or ENXIO 087 for non-existent devices, whereas ISO/IEC 9945 requires ENXIO. 088 2.1.7 getopt 089 The LSB documents a number of GNU extensions to getopt() as well as 090 descriptions of the POSIX requirements. Such extensions include argument 091 ordering. The LSB requires LSB implementations to implement the GNU 092 behavior. The POSIXLY_CORRECT environment variable is documented as a 093 method to obtain ISO/IEC 9945 conforming behavior. 094 2.1.8 ioctl 095 The LSB has its own definition of ioctl() and does not reference ISO/IEC 096 9945. The interface description says that applications shall not call 097 ioctl() unless as explicitly described in the LSB. The sockio man page 098 describes a set of socket ioctl() calls. 099 This would imply that an application that uses the ioctl() function 100 as described in ISO/IEC 9945 is not conforming to the LSB. Such an 101 application would be using the XSR option (XSI STREAMS option) within 102 ISO/IEC 9945. 103 2.1.9 kill 104 Process ID -1 doesn't affect calling process 105 If pid is specified as -1, LSB says that sig shall not be sent to the 106 calling process, whereas ISO/IEC 9945 states "If pid is -1, sig shall be 107 sent to all processes (excluding an unspecified set of system processes) 108 for which the process has permission to send that signal.". 109 This was a deliberate Linus decision after an unpopular experiment 110 in including the calling process in the 2.5.1 kernel. See "What does 111 it mean to signal everybody?", Linux Weekly News, 20 December 2001, 112 http://lwn.net/2001/1220/kernel.php3 113 2.1.10 open 114 LSB permits implementations to return ENODEV or ENXIO 115 for non-existent devices, whereas ISO/IEC 9945 requires ENXIO. 116 117 2.1.11 opterr, optind, optopt 118 The LSB has its own definition of opterr, optind and optopt and does not 119 reference ISO/IEC 9945. 120 2.1.12 strerror_r 121 The Synopsis for strerror_r is defined in the LSB to have a return value 122 of type extern char * , whereas ISO/IEC 9945 defines the return value to 123 be type int. 124 Also according to the LSB it is optional whether an implementation 125 copies a message into the supplied buffer. 126 2.1.13 strptime 127 The LSB documents an issue with limiting the number of leading zeroes. 128 This may be a conflict and needs further investigation 129 as to the interpretation of ISO/IEC 9945 . 130 LSB states: 131 "Number of leading zeroes limited 132 The Single UNIX Specification, Version 2 specifies fields for which 133 "leading zeros are permitted but not required"; however, applications must 134 not expect to be able to supply more leading zeroes for these fields than 135 would be implied by the range of the field. Implementations may choose 136 to either match an input with excess leading zeroes, or treat this as 137 a non-matching input. For example, %j has a range of 001 to 366, so 0, 138 00, 000, 001, and 045 are acceptable inputs, but inputs such as 0000, 139 0366 and the like are not. 140 Rationale 141 glibc developers consider it appropriate behavior to forbid excess 142 leading zeroes. When trying to parse a given input against several format 143 strings, forbidding excess leading zeroes could be helpful. For example, 144 if one matches 0011-12-26 against %m-%d-%Y and then against %Y-%m-%d, 145 it seems useful for the first match to fail, as it would be perverse to 146 parse that date as November 12, year 26. The second pattern parses it 147 as December 26, year 11. 148 The Single UNIX Specification is not explicit that an unlimited 149 number of leading zeroes are required, although it may imply this. 150 The LSB explicitly allows implementations to have either behavior. 151 Future versions of this standard may require implementations to forbid 152 excess leading zeroes." 153 2.1.14 unlink 154 May return EISDIR on directories 155 The LSB states that if path specifies a directory, a return 156 of EISDIR is permitted instead of EPERM as required by ISO/IEC 9945. 157 LSB notes that "The Linux kernel has deliberately chosen EISDIR for this 158 case and does not expect to change (Al Viro, personal communication)." 159 2.1.15 waitpid 160 The LSB does not require implementations to support the 161 WCONTINUED or WIFCONTINUED functionality within waitpid(). 162 2.2 ISO/IEC 9945 system interfaces not in the LSB 163 There are a number of system interfaces in ISO/IEC 9945 that are not in 164 the LSB. Whilst not a direct conflict, a consequence of this is that 165 some applications written to ISO/IEC 9945 will not port to a strict 166 LSB implementation. It is recommended that development of a porting 167 guide be considered. 168 A number of known areas are noted below: 169 waitid 170 The LSB does not include the waitid() function, whereas it is a first 171 class function in ISO/IEC 9945 (but in the XSI option group). 172 The consequence of this is that an application written to conform to 173 ISO/IEC 9945 using waitid() does not conform to the LSB. 174 Realtime Threads Options 175 The LSB does not support functionality associated with the 176 Realtime options defined by ISO/IEC 9945 as the Realtime Threads, and 177 Advanced Realtime Threads Option Groups (see ISO/IEC 9945, 178 Base Definitions, section 2.1.5.2). Consequently any applications 179 using those features will not be LSB conforming. 180 XSI STREAMS Option 181 The LSB does not support functionality associated with the 182 XSI STREAMS option defined by ISO/IEC 9945. 183 3. Shell and Utilities Interfaces 184 This section describes possible areas of conflict between the LSB and 185 ISO/IEC 9945 (POSIX) for the Shell and Utilities. 186 This description is based on the Linux Standard Base Core Specification 187 2.0.1. Note that the descriptions of the known conflicts are taken from 188 the LSB and have not been verified by the Austin Group, thus they may be 189 subject to interpretation of the standard. Deprecated differences are 190 not listed since they are assumed to be removed at some future point. 191 In some cases, the differences may be upward compatible extensions. In 192 cases where the LSB provides its own API manual page rather than 193 referencing ISO/IEC 9945 then that is noted here and its possible that 194 further investigation might determine that there is no conflict. 195 3.1 Utility definitions 196 3.1.1 ar 197 The ar utility is deprecated in the LSB. 198 3.1.2 at 199 The LSB lists the following differences: 200 -d is functionally equivalent to the -r option specified in ISO/IEC 9945 201 -r need not be supported on LSB implementations, but the '-d' option 202 is equivalent. 203 -t time 204 need not be supported. 205 The files at.allow and at.deny reside in /etc rather than /usr/lib/cron 206 on LSB implementations. 207 3.1.3 awk 208 The LSB lists the following differences: 209 Certain aspects of internationalized regular expressions are optional. 210 3.1.4 batch 211 The LSB lists the following differences: 212 The files at.allow and at.deny reside in /etc rather than /usr/lib/cron 213 on LSB implementations. 214 3.1.5 bc 215 In order to obtain ISO/IEC 9945 conforming behavior, applications 216 are required to use the -s or --standard option to bc. 217 The -w option can provide warnings for bc extensions being 218 used over the ISO/IEC 9945 definition. 219 3.1.6 chgrp 220 The -L, -H, and -P options need not be supported by LSB implementations. 221 ISO/IEC 9945 defines these options for manipulating symbolic 222 links. 223 3.1.7 chown 224 The -L, -H, and -P options need not be supported by LSB implementations. 225 ISO/IEC 9945 defines these options for manipulating symbolic 226 links. 227 3.1.8 crontab 228 The LSB lists the following differences: 229 The files at.allow and at.deny reside in /etc rather than /usr/lib/cron 230 on LSB implementations. 231 3.1.9 cut 232 The LSB lists the following difference: 233 -n has unspecified behavior. 234 ISO/IEC 9945 defines the behavior of "-n" 235 Do not split characters. When specified with the -b option, each 236 element in list of the form low- high (hyphen-separated numbers) 237 shall be modified as follows: 238 * If the byte selected by low is not the first byte of a character, 239 low shall be decremented to select the first byte of the character 240 originally selected by low. If the byte selected by high is not 241 the last byte of a character, high shall be decremented to select 242 the last byte of the character prior to the character originally 243 selected by high, or zero if there is no prior character. If the 244 resulting range element has high equal to zero or low greater than 245 high, the list element shall be dropped from list for that input 246 line without causing an error. 247 Each element in list of the form low- shall be treated as above with 248 high set to the number of bytes in the current line, not including 249 the terminating . Each element in list of the form - high 250 shall be treated as above with low set to 1. Each element in list 251 of the form num (a single number) shall be treated as above with 252 low set to num and high set to num. 253 3.1.10 df 254 The LSB lists the following differences: 255 If the -k option is not specified, disk space is shown in unspecified 256 units. Applications should specify -k. 257 If an argument is the absolute file name of a disk device node containing 258 a mounted filesystem, df shows the space available on that filesystem 259 rather than on the filesystem containing the device node (which is always 260 the root filesystem). 261 3.1.11 du 262 The LSB lists the following differences: 263 If the -k option is not specified, disk space is shown in unspecified units. 264 Applications should specify -k. 265 3.1.12 echo 266 Unlike the behavior specified in ISO/IEC 9945, LSB states that support for 267 options is implementation defined, and that the behavior of echo if any 268 arguments contain backslashes is also implementation defined. Applications 269 are advised not to run echo with a first argument starting with a hyphen, 270 or with any arguments containing backslashes; they must use printf in 271 those cases. 272 The behavior specified here is similar to that specified by the Single UNIX 273 Specification version 3 without the XSI option. However, the LSB forbids all 274 options and ISO/IEC 9945 forbids only -n. 275 3.1.13 file 276 The LSB lists the following differences: 277 The -M, -h, -d, and -i options need not be supported. 278 3.1.14 find 279 The LSB lists the following differences: 280 Some elements of the Pattern Matching Notation are optional; see 281 Internationalization and Pattern Matching Notation. 282 3.1.15 fuser 283 The LSB lists the following differences: 284 -c has unspecified behavior. 285 -f has unspecified behavior. 286 3.1.16 grep 287 The LSB lists the following differences: 288 Some elements of the Pattern Matching Notation are optional; see 289 Internationalization and Pattern Matching Notation. 290 3.1.17 ipcrm 291 The LSB states that if any of the -q, -Q, -s, -S, -m, or -M arguments 292 are given, the ipcrm shall behave as described in ISO/IEC 9945. 293 Otherwise, ipcrm shall remove the resource of the specified type identified by 294 id. 295 3.1.18 ipcs 296 The LSB has its own definition of ipcs and does not 297 reference ISO/IEC 9945. 298 3.1.19 ls 299 The LSB lists the following differences: 300 -l If the file is a character special or block special file, the size 301 of the file shall be replaced with two unsigned numbers in the format 302 "%u, %u", representing the major and minor device numbers associated 303 with the special file. 304 -p 305 in addition to the behavior of printing a slash for a directory, 306 ls -p may display other characters for other file types. 307 For the -p difference, since the ISO/IEC 9945 only defines the behavior 308 for directories this appears to be an upward compatible extension. 309 The LSB states that certain aspects of the pattern matching notation 310 are optional. 311 3.1.20 more 312 The LSB lists these as differences, 313 The more command need not respect the LINES and COLUMNS environment 314 variables. 315 The more command need not support the following interactive commands: 316 g 317 G 318 u 319 control u 320 control f 321 newline 322 j 323 k 324 r 325 R 326 m 327 ' (return to mark) 328 /! 329 ? 330 N 331 :e 332 :t 333 control g 334 ZZ 335 -num 336 specifies an integer which is the screen size (in lines). 337 -e 338 has unspecified behavior. 339 -i 340 has unspecified behavior. 341 -n 342 has unspecified behavior. 343 -p 344 Either (1) clear the whole screen and then display the text (instead 345 of the usual scrolling behavior), or (2) provide the behavior 346 specified by ISO/IEC 9945. In the latter case, the syntax is 347 "-p command". 348 -t 349 has unspecified behavior. 350 3.1.21 newgrp 351 The LSB states that implementations need not support the -l 352 option as required in ISO/IEC 9945. 353 3.1.22 od 354 The LSB lists these as differences. 355 -w, --width[=BYTES] 356 outputs BYTES bytes per output line. 357 --traditional 358 accepts arguments in pre-POSIX form described below 359 Pre-POSIX and XSI Specifications 360 The LSB supports option intermixtures with the following pre-POSIX 361 and XSI specifications: 362 -a 363 is equivalent to -t a, selects named characters. 364 -f 365 is equivalent to -t fF, selects floats. 366 -i 367 is equivalent to -t d2, selects decimal two byte units 368 -l 369 is equivalent to -t d4, selects decimal longs. 370 3.1.23 renice 371 The LSB lists the following differences: 372 -n increment 373 has unspecified behavior. 374 3.1.24 sed 375 The LSB lists the following differences: 376 Certain aspects of internationalized regular expressions are optional 377 3.1.25 xargs 378 The LSB lists the following differences: 379 -E 380 has unspecified behavior. 381 -I 382 has unspecified behavior. 383 -L 384 has unspecified behavior. 385 3.2 Internationalization 386 The LSB makes certain internationalization aspects optional. 387 3.2.1 Regular Expressions 388 Utilities that process regular expressions shall support Basic Regular 389 Expressions and Extended Regular Expressions as specified in ISO/IEC 9945 390 with the following exceptions: 391 Range expression (such as [a-z]) can be based on code point order instead 392 of collating element order. 393 Equivalence class expression (such as [=a=]) and multi-character collating 394 element expression (such as [.ch.]) are optional. 395 Handling of a multi-character collating element is optional. 396 This affects at least the following utilities: grep, sed, and awk. 397 3.2.2 Pattern Matching Notation 398 Utilities that perform Pattern Matching Notation shall do it as specified 399 in ISO/IEC 9945 with the following exceptions: 400 Range expression (such as [a-z]) can be based on code point order instead 401 of collating element order. 402 Equivalence class expression (such as [=a=]) and multi-character collating 403 element expression (such as [.ch.]) are optional. 404 Handling of a multi-character collating element is optional. 405 3.3 ISO/IEC 9945 Utility interfaces not in the LSB 406 There are a number of utility interfaces in ISO/IEC 9945 that are not in 407 the LSB. Whilst not a direct conflict, a consequence of this is that 408 some applications written to ISO/IEC 9945 will not port to a strict 409 LSB implementation. It is recommended that development of a porting 410 guide be considered. 411 A number of known areas are noted below: 412 Partial coverage of the User Portability Utilities option 413 The LSB does not require a full implementation of the 414 User Portability Utilities option, for example it does 415 require support for the at, batch, crontab, csplit, df, du, 416 expand, file, man, more, newgrp, nice, patch, ps, renice, split, 417 time, and unexpand. It omits support for alias, bg, 418 ctags, ex, fc, fg, jobs, mesg, nm, strings, tabs, talk, tput, 419 unalias, uudecode, uuencode, vi, who and write. 420 Development options 421 The LSB does not require implementations to support 422 the various development options with ISO/IEC 9945. 423 APPENDIX A 424 This appendix contains background information on the POSIX 425 Standards and the Linux Standard Base specification. 426 A1. POSIX Standards 427 The POSIX standards, are the foundations of the UNIX system and Linux 428 API sets. The development body for the POSIX standards has been 429 the IEEE in association with ISO/JTC1/SC22/WG15. 430 This section provides an overview of the POSIX standards. 431 A1.1 The Portable Application Standards Committee (PASC) 432 The IEEE Computer Society's Portable Application Standards Committee 433 (PASC) is the group that has and continues to develop the POSIX family 434 of standards. Historically, the major work has been undertaken within 435 Project 1003 (POSIX) with the best known standard being IEEE Std 1003.1 436 (also known as POSIX 1003.1, colloquially termed "dot 1"). The goal of 437 the PASC standards has been to promote application portability at the 438 source code level. 439 More Information about the Portable Application Standards Committee 440 (PASC) is available from: 441 http://www.pasc.org 442 A1.2 IEEE POSIX 1003.1 System Application Interface (C API) 443 Historically, this has been the base standard upon which the POSIX 444 family of standards has been built. In keeping with its original focus 445 on the UNIX system, it is aimed at interactive timesharing computing 446 environments. The latest version of this standard was produced by the 447 Austin Group (see later). In general the Linux operating system 448 aims to comply with the POSIX 1003.1 standard. 449 The first edition of IEEE Std 1003.1 was published in 1988. Subsequent 450 editions were published in 1990, 1996 and 2001. The 1990 edition was a 451 revision to the 1988 edition and became the stable base standard onto 452 which further amendments were added. The 1990 edition was also approved 453 as an international standard, ISO/IEC 9945-1:1990. 454 The 1996 edition added the IEEE Std 1003.1b-1993, IEEE Std 1003.1c-1995, 455 and 1003.1i-1995 amendments to the base standard, keeping the stable core 456 text unchanged. The 1996 edition of IEEE Std 1003.1 was also approved 457 as an international standard, ISO/IEC 9945-1:1996. 458 In 1998 the first real-time profile standard, IEEE Std 1003.13-1998 was 459 published, enabling POSIX to address embedded real-time applications 460 and smaller footprint devices. 461 In 1999 the decision was taken to commence the first major revision to 462 the core base standard in ten years, including a merger with the 1003.2 463 standards for Shell and Utilities which had been a separate standard 464 up to this point . It was agreed that this work be undertaken by the 465 Austin Group (see later ). As part of this decision the PASC decided 466 to cease rolling amendments to the base standard after completion of 467 IEEE Stds 1003.1a, 1003.1d, 1003.1g, 1003.1j, 1003.1q, and 1003.2b. 468 These projects were rolled into the 2001 edition of IEEE Std 1003.1. 469 It was decided to convert other projects in progress to standalone 470 documents. 471 A1.3 IEEE POSIX 1003.2 Shell and Utilities 472 This standard defines a standard source level interface to the shell 473 and utility functionality required by application programs, including 474 shell scripts. This standard has been incorporated into the IEEE Std 475 1003.1-2001 produced by the Austin Group. The compliance level 476 of the Linux operating system is harder to determine for the 477 shell and utilities. 478 A1.4 IEEE POSIX Standards for Real-time 479 The PASC Real-time System Services Working Group (SSWG-RT) has developed 480 a series of standards that amend IEEE Std 1003.1-1990 and a profile 481 standard (IEEE Std 1003.13-1998). 482 The Real-time amendments to IEEE Std 1003.1-1990 are as follows: 483 IEEE Std 1003.1b-1993 Realtime Extension 484 IEEE Std 1003.1c-1995 Threads 485 IEEE Std 1003.1d-1999 Additional Realtime Extensions 486 IEEE Std 1003.1j-2000 Advanced Realtime Extensions 487 IEEE Std 1003.1q-2000 Tracing 488 These have all been folded in as options within the revision project 489 undertaken by the Austin Group (see below). 490 The Real-time profile is known as IEEE Std 1003.13-1998. At the time 491 of writing there is a revision to IEEE Std 1003.13-1998 in progress to 492 align it with IEEE Std 1003.1-2001, this project current known as IEEE 493 P1003.13-200x. 494 A1.5 The Austin Group 495 The Austin Group is the working group that manages the POSIX.1 496 specificaton. It is a joint working group of members of the IEEE Portable 497 Applications Standards Committee, members of The Open Group, and members 498 of ISO/IEC Joint Technical Committee 1. Participation is free and open 499 to all interested parties. 500 The Austin Group arose out of discussions amongst the parties which 501 started in early 1998, which led to an initial meeting and formation 502 of the group in September 1998. The purpose for this group has 503 been to revise, combine, and update the following standards: ISO/IEC 504 9945-1, ISO/IEC 9945-2, IEEE Std 1003.1, IEEE Std 1003.2, and the Base 505 Specifications of The Open Group Single UNIX Specification. 506 After two meetings, an agreement was signed in July 1999 between The 507 Open Group and the Institute of Electrical and Electronics Engineers 508 (IEEE), Inc., to formalize the project with the first draft of the 509 revised specifications ("the revision") being made available at the 510 same time. Under this agreement, The Open Group and IEEE agreed to share 511 joint copyright of the resulting work. 512 The base document for the revision was The Open Group's Base volumes 513 of its Single UNIX Specification, Version 2. These were selected since 514 they were a superset of the existing POSIX.1 and POSIX.2 specifications 515 and had some organizational aspects that would benefit the audience for 516 the new revision. 517 The approach to specification development has been one of "write once, 518 adopt everywhere", with the deliverables being a set of specifications 519 that carry the IEEE POSIX designation, The Open Group's Technical 520 Standard designation, and an ISO/IEC designation (see below). This set of 521 specifications also forms the core of the Single UNIX Specification, Version 3. 522 The Open Group and the IEEE approved the Austin Group specifications in 523 late 2001, as The Open Group Base Specifications, Issue 6, and IEEE Std 524 1003.1-2001 respectively. ISO/IEC approval followed about twelve 525 months later. 526 The Austin Group Specifications consist of the following : 527 * Base Definitions, Issue 6 (XBD) 528 * Shell and Utilities, Issue 6 (XCU) 529 * System Interfaces, Issue 6 (XSH) 530 * Rationale (Informative) 531 The revision has tried to minimize the number of changes that 532 implementations which conform to the earlier versions of the approved 533 standards would require to bring them into conformance with the current 534 standard. Specifically, the scope of the project excluded doing any 535 ``new'' work, but rather collecting into a single document what had 536 been spread across a number of documents, and presenting it in what 537 had been proven in practice to be a more effective way. Some changes 538 to prior conforming implementations were unavoidable, primarily as a 539 consequence of resolving conflicts found in prior revisions, or which 540 became apparent when bringing the various pieces together. Also, since 541 the revision now references the 1999 version of the ISO C standard, 542 there are a number of unavoidable changes that have been made which will 543 affect applications portability. 544 The 2004 edition of the 1003.1 standard was published on April 30th 545 2004, and updates the 2001 edition of the standard to include Technical 546 Corrigendum 1 (TC1) and Technical Corrigendum 2 (TC2). The 2004 Edition 547 is formally known as: 548 IEEE Std 1003.1, 2004 Edition 549 The Open Group Technical Standard Base Specifications, Issue 6 550 551 Includes IEEE Std 1003.1-2001, IEEE Std 1003.1-2001/Cor 1-2002 and 552 IEEE Std 1003.1-2001/Cor 2-2004 553 The second technical corrigendum (TC2) was published by 554 ISO/IEC as ISO/IEC 9945:2003/Cor-1:2004 on September 15 2004. 555 More information on the Austin Group, including how to join and 556 participate is available from its web site at 557 http://www.opengroup.org/austin/ 558 A html version of the specification is freely available from 559 The Open Group's Single UNIX Specification web site at 560 http://www.unix.org/version3/ 561 A1.5.1 Relationship to the ISO C Standard 562 The most recent revision to the ISO C standard occurred in 1999. 563 The ISO C standard is itself independent of any operating system in so 564 much as it may be implemented in many environments including 565 hosted environments. 566 The POSIX and Single UNIX Specification have a long history 567 of building on the ISO C standard and deferring to it where applicable. 568 Revisions of POSIX.1 prior to the Austin Group specification built upon 569 the ISO C standard by reference only, and also allowed support for traditional 570 C as an alternative. The Single UNIX Specification in contrast, 571 included manual pages for the ISO C interfaces. 572 The Austin Group took the latter approach. The standard 573 developers believed it essential for a programmer to have a single 574 complete reference place. They also recognized that deference to the formal 575 standard had to be addressed for the duplicate interface definitions 576 which occur in both the ISO C standard and their document. 577 It was agreed that where an interface has a version in the ISO C standard, 578 the DESCRIPTION section should describe the relationship to the ISO C 579 standard and markings added as appropriate within the manual page to 580 show where the ISO C standard has been extended. 581 A block of text was added to the start of each affected reference 582 page stating whether the page is aligned with the ISO C standard or 583 extended. Each page was parsed for additions beyond the ISO C standard 584 (that is, including both POSIX and UNIX extensions), and these extensions 585 are marked as CX extensions (for C Extensions). 586 A1.6 ISO/IEC 9945 587 In late 2002, the ISO/IEC Joint Technical Committee approved the joint 588 revision to POSIX and the Single UNIX Specification as an International 589 Standard. Designated as ISO/IEC 9945:2002, the joint revision forms 590 the core of The Open Group's Single UNIX Specification Version 3 (IEEE 591 1003.1-2001, POSIX.1). 592 The combining of the IEEE POSIX specifications and the Single UNIX 593 Specification into ISO/IEC 9945:2002 Parts 1 to 4 replaces the existing 594 ISO/IEC 9945-1:1996 (IEEE 1003.1, 1996 version), and ISO/IEC 9945-2:1993 595 (IEEE Std 1003.2, 1992 version). 596 ISO/IEC 9945 consists of the following parts, under the general title 597 Information technology Portable Operating System Interface (POSIX): 598 Part 1: Base Definitions 599 Part 2: System Interfaces 600 Part 3: Shell and Utilities 601 Part 4: Rationale 602 The 2003 Edition of the Austin Group specifications was published as 603 ISO/IEC 9945:2003 on August 15 2003. 604 The latest technical corrigendum is due to be published 605 shortly and is designated as ISO/IEC 9945:2003/Cor.1:2004. 606 A2.2 The Linux Standard Base Specification 607 The Linux Standard Base (LSB) Specification is an application binary 608 interface standard for shrink-wrapped applications. The purpose is to 609 allow commonality amongst the many Linux distributions. 610 The LSB draws on the source standards of IEEE POSIX 1003.1 and The Open 611 Group Single UNIX Specification for many of its interfaces although does 612 not formally defer to them preferring to document any differences where 613 they exist, such as where certain aspects of Linux cannot currently 614 conform to the industry standards, one particular example for early 615 versions of the LSB being the area of threads. Some interfaces are 616 not included in the LSB, since they are outside the remit of a binary 617 runtime environment, typically these are development interfaces or user 618 level tools . The LSB also extends the source standards in other areas 619 (such as graphics), and includes the necessary details such as the binary 620 execution file formats to support a high volume application platform. 621 Although in theory the LSB is not tied to the GNU/Linux operating system, 622 in practise the binary definitions are tightly coupled to the Linux operating 623 system and the GNU C compiler. 624 The LSB is available as a family of specifications supporting a 625 number of processor architectures including IA32, PPC32, PPC64, IA64, 626 S390 and S390X. There is a generic specification, common to all the 627 processor architectures known as the "generic LSB" (or gLSB), and for 628 each processor architecture an architecture-specific specification 629 ("archLSB") describing the details that vary by processor architecture. 630 To support the specification, the LSB includes a number of 631 development tools, including test suites, and a set of reference 632 conforming applications. Binary versions of the test suites and 633 reference applications are used for formal LSB certification of runtime 634 environments. All the major Linux vendors today have certified LSB 635 systems. 636 LSB 1.2, introduced in January 2002, was the first version of the 637 specification to have an equivalent LSB certification program. LSB 1.2 638 certification, which commenced in July 2002 is limited to the IA32 ABI. 639 LSB 1.3 certification includes additional support for the IA64, PPC32, 640 PPC64, S390 and S390X architectures. At the time of writing there are 641 thirty-eight certified runtime environments from 11 vendors. 642 The specification is evolving quite rapidly. LSB 1.3, introduced in 643 January 2003, adds some internationalization, PAM, packaging, static C++ 644 linking, bug fixes, plus IA64, PPC32, S390, and S390X. 645 LSB 2.0 was completed in August 2004, and adds some alignment 646 with ISO/IEC 9945:2003, support for 647 C++, and the additional architectures of AMD64 and PPC64. 648 LSB 2.0.1 was completed in October 2004, and is a minor revision 649 in preparation for the PAS submission to ISO. 650 Detailed information on the LSB is available from: 651 http://www.linuxbase.org 652 653 Detailed information on the LSB Certification Program is available 654 from the LSB Certification Authority at 655 http://www.opengroup.org/lsb/cert/ 656 The Guide to LSB Certification is available at: 657 http://www.opengroup.org/lsb/cert/docs/LSB_Certification_Guide.html 658 The LSB Certification Register can be viewed at: 659 http://www.opengroup.org/lsb/cert/register.html