Subject: N 3823-ISO/IEC TR 34715-Technical Report on the Conflicts Between the ISO/IEC 9945 (POSIX) Standard and the Linux Standard Base Specificat ion (LSB)

From: Sally Seitz <[email-masked]>
Date: Fri, 22 Oct 2004 16:36:16 -0400

ISO/IEC JTC 1/SC22

Programming languages, their environments and system software interfaces

Secretariat:  U.S.A.  (ANSI)

ISO/IEC JTC 1/SC22 N3823

TITLE: ISO/IEC TR 24715-Technical Report on the Conflicts between the
ISO/IEC 9945 (POSIX) Standard and the Linux Standard Base Specification
(LSB)

DATE ASSIGNED:

2004-10-22

SOURCE:

Project Editor (A. Josey)

BACKWARD POINTER:

DOCUMENT TYPE:

DRAFT TR Text

PROJECT NUMBER:

STATUS:

This document is issued per JeJu Resolution 04-16 which stated: "JTC 1SC 22
instructs the project editor for the Technical Report on conflicts between
POSIX and LSB to make available a draft of the report based on LSB 2.0.1
before the commencement of the PAS Transposition Ballot on the LSB Core
Document."  The JTC 1 Secretariat has submitted the PAS documents to ITTF
for ballot today, 2004-10-22. 

DUE DATE:

DISTRIBUTION:

TEXT

ACTION ID:

FYI

CROSS REFERENCE:

DISTRIBUTION FORM:

Def

Address reply to:

ISO/IEC JTC 1/SC22 Secretariat

Sally Seitz

ANSI

25 West 43rd Street

New York, NY  10036

Telephone:  (212) 642-4918

Fax:             (212) 840-2298

Email:  [email-masked] <mailto:[email-masked]> 

__________________________________________End of cover page, beginning of
document____________________________________

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 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 <newline>. 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

Sally Seitz

Program Administrator

ANSI

25 West 43rd Street

New York, NY 10036

Phone: (212) 642-4918

Fax: (212) 840-2298