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