Generic UNIX ABI-41

8/3/2019 Generic UNIX ABI-41

http://slidepdf.com/reader/full/generic-unix-abi-41 1/271

SYSTEM V

APPLICATION BINARY INTERFACE

Edition 4.1



Copyright © 1990−1996 The Santa Cruz O peration, Inc. All rights reserved.

Copyright © 1990−1992 AT&T. All rights reserved.

No p art of this publication may be repr oduced, transmitted, stored in a retrieval system, nor translated

into any hu man or compu ter language, in any form or by any means, electronic, mechanical, magnetic,

optical, chemical, manu al, or otherwise, without the p rior written perm ission of the copyright ow ner,The Santa Cruz Oper ation, Inc., 400 Encinal Street, Santa Cru z, California, 95060, USA . Copyright

infringement is a serious matter u nder th e United States and foreign Copyright Laws.

Information in this docum ent is subject to change without notice and d oes not represent a commitment

on the p art of The Santa Cruz Op eration, Inc.

SCO, the SCO logo, The Santa Cruz Op eration, and UnixWare are trademarks or registered tradema rks

of The Santa Cru z Operation , Inc. in the USA and other countries. UNIX is a registered trad emark in

the USA and other countries, licensed exclusively through X/ Open Comp any Limited. NeWS is a

registered trad emark of Sun Microsystems, Inc. X11 and X Window System are trad emarks of

Massachusetts Institute of Technology All other brand a nd p roduct nam es are or ma y be tradem arks

of, and are u sed to identify produ cts or services of, their respective owners.

SCO® UnixWare® is comm ercial computer software an d, together with an y related docum entation, is

subject to the restrictions on US Governmen t use as set forth below. If this procu remen t is for a DO D

agency, the following DFAR Restricted Rights Legend applies:

RESTRICTED RIGHTS LEGEN D: Use, dup lication, or disclosure by the Governmen t is subject to

restrictions as set forth in subp aragr aph (c)(1)(ii) of Rights in Technical Data an d Com pu ter Software

Clause at DFARS 252.227-7013. Contractor/ Manu facturer is The Santa Cru z Oper ation, Inc., 400 Encinal

Street, Santa Cr uz, CA 95060.

If this procurement is for a civilian government agency, this FAR Restricted Rights Legend applies:

RESTRICTED RIGHTS LEGEN D: This computer software is submitted with restricted rights und er

Government Contract No. _________ (and Subcontract No. ________, if app ropr iate). It may not be

used, reprod uced, or d isclosed by the Governm ent except as provided in paragrap h (g)(3)(i) of FAR

Clause 52.227-14 alt III or as otherw ise expressly stated in th e contract. Contractor/ Manu facturer is

The Santa Cru z Op eration, Inc., 400 Encinal Street, Santa Cruz , CA 95060.

If any copyrighted software accompanies this publication, it is licensed to the End User only for use in

strict accordance with the End User License Agreement, which should be read carefully before

commencing use of the software.

ACKNOWLEDGEMENTS

"We acknowledge the contributions of the 88OPEN Consortium Ltd., portions of whose System V ABI

Implementation Guide for the M 88000 Processor and the System V ABI M88000 Processor N etworking

Supplement have been incorporated in this section of the ABI with permission."

DRAFT COPYMarch 18, 1997File: copyright

386:adm.book:sum

Page: 2



Contents

Table of ContentsINTRODUCTION

SOFTWARE INSTALLATIONLOW-LEVEL SYSTEM INFORMATIONOBJECT FILES

PROGRAM LOADING AND DYNAMIC LINKINGLIBRARIES

FORMATS AND PROTOCOLSSYSTEM COMMANDS

EXECUTION ENVIRONMENTWINDOWING AND TERMINAL INTERFACESDEVELOPMENT ENVIRONMENTS FOR AN ABI SYSTEM

NETWORKINGIndex

1 INTRODUCTIONSystem V Application Binary Interface 1-1

Foundations and Structure of the ABI 1-2

How to Use the System V ABI 1-4

Definitions of Terms 1-8

2 SOFTWARE INSTALLATIONSoftware Installation and Packaging 2-1

File Formats 2-7

File Tree for Add-on Software 2-15

Commands That Install, Remove and Access Packages 2-16

Table of Contents i

DRAFT COPYMarch 18, 1997File: MasterToc

386:adm.book:sum

Page: 3



3 LOW-LEVEL SYSTEM INFORMATIONIntroduction 3-1

Character Representations 3-2

Machine Interface (Processor-Specific) 3-3Function Calling Sequence (Processor-Specific) 3-4

Operating System Interface (Processor-Specific) 3-5

Coding Examples (Processor-Specific) 3-6

4 OBJECT FILESIntroduction 4-1

ELF Header 4-4

Sections 4-10

String Table 4-21

Symbol Table 4-22

Relocation 4-27

5 PROGRAM LOADING AND DYNAMICLINKINGIntroduction 5-1

Program Header 5-2

Program Loading (Processor-Specific) 5-11

Dynamic Linking 5-12

6 LIBRARIESIntroduction 6-1

C Library 6-5

Threads Library 6-15

Dynamic Linking Library 6-17

Network Services Library 6-18

Socket Library 6-21

Curses Library 6-22

X Window System Library 6-26

X11 Nonrectangular Window Shape Extension Library 6-33

ii Table of Contents


386:adm.book:sum

Page: 4



X Toolkit Intrinsics Library 6-34

Motif Libraries 6-38

System Data Interfaces 6-46

7 FORMATS AND PROTOCOLSIntroduction 7-1

Archive File 7-2

Other Archive Formats 7-6

Terminfo Data Base 7-7

Formats and Protocols for Networking 7-10

8 SYSTEM COMMANDSCommands for Application Programs 8-1

9 EXECUTION ENVIRONMENTApplication Environment 9-1

File System Structure and Contents 9-3

10 WINDOWING AND TERMINAL INTERFACESThe System V Window System 10-1

System V Window System Components 10-3

11 DEVELOPMENT ENVIRONMENTS FOR ANABI SYSTEMDevelopment Environments 11-1

12 NETWORKINGNetworking 12-1

Table of Contents iii


386:adm.book:sum

Page: 5



Required STREAMS Devices and Modules 12-2

Required Interprocess Communication Support 12-3

Required Transport Layer Support 12-4

Required Transport Loopback Support 12-7

Optional Internet Transport Support 12-8

IN IndexIndex IN-1

iv Table of Contents


386:adm.book:sum

Page: 6



Figures and Tables

Figure 2-1: Package File Tree Organization 2-2

Figure 2-2: Data Stream File Layout for Distribution Media 2-4

Figure 4-1: Object File Format 4-1

Figure 4-2: 32-Bit Data Types 4-3

Figure 4-3: ELF Header 4-4

Figure 4-4: e _ident[ ] Identification Indexes 4-7

Figure 4-5: Data Encoding ELFDATA2LSB 4-9

Figure 4-6: Data Encoding ELFDATA2MSB 4-9

Figure 4-7: Special Section Indexes 4-10

Figure 4-8: Section Header 4-12

Figure 4-9: Section Types, sh _type 4-13

Figure 4-10: Section Header Table Entry: Index 0 4-15

Figure 4-11: Section Attribute Flags, sh _flags 4-16

Figure 4-12: sh _link and sh _info Interpretation 4-17

Figure 4-13: Special Sections 4-17

Figure 4-14: String Table Indexes 4-21

Figure 4-15: Symbol Table Entry 4-22

Figure 4-16: Symbol Binding, ELF32 _ST _BIND 4-23

Figure 4-17: Symbol Types, ELF32 _ST _TYPE 4-24

Figure 4-18: Symbol Table Entry: Index 0 4-26

Figure 4-19: Relocation Entries 4-27

Figure 5-1: Program Header 5-2

Figure 5-2: Segment Types, p _type 5-3

Figure 5-3: Segment Flag Bits, p _flags 5-6Figure 5-4: Segment Permissions 5-6

Figure 5-5: Text Segment 5-7

Figure 5-6: Data Segment 5-7

Figure 5-7: Note Information 5-8

Figure 5-8: Example Note Segment 5-9

Figure 5-9: Dynamic Structure 5-15

Figure 5-10: Dynamic Array Tags, d _tag 5-15

Figure 5-11: Symbol Hash Table 5-21

Figure 5-12: Hashing Function 5-22

Figure 5-13: Initialization Ordering Example 5-25

Figure 6-1: Shared Library Names 6-3

Table of Contents v


386:adm.book:sum

Page: 7



Figure 12-9: XTI values for t _info flags member 12-6

Figure 12-10: TCP Options 12-10

Figure 12-11: IP Options 12-10

Figure 12-12: TCP Options 12-11

Figure 12-13: UDP Options 12-11

Figure 12-14: IP Options 12-12Figure 12-15: Data Structures 12-13

Table of Contents vii


386:adm.book:sum

Page: 9



1 INTRODUCTION

System V Application Binary Interface 1-1


Conformance Rule 1-2


Base and Optional Components of the ABI 1-6

Evolution of the ABI Specification 1-7


Table of Contents i

DRAFT COPYMarch 18, 1997File: Cchap1

386:adm.book:sum

Page: 10



System V Application Binary Interface

The Syst em V Application Binary Int erface, or ABI , defines a system interface for

compiled application programs and a minimal environment for supp ort of instal- E

lation scripts. Its pu rpose is to documen t a stand ard binar y interface for app lica-

tion program s on systems that implement an operating system that complies with X

the X/Open Common Application Environment Specification, Issue 4.2 and the System X

V Interface Definition, Fourth Edition.

The ABI defines a binary interface for ap plication programs that are compiled and

packaged for System V imp lementations on many different hard ware architec-

tur es. Since a binary specification must includ e inform ation specific to the com-

pu ter processor architecture for wh ich it is intended , it is not possible for a single

documen t to specify the interface for all possible System V imp lementations.

Therefore, the System V A BI is a family of specifications, rather th an a single one.

The System V A BI is comp osed of two basic par ts: A generic part of thespecification d escribes those parts of the interface that rema in constant across all

hard ware implem entations of System V, and a p rocessor-specific par t of the

specification d escribes the p arts of the specification th at are specific to a par ticular

processor architecture. Together, the generic ABI and the processor-specific sup-

plement for a single hardware architecture provide a complete interface

specification for compiled application programs on systems that share a common

hard ware architecture.

This document is the generic ABI . It must be used in conjunction with a supp le-

men tal specification containing p rocessor-specific information. Whenever a sec-

tion of this specification mu st be supp lemented by processor-specific informa tion,

the text will reference the processor sup plemen t. The processor sup plemen t may

also contain ad ditional information tha t is not referenced here.

System V Application Binary Interface 1-1

DRAFT COPYMarch 18, 1997

File: chap1386:adm.book:sum

Page: 11



Foundations and Structure of the ABI

The System V A BI is based on several reference docum ents. Because it is a binary

interface, it includ es the fund amen tal set of machine instru ctions for that p roces-

sor to wh ich the specification app lies, and includ es many oth er low-level

specifications th at m ay be stron gly affected by the characteristics of a given

pr ocessor’s architecture. It also includ es higher-level information abou t System V.

The interfaces specified here w ere draw n from existing stand ards for operating

systems, u ser interfaces, programm ing languages, and networking, includ ing

those on the following list and others.

The architectur e man ual for the target system ’s processor.

The System V Interface Definition, Fourth Edition. M

The IEEE POSIX 1003.1-1990 standard operating system sp ecification.

The X/Open Common A pplication Environment Specification (CA E), Issue 4.2. X

The International Standard, ISO/IEC 9899:1990 (E), Programming Languages - E

C, 12/ 15/ 90.

The X W indow SystemTM

, X Version 11, Release 5, grap hical user interface G

specification.

Conformance Rule

NOTE

All interfaces in the X/Open CAE Specification, Issue 4.2 (excluding those Xmarked Withdrawn) and certain interfaces in the System V Application Binary X

Interface, Fourth Edition are contained in this document, the System V Applica- Xtion Binary Interface, Edition 4.1 (System V ABI 4.1) . Note that all interfaces in Xthe System V ABI are conformant to XPG4.2. Those interfaces that were ori- Xginally in the System V Application Binary Interface, Fourth Edition will also be Xconformant to the System V Interface Definition, Fourth Edition in cases where Xthe SVID adds additional functionality over XPG4.2. In all cases where System XV Interface Definition, Fourth Edition functionality conflicts with X/Open CAE XSpecification, Issue 4.2 functionality, X/Open CAE Specification, Issue 4.2 is fol- Xlowed. For this reason certain libraries presented in Chapter 6 and Chapter 8 Xwill be divided into two tables. The first table presents interfaces which are Xgoverned by the specifications in the X/Open CAE Specification, Issue 4.2 and Xthe System V Interface Definition, Fourth Edition . The second tables presents Xinterfaces which were not originally in the System V Application Binary Interface, XFourth Edition and are therefore only governed by the specifications in the

X/Open CAE Specification, Issue 4.2.

1-2 INTRODUCTION



Page: 12



The ABI is divided into sections d ealing with sp ecific portions of the interface.

Some sections includ e a large amoun t of deta iled inform ation, while others con-

tain lists of interface components and pointers to other documents.

In general, this specification d oes not d up licate information th at is available in

other stand ards docum ents. For example, the ABI section th at d escribes systemservice rou tines includ es a list of the system routines supp orted in th is interface,

formal declarations of the data stru ctures they u se that are visible to application

program s, and a pointer to the X /Open CA E Specification, Issue 4.2 and the System V M

Interface Definition, Fourth Edition for information about the syntax and semantics

of each call. Only those rou tines not described in System V Interface Definition, M

Fourth Edition or elsewhere are described in the ABI .

Other sections of the ABI are written using this same mod el. The ABI identifies

operating system components it includes, provides w hatever information abou t

those components tha t is not available elsewh ere, and furn ishes a reference to

another d ocument for further information. Information referenced in this way is

as much a p art of the ABI specification a s is the in formation exp licitly includ ed

here.




Page: 13



How to Use the System V ABI

The complete System V ABI is comp osed of this generic ABI specification and the

sup plemen tal processor-specific specification for a particular pr ocessor architec-

tur e. These two d ocumen ts constitute a specification that shou ld be used in con-

jun ction w ith the pu blicly-available standa rds docum ents it references (some of

these are listed above). The ABI enum erates the system comp onents it includ es,

but descriptions of those comp onents may be includ ed entirely in the ABI , partly

in the ABI and partly in other d ocuments, or entirely in other reference docu-

ments.

App lication p rogramm ers who w ish to produ ce binary p ackages that will install

and run on any System V-based compu ter should follow th is procedu re:

1 . Write program s using the X/Open CA E Specification, Issue 4.2 and the Level 1 X

source-level interfaces described in th e System V Interface Definition, Fourth X

Edition in the following sections. (See the Conformance Rule above.) Rou-tines guaranteed to be presen t on all ABI-conforming systems as

dynam ically-linkable resour ces are listed below.

BA _OS: All Level 1 rou tines are available as shared resources. E

BA _LIB: All Level 1 rou tines are available as shared resources E

except for the math rou tines which may be available as an ABI E

compliant static archive (see Chapter 11):

acos acosh asin asinh atan

atan2 atanh cbrt ceil cos

cosh erf erfc exp fabs

floor fmod gamma hypot j0

j1 jn lgamma log10 log

matherr pow remainder sin sinh *

sqrt tan tanh y0 y1

yn

ABI-conforming applications should not use the encryption rou-

tines crypt(), encrypt(), or setkey(), and should n ot use the

Level 2 routines advance(), compile(), step(), drand48(),

erand48(), jrand48(), lcong48(), lrand48(), mrand48(),

nrand48(), seed48(), and srand48(), since these rou tines are

not required to be present on an ABI-conforming system.

1-4 INTRODUCTION



Page: 14



KE _OS: All Level 1 rou tines in this section are gua ranteed to be E

presen t as shared resou rces on an ABI-conforming system.

RS _LIB: All rou tines in this section are gu aran teed to be presen t as

shared resources on ABI-conforming system s that include net-

working facilities.MT _LIB: All rou tines in this section are guaran teed to be pr esent M

as shared resour ces on ABI-conforming systems.

The rout ines listed in the ‘‘System Library’’ , ‘‘Threads Library ’’ , ‘‘Netw ork E

Services Library’’ , and the ‘‘X Wind ow System Library’’ (see: Chapter 6, 10) E

mu st be accessed as dynam ically-linked resources. Other rou tines may be

dynam ically linked, or may be statically bound into the app lication from an

archive library.

2 . Use only the system utilities and environm ent information described in

Chapters 8 and 9 of the ABI .

3 . Compile programs so that the resulting executable program s use the

specified interface to all system rou tines and services, and have the form at

described in the ABI specification. The command s available on a system E

that also supp orts an ABI development environment is defined in Chapter E

11.

4 . Package the app lication in the format and on the med ia described in the

ABI , and install or create files only in the specified locations prov ided for

this pu rpose when the app lication is installed. The packaging tools avail- E

able on a system that also supp orts an ABI development environment is E

defined in Chapter 11.

The manu facturers of System V-based compu ter systems w ho w ish to p rovide the

system interface described in th is specification mu st satisfy a complem entary set

of requirements:

1 . Their system m ust imp lement fully the architecture described in the

hard ware manu al for their target processor architecture.

2 . The system mu st be capable of executing comp iled p rogram s having the

format d escribed in th is specification.

3 . The system must provide libraries containing the routines specified by the

ABI , and m ust pr ovide a dyn amic linking mechanism that allows these rou-

tines to be attached to application pr ogram s at run time. All the system

routines must behave as specified by th e X /Open CA E Specification, Issue 4.2 X

and the System V Interface Definition, Fourth Edition (see the Conformance X

Rule above).




Page: 15



4 . The system’s map of virtual memory mu st conform to the requirements of

the ABI .

5 . The system’s low-level behavior w ith respect to function call linkage, sys-

tem trap s, signals, and other su ch activities mu st conform to the forma ts

documented in the ABI .6 . The system’s compilation system, if presen t, must comp ile source code into

executab le files having th e formats and characteristics specified in the ABI .

7 . The system mu st provid e all files and u tilities specified as part of the ABI , in

the format defined here and in other referenced d ocuments. All command s

and utilities mu st behave as documented in the X/Open CA E Specification, X

Issue 4.2 and the System V Interface Definition, Fourth Edition (see the Confor- X

man ce Rule above). The system must also pr ovide all other components of

an application’s run-time environment that are included or referenced in

the ABI specification.

8 . The system mu st install packages using the formats and procedure

described in the ABI , and m ust be capable of accepting installable softwa re

packages, either throu gh p hysical media or th rough a netw ork interface.

Base and Optional Components of the ABI

The ABI prov ides tw o levels of interface specification: Base and Op tional. Base

components of the ABI are required to be p resent in all ABI -conforming systems.

Optional components m ay be absent on an ABI-conforming system, but, wh en

they are p resent, they mu st conform to the specification given in the ABI . All com-

ponents of the ABI are to be considered Base comp onents u nless they are explicitly

described as Op tional like the one that follows.

NOTE

THE FACILITIES AND INTERFACES DESCRIBED IN THIS SECTION AREOPTIONAL COMPONENTS OF THE System V Application Binary Interface.

This distinction is necessary because som e ABI capabilities dep end on th e p resence

of hardware or other facilities that may not be p resent, such as integral graph ics

disp lays or netw ork connections and h ard ware. The absence of such facilities

does not p revent a System V-based system from conforming with th e ABI

specification, thou gh it may p revent ap plications tha t need th ese facilities from

run ning on those systems.

1-6 INTRODUCTION



Page: 16



Evolution of the ABI Specification

The Syst em V Application Binary Int erfacewill evolve over time to add ress new

technology and market requ irements, and w ill be reissued at intervals of approxi-

mately th ree years. Each new ed ition of the specification is likely to contain exten-

sions and additions tha t will increase the poten tial capabilities of app lications that

are w ritten to conform to the ABI .

The Syst em V Application Binary Interface, Edition 4.1 includes certain elements X

mar ked as DEPRECATED. An interface, head er, or comman d has been mar ked as X

DEPRECATED if it is specified as To Be Withd raw n in th e X/Open CAE X

Specification, Issue 4.2, or if it is not p resent in the X/Open CA E Specification, Issue X

4.2 and is designated a s Level 2 in the System V Interface Definition, Fourth Edition. X

Long term supp ort for such functions can not be presum ed.




Page: 17



Definitions of Terms

The following terms are u sed throu ghout th is document.

ABI or System V A BI : Refers to the sp ecification that is the su bject of this

docum ent, the System V Application Binary Int erface. The System V A BI for a

par ticular system is composed of the generic ABI and the Processor-specific

Supplement for the processor used in the system.

generic System V ABI or generic ABI : Consists of the processor-indep end ent

portions of the System V Application Binary Interface.

Processor-specific ABI or Processor-specific Supplement : Consists of those p or-

tions of the System V ABI that ar e specific to a particular p rocessor architec-

tur e. Together, the generic ABI and the appropriate Processor-specific Supple-

ment comprise the System V A BI for systems employing a particular proces-

sor architecture.

ABI-conforming system : A comp uter system that pr ovides the binary sys-

tem interface for application programs described in the System V ABI .

ABI-conforming p rogram : A program w ritten to includ e only the system

routines, comm and s, and other resources included in the ABI , and a pro-

gram compiled into an executable file that has the formats and characteris-

tics specified for su ch files in the ABI , and a program wh ose behavior com-

plies with the rules given in the ABI .

ABI-nonconforming p rogram: A program wh ich has been w ritten to

include system rou tines, comm ands, or other resources not includ ed in th e

ABI , or a p rogram w hich h as been compiled into a format different from

those specified in the ABI , or a program wh ich d oes not behave as specified

in the ABI .

un defined behavior: Behavior that may vary from instance to instance or

may change at some time in the futu re. Some un desirable programm ing

practices are marked in the ABI as yielding und efined behavior.

unspecified property: A property of an entity that is not explicitly included

or referenced in this specification, and may chan ge at some time in the

future. In general, it is not good practice to make a program depen d on an

unspecified property.

1-8 INTRODUCTION



Page: 18



NOTE

Diffmarkings have been retained in the text of this book to indicate in whichrevisions of System V certain modifications were made to the ABI .

A "" character in the right hand margin indicates a corrective change in the ABI made just after the Release 4 ABI was published.

An "E" character in the right hand margin indicates a change in the ABI madein UNIX System V Release 4.1.

A "G" character in the right hand margin indicates a change in the ABI madein UNIX System V Release 4.2.

A "M" character in the right hand margin indicates a change in the ABI made Xin UnixWare® 2.0. A "X" character in the right hand margin indicates achange in the ABI made to merge in XPG4.2 source API requirements.




Page: 19



2 SOFTWARE INSTALLATION

Software Installation and Packaging 2-1

Installation Media 2-1

Physical Distribution Media and Formats 2-1

Media Format 2-1

Software Structure of the Physical Media 2-2

File Formats 2-7

pkginfo File 2-7

The pkgmap File 2-9

The copyright File 2-10

The space File 2-10

The depend File 2-11

The compver File 2-11

Installation and Removal Scripts 2-11


Commands That Install, Remove andAccess Packages 2-16

Table of Contents i


386:adm.book:sum

Page: 20



Software Structure of the Physical Media

Add -on app lication software is bu nd led and installed in un its called p ackages.

Multiple packages can be delivered on a single volum e of med ia or a package can

span m ultiple volumes of media. A package that spans mu ltiple volumes of

med ia must be the only package in the distribution. cpio always pad s headers to E

a 512 byte bounda ry, and archives to an integral block size, set by the -C or -B E

option . Each archive on the med ia is extended to the block size specified by nu ll E

padding.

Software to be bun dled as a package mu st be organized as a file tree subd irectory

as shown in Figure 2-1. The data stream from the d istribution m edia is read onto

disk into a file subtree of this form at before the actua l installation begins. Figure

2-2 show s the sequence of files in the d ata stream stored on d istribution med ia.

Figure 2-1: Package File Tree Organization

/

pkginfo pkgmap

copyright 0 or morescripts

compver depend space

packageobjects

reloc root

packageobjects

install

pkg

.

.

.

2-2 SOFTWARE INSTALLATION



Page: 22



The following is a brief description of files and directories shown in Figure 2-1.

Entries in constant width type are standard file or directory names; the names

of the other items a re package-specific.

The following files are requ ired:

pkginfo: describes the p ackage.

pkgmap: describes each package object (files, directories, and so on).

The following files and directories are optional:

compver: describes previous versions of the package with w hich this ver-

sion is backward compatible.

copyright: copyr ight no tice for the package.

depend: describes depen dencies and incompatibilities across packages.

install: contains optiona l package information files.

package objects: executab les, da ta files, and so on , belonging to the p ackage.

reloc: contains relocatable package objects (files whose path nam es on the

target system are determined at the time of installation rather than at the

time of package creation).

root: contains non-relocatable package objects.

space: describes space requiremen ts beyond package objects.

scripts: zero or m ore scripts to han dle p ackage-specific installation and

removal requirements.




Page: 23



Figure 2-2: Data Stream File Layout for Distribution Media

package part

(cpio archive):

.

.

.

.

.

.

.

.

.

pkgB/ pkgmap

pkgB/ pkginfo

pkgA/ pkgmap

pkgA/ pkginfo

pkgA/ root.1/ *

pkgA/ install/ *pkgA/ pkginfo

pkgA/ reloc.1/ *

pkgB/ reloc.1/ *pkgB/ root.1/ *

pkgB/ install/ *

pkgB/ pkginfo

pkgA/ pkginfo

pkgA/ root.2/ *

pkgA/ reloc.2/ *

# end of header

.

.

.

pkgB num _parts max _part _size [N ... N]pkgA num _parts max _part _size [N ... N]

# PaCkAgE DaTaStReAm[: type]header:

special information

files (cpio archive):

package part(cpio archive):

package part

(cpio archive):




Page: 24



The da ta stream format begins with a head er containing a series of new -line ter- E

minated ASCII character strings. A special character string on the first line

identifies the start of the head er. It shou ld be in the following format:

# PaCkAgE DaTaStReAm[: type]

When no type is defined, the data stream is continuous. Add itional types of datastreams may be specified in a processor-specific ABI sup plemen t. Such add itional

types would deal with media-specific physical storage attributes, for example,

record size, blocking factors, or alignmen t of package par ts on the m edia.

Next are one or m ore special lines, one for each package in the distribution. Each

line has the following format:

pkginstance num _ parts max _ part _size [N . . . N]

where:

pkginstance is the package identifier mad e up of the package abbreviation

(described later as the PKG param eter in the pkginfo file) and an optional

suffix.

num _ parts is the nu mber of parts into wh ich the package is divided. As

show n in Figu re 2-2, a pa rt is a collection of files contained in a cpio

archive. A part is the atomic un it by wh ich a package is processed. Each

part m ust fit entirely on a d istribution m edia volume, that is, a part cannot

cross volum es. A developer chooses the criteria for grouping files into a

part.

max _ part _size is the maximum nu mber of 512-byte blocks consum ed by a

single part of the package.

N . . . N are optional fields to ind icate the num ber of parts stored on the

sequen tial volum es of med ia wh ich contain the package. For example,

pkgA 6 2048 2 3 1indicates that pkgA consists of six pa rts. The largest p art is 2048 512-byte

blocks in size. The first two parts exist on the first volum e, the next three

parts exist on th e second volume, and the last part exists on the third, an d

last, volum e. These fields only app ly where mu ltiple volumes are needed to

distribute a package. Otherwise, these fields should not appear and any

process reading the h eader should assume that all parts of the package

reside on the current volum e. When these fields are used , there can only be

one package in the data stream.




Page: 25



A special new -line terminated character string on a separate line identifies the end E

of the header. It shou ld be in the following format:

# end of header

The header mu st be padd ed to a 512-byte bound ary.

Following the head er is a cpio archive containing sp ecial information files for

each package. The rest of the data stream consists of package par ts. Note that a

given package may consist of one or mor e parts, that is, cpio archives. A pack-

ages wh ich requ ires multiple parts mu st meet the following conditions:

Each p art mu st contain the entire pkginfo file.

Each part includes its own root an d reloc directories and th ese directories

are num bered. For example, a package that requires n parts has root.1 an d

reloc.1 through root.n and reloc.n. n is limited to eight d igits.

The install directory and its contents are only provided in the first part.




Page: 26



File Formats

pkginfo File

The pkginfo file describes the package, as a whole. Each line is of the form

parameter=value. The list below describes defin ed param eters. These par ameters

can be retrieved via pkginfo(AS _CMD) and/ or have a specific meaning to the

package installation and removal command s (pkgadd(AS _CMD) and

pkgrm(AS _CMD)). No specific ordering of par ameters is requ ired. Lines begin-

ning with # are treated as comments.

PKG: Package abbreviation, limited to 9 characters. The first character must

be alphabetic; remaining characters can be alphabetic, nu meric, or the char-

acters + and -. install, new, and all are not valid package abbreviations.

NAME: Package name, limited to 256 ASCII characters.

ARCH: A comm a-separated list of identifiers that sp ecify the architecture(s)on which the package can run. Each architecture identifier is limited to 16

ASCII characters; the character ’,’ is invalid.

VERSION: Version iden tifier, limited to 256 ASCII characters. The first char -

acter can not be a left paren thesis du e to the syntax of the depend file. This

identifier is vendor-specific information.

DESC: Descriptive text, limited to 256 ASCII characters.

VENDOR: Vend or identifier, limited to 256 ASCII characters.

HOTLINE: Phone nu mber or m ailing add ress where further information may

be requested or bu gs reported . The value of this param eter is limited to 256

ASCII characters.

EMAIL: An electronic mail add ress, with th e same p urp ose and length limita-

tion as the HOTLINE parameter.

VSTOCK: Vend or stock nu mber, limited to 256 ASCII characters.

CATEGORY: A comm a-separated list of categories to wh ich the p ackage

belongs. Add -on software p ackages must state their membership in the

application category. Users can requ est informa tion on all packages in

specific categories via pkginfo(AS _CMD). Category identifiers are case-

insensitive and are limited to 16 alphanu meric characters, exclud ing the

space and comma characters.

File Formats 2-7



Page: 27



PSTAMP: Produ ction stam p, limited to 256 ASCII characters.

ISTATES: Space-separated list of valid ru n-levels du ring w hich this package

can be installed. Run-levels are integers in the range 0 throu gh 6, s an d S

[see System V Interface Definition, Fourth Edition, init(AS _CMD)].

RSTATES: Same as ISTATES, but ap plies to package removal.

ULIMIT: Tempor ary file size limit to use during installation of this package

[see getrlimit].

INTONLY: A pa ram eter that ind icates a package can on ly be installed interac-

tively by the pkgadd(AS _CMD) command . If this parameter is supp lied and

set to any non-null value (for example, y or yes), the package can only be

installed interactively. Otherw ise, the package can be installed in a nonin-

teractive mode using pkgask(AS _CMD) or pkgadd with the -n option.

MAXINST: An integer tha t specifies the maximum nu mber of instances of this

package that can be installed on a system at one time. If this param eter is

not su pp lied, a d efault of 1 is used (at most one copy of the package can be

installed on a system at any time).

BASEDIR: The p athn ame to a d efault d irectory w here ‘‘relocatable’’ files may be installed. If BASEDIR is blank an d the basedir variable in the admin file is set to ‘‘default,’’ the package is not cons ider ed relocatable. In this case, if files have relative pathn ames, package installation will fail. An ad ministra- tor can override BASEDIR by setting the basedir variable in the admin file.

CLASSES: A space-separated list of package object classes to be installed.

Every package object is assigned to one class (in th e pkgmap file). Class

assignment can be used to control (for example, based on administrator

inpu t at the time of installation) wh ich objects are installed an d to p rovide

specific actions to be taken to install or remove them. The value of this

parameter can be overridden at the time of installation.

PKG, NAME, ARCH, VERSION, CATEGORY an d BASEDIR are mand atory param eters, E

that is, package developers mu st supp ly them. The rest are optional.

Other param eters may be defined in the pkginfo file. If they are used as part of

package object pathnames in the pkgmap file, the value sup plied in the pkginfo

file is used as a d efault and may be overridd en at the time of

installation. Other param eters will be made p art of the environment in w hich ins-

tallation scripts execute.




Page: 28



The pkgmap File

Each line in th e pkgmap file describes a p ackage object or installation script (with

the exception of one pkgmap entry, described at the end of this section). The fol-

lowing list describes the space-separated fields in each pkgmap entry; their order

mu st be the same as in the list. Lines in the file that begin with # are ignored. part : A positive integer that ind icates the pa rt of a mu lti-par t package in

wh ich this pathn ame resides.

ftype: A one-character file type iden tifier from the set below:

f a file

d a directory

i an installation or removal script

l a linked file

s a sym bolic link

p a named pipe

b a block sp ecial d evice

c a character special device

e a file installed or removed by editing

v a volatile file, whose contents ar e expected to change as the

package is used on the system

x an exclusive directory, which shou ld contain on ly files installed

as part of this or some other standard format p ackage

class: A package object class identifier, limited to 12 characters. none is used

to specify no class mem bership. This field is not specified for files whose ftype is i.

pathname: The path nam e describing the location of the file on the target

machine. For files of ftype, l or s, pathnamemu st be of the form path1=path2,

specifying the d estination ( path1) and source ( path2) files to be linked. Spe-

cial characters, such as an equa l sign (=), are included in pathn ames by sur-

round ing the entire path name in single quotes (as in, for examp le,

’/usr/lib/˜=’).

The pathname may contain variables which supp ort relocation of the file. A

$ parameter may be embedded in the pathn ame structure. $BASEDIR can be

used to identify the p arent d irectories of the path hierarchy, making the

entire package easily relocatable. Default values for parameter and BASEDIR

mu st be supp lied in the pkginfo file and m ay be overridd en at installation.

File Formats 2-9



Page: 29



major : The major device num ber, app licable to files wh ose ftype is b or c.

minor : The minor d evice nu mber, ap plicable to files whose ftype is b or c.

mode: The octal mod e of the file. ? indicates that no particular mode is

required. This field is not provided for files whose ftype is l, s or i.

owner : The uid of the owner of the file; it mu st be a legal uid . ? indicates that

no p articular own er is required. This field is not provided for files whose

ftype is l, s or i.

group: The grou p to wh ich the file belongs, limited to 14 characters. ? indi-

cates that no par ticular group is required. This field is not prov ided for files

whose ftype is l, s or i.

size: The file size in bytes. This field is not p rovided for files wh ose ftype is d,

x, p, b, c, s or l.

cksum: The checksum of the file contents, as calculated by sum. This field is

not provided for files wh ose ftype is d, x, p, b, c, s or l.

modtime: The time of last mod ification as rep orted by the function stat.This field is not p rovided for files whose ftype is d, x, p, b, c or l.

An ad ditional line in the pkgmap file, beginning w ith a colon, provides inform a-

tion about the med ia on wh ich the p ackage is distributed. Its format is:

:number _of _ parts maximum _ part _size

number _of _ parts specifies the nu mber of p arts wh ich comp ose this package.

maximum _ part _size specifies the size, in 512-byte blocks, of the largest part.

The copyright File

The contents of the copyright file will be displayed on stdout at the time of instal-

lation; there are no format requirements.

The space File

The space file describes disk block and inode requirements for the package

beyond files listed in the pkgmap file and p rovided on the med ia. Each line in the

file contains the following three space-separated fields:

pathname: A directory name. Naming conventions (with respect to ind icat-

ing relocatability) are the same as for th e pathnamefield in the pkgmap file.

blocks: The num ber of 512-byte blocks required .




Page: 30



inodes: The number of d istinct files required.

The depend File

The depend file describes depen den cies across packages. The forma t of each entry

is as follows:

type pkg name

(arch)version

The following field d efinitions and rules app ly:

type: Describes the typ e of depend ency:

P a p rerequ isite for installation

I an incomp atibility

R reverse depend ency (the referenced package depend s on this p ack-

age)

pkg: The package abbreviation, as defined in the pkginfo file.

name: The p ackage name, as defined in the pkginfo file.

arch: The package architecture, as defined in th e pkginfo file.

version: The package version, as defined in the pkginfo file.

There may be zero or more (arch)version lines.

(arch)version lines mu st begin w ith wh ite space.

The compver File

The compver file specifies previous versions of the package with which this ver-sion is backward comp atible. It is used for depend ency checking across packages,

in conjun ction w ith the depend file. It consists of version identifiers, as defined in

the pkginfo file, one per line.

Installation and Removal Scripts

This section describes installation and removal scripts that m ay be prov ided by a

package to meet package-specific needs. Scripts are executed by the comman d sh

and therefore must be either shell scripts or executab le program s. In the case of

recovery from an interrupted installation they may be re-executed; they should be

written so that mu ltiple invocations prod uce the same results as a single invoca-

tion.

File Formats 2-11



Page: 31



NOTE

Since substantive differences exist between the shell traditionally provided by XSystem V systems and the new X/Open CAE Specification, Issue 4.2 shell, and Xsince many shell scripts are liable to be affected by these differences, it is Xrecommended that installation scripts and any other shell scripts that have Xstringent compatibility requirements continue to use the traditional System V X

shell. New shell scripts may wish to take advantage of the capabilities of the X/Open CAE Specification, Issue 4.2 shell.

The request Script

The request script, if provided, is the first script executed at the time of package

installation. Its pu rpose is to interact with the user and mod ify details of the ins-

tallation p rocess as a result of this interaction. The script w rites shell variable

assignmen ts to the file nam ed by its only argum ent. It is executed w ith uid root E

an d gid sys. stdin, stdout an d stderr are all attached to the controlling termi- E

nal. The following variables are defined as part of the installation procedur e and

may be set by the request script:

CLASSES: As defined in the pkginfo file.

Procedure Scripts

Four scripts m ay be p rovided by a package to han dle p ackage-specific require-

ments - preinstall, postinstall, preremove an d postremove.

The following constraints apply to these procedure scripts:

When th e script is executed , stdin is attached to the controlling termina l; M

stdout an d stderr are attached to the controlling termina l.

Each p athname created or m odified by a p rocedu re script du ring installa-

tion or removal, and wh ich shou ld be considered part of the package, must

be logically add ed or removed from the p ackage via the

installf(AS _CMD) or removef(AS _CMD) comman ds.

Procedure scripts are executed with uid root and gid sys. M

Class Scripts

Class scripts provide non -standa rd installation and removal actions for classes of

package objects (the m embersh ip of objects in a class is specified in th e pkgmap

file). The following constraints apply:

Each class includ ed in th e value of the CLASSES par ameter is installed, in the

ord er in wh ich they app ear in that param eter. Objects in class none are

installed first.




Page: 32



If an object belongs to class none or no class script is p rovided for the class,

the object is copied from the med ium to the target system du ring installa-

tion, and removed du ring removal.

Class script names ar e of the form operation.class, where operation is either i

(for install) or r (for rem ove), and class is the class name, limited to 12 char-acters. Class nam es beginning with 0 are reserved.

Class scripts w ill execute as uid root an d gid sys. M

During installation, the script is executed with either no arguments or the

single argum ent ENDOFCLASS. stdin contains a list of filename p airs, of the

form source _ pathname destination _ pathname. The source _ pathname parameter

is either a pathnam e on the medium or /dev/null to ind icate there is no fi le

to copy from the med ium (for example, a directory). destination _ pathname is

the target pathnam e. Only files that are members of the class and are not

identical to files already on the system are prov ided to the script.

The script is invoked with the single argum ent ENDOFCLASS to indicate that

there are no more files belonging to the class once end of file is reached on

stdin du ring the current invocation of the script.

During rem oval, the script is executed with n o argum ents. stdin contains a

list of filenames, includ ing all members of the class except th ose shared by

other installed packages wh ose ftype in the pkgmap file is something oth er

than e.

Two standard classes are defined: build and sed. The name of the file on the med ium is the nam e of the file on the target system to be modified.

For the sed class, the file provided on the m edium contains the comman d sed instructions. Lines of the format !install an d !removemark the

beginning of instructions which apply to installation and removal, respectively. The file on the target system will be mod ified by the output of sed, using the provided d ata.

A file that belongs to the build class is executed with a single argument,

install or remove. Its output (on stdout) is written to the file it references

on the target system.

Exit Codes Used by Scripts

Scripts shall exit with an additive combination of one of the first four and one of E

the last two exit codes listed below :

0: successful execution

File Formats 2-13



Page: 33



1: fatal error

2: warning

3: interruption

10: reboot after installation of all packages

20: reboot after installation of this package

For example, the exit code for a script resulting in a warn ing condition and that

requires an imm ediate reboot is 22.




Page: 34



File Tree for Add-on Software

/opt, /var/opt and /etc/opt are reserved in the file tree for the installation of

app lication software packages. Each ad d-on software p ackage should adh ere to

the following ru les:

Static package ob jects should be installed in /opt/ pkg, where pkg is the

package abbreviation or instance.

Package objects that change in norm al operations (for examp le, log and

spool files) shou ld be installed in /var/opt/ pkg.

Machine-specific configura tion files should be installed in /etc/opt/ pkg.

Executables that are d irectly invoked by users should be installed in

/opt/ pkg / bin.

Only p ackage objects that mu st reside in specific locations w ithin the system

file tree in order to function p roper ly (for examp le, special files in /dev)shou ld be installed in those locations.




Page: 35



Commands That Install, Remove and AccessPackages

The following comman ds an d library routines are used to install and remove

packages and to retrieve information abou t installed packages. They will be

included in every ABI-conforming system, and are defined in the System V In ter-

face Definition, Fourth Edition.

pkgadd(AS _CMD): installs packages

pkgrm(AS _CMD): remov es packages

pkgchk(AS _CMD): checks installed packages

pkginfo(AS _CMD): disp lay information abou t packages

pkgask(AS _CMD): runs the request script and stores outpu t for later use

installf(AS _CMD): associates an installed file with a package

removef(AS _CMD): remov es a file’s association with a package

pkgparam(AS _CMD): display the values of param eters defined by the package

in the pkginfo file




Page: 36



3 LOW-LEVEL SYSTEMINFORMATION

Introduction 3-1

Character Representations 3-2

Machine Interface (Processor-Specific) 3-3

Function Calling Sequence (Processor-Specific) 3-4


Coding Examples (Processor-Specific) 3-6

Table of Contents i


386:adm.book:sum

Page: 37



Introduction

This chap ter defin es low-level system information, mu ch of which is processor-

specific. It gives the constraints imposed by the system on app lication progr ams,

and it describes how app lication programs use operating system services. AN SI C

serves as the ABI reference prog ram ming langu age. By defining the implemen ta-

tion of C data typ es, the ABI can give p recise system interface information w ithout

resorting to assembly langu age. Giving C langu age bindings for system services

does not preclud e bind ings for other programm ing languages. Moreover, the

examp les given here are not intended to specify the C language available on the

processor.

NOTE

According to ANSI C, a bit-field may have type int, unsigned int, orsigned int. The C language used in this ABI allows bit-fields of type char,short, int, and long (plus their signed and unsigned variants), and oftype enum.

This chapter’s major sections d iscuss th e following top ics.

Character representations. This section d efines the stand ard cha racter set used

for external files that should be portable among systems.

Machine int erface. This section d escribes the processor architecture available

to programs. It also defin es the reference langu age data types, giving the

found ation for system interface specifications.

Function calling sequence. The standard function calling sequence accommo-

da tes the operating system interface, includ ing system calls, signals, and

stack man agement.

Operating system interface. This section describes the op erating system

mechanisms that are visible to application programs (such as signals, pro-

cess initialization, and so on).

Coding examples. Finally, some C code fragments show how program ming

languages may implement some fund amental operations un der the ABI

specifications. These examp les are not intended to give the only imp lemen-

tations, the op timal implementations, nor requirements for implementa-

tions.

Introduction 3-1



Page: 38



Character Representations

Several external file forma ts represen t control information w ith characters (see

‘‘Archive File’’ in Chap ter 7, for examp le). These single-byte characters u se the 7-

bit ASCII character set. In other words, when th e ABI mentions character con-

stants, such as ’/’ or ’\n’, their numerical values shou ld follow the 7-bit ASCII

gu idelines. For the previou s character constants, the single-byte values wou ld be

47 and 10, respectively.

Char acter values outside the ran ge of 0 to 127 may occup y one or mor e bytes,

according to the character encoding. Applications can control their own character

sets, using different character set extensions for different langu ages as app rop ri-

ate. Although ABI-conformance does not restrict the character sets, they generally

should follow some simple guidelines.

Character values between 0 and 127 shou ld correspond to the 7-bit ASCII

code. That is, character sets with encodings above 127 shou ld include the7-bit ASCII code as a subset.

Multibyte character encodings with values above 127 shou ld contain only

bytes with values ou tside the ran ge of 0 to 127. That is, a character set that

uses mor e than one byte per character should not ‘‘embed ’’ a byte resem-

bling a 7-bit ASCII character w ithin a mu ltibyte, non-ASCII character.

Multibyte characters should be self-identifying. That allows, for examp le,

any multibyte character to be inserted between any pair of multibyte charac-

ters, without changing the characters’ interpretations.

These cau tions are particularly relevant for multilingu al app lications.

3-2 LOW-LEVEL SYSTEM INFORMATION



Page: 39



Machine Interface (Processor-Specific)

NOTE This section requires processor-specific information. The ABI supplement forthe desired processor describes the details.

Machine Interface (Processor-Specific) 3-3



Page: 40



Function Calling Sequence (Processor-Specific)

NOTE

This section requires processor-specific information. The ABI supplement forthe desired processor describes the details.




Page: 41



Operating System Interface (Processor-Specific)

NOTE





Page: 42



Coding Examples (Processor-Specific)





Page: 43



4 OBJECT FILES

Introduction 4-1

File Format 4-1

Data Representation 4-3

ELF Header 4-4

ELF Identification 4-7

Machine Information (Processor-Specific) 4-9

Sections 4-10

Special Sections 4-17

String Table 4-21

Symbol Table 4-22Symbol Values 4-26

Relocation 4-27

Relocation Types (Processor-Specific) 4-28

Table of Contents i


386:adm.book:sum

Page: 44



Introduction

This chapter describes the ob ject file format, called ELF (Executab le and Linking

Format). There are three main typ es of object files.

A relocatable file holds code and d ata suitable for linking with other object

files to create an executable or a shared object file.

An executable file holds a p rogram suitable for execution; the file specifies

how the function exec creates a program ’s process image. X

A shared object file holds code an d data suitable for linking in tw o contexts.

First, the link ed itor [see ld(SD _CMD)] may pr ocess it with other r elocat-

able and shared object files to create another object file. Second, the

dynam ic linker combines it with an executable file and other shared ob jects

to create a process image.

Created by th e assembler and link ed itor, object files are binary represen tations of program s intend ed to execute directly on a p rocessor. Programs that require

other abstr act machines, such as shell scripts, are excluded .

After the introdu ctory material, this chapter focuses on the file form at and how it

perta ins to bu ilding progr ams. Chap ter 5 also describes parts of the object file,

concentrating on the information necessary to execute a program.

File Format

Object files participate in program linking (building a program) and program exe-

cution (runn ing a prog ram ). For conven ience and efficiency, the object file form at

provides p arallel views of a file’s contents, reflecting th e differing n eeds of these

activities. Figur e 4-1 shows an object file’s organ ization.

Introduction 4-1



Page: 45



Figure 4-1: Object File Format

Linking View Execution View _ _____________________ _ ______________________ELF head er ELF head er _ _____________________ _ ______________________

Program header table Program header tableoptional _ _____________________ _ ______________________

Section 1 _ _____________________. . . Segment 1

_ _____________________ _ ______________________Section n _ _____________________

. . . Segment 2 _ _____________________ _ ______________________

. . . . . . _ _____________________ _ ______________________

Section head er table Section head er table

optional _ _____________________ _ ______________________

An ELF header resides at the beginn ing and holds a ‘‘road map ’’ describing thefile’s or ganization. Sections hold the bu lk of object file informa tion for the linking

view: instructions, data, symbol table, relocation information, and so on. Descrip-

tions of special sections appear later in the chapt er. Chap ter 5 discusses segments

and the program execution view of the file.

A program header table, if pr esent, tells the system h ow to create a pr ocess image.

Files used to bu ild a pr ocess image (execute a program ) must h ave a p rogram

head er table; relocatable files do not need one. A section header table contains infor-

mation d escribing the file’s sections. Every section ha s an entry in th e table; each

entry gives information such as the section nam e, the section size, and so on. Files

used du ring linking mu st have a section head er table; other object files may or

may not have one.

NOTE

Although the figure shows the program header table immediately after theELF header, and the section header table following the sections, actual filesmay differ. Moreover, sections and segments have no specified order. Onlythe ELF header has a fixed position in the file.

4-2 OBJECT FILES



Page: 46



Data Representation

As d escribed here, the object file format supports various processors with 8-bit

bytes and 32-bit architectures. Nevertheless, it is intend ed to be extensible to

larger (or smaller) architectures. Object files therefore represent som e control data

with a machine-indep end ent format, making it possible to iden tify object files and

interpret their contents in a common way. Remaining d ata in an object file use the

encoding of the target pr ocessor, regard less of the machine on which the file was

created.

Figure 4-2: 32-Bit Data Types

Nam e Size Alignment Purp ose _ ____________________________________________________________Elf32 _Addr 4 4 Unsigned program add ress

Elf32 _Half 2 2 Unsigned med ium integer

Elf32 _Off 4 4 Unsigned file offset

Elf32 _Sword 4 4 Signed large integer

Elf32 _Word 4 4 Unsigned large integer

unsigned char 1 1 Unsigned small integer _ ____________________________________________________________

All data structu res that the object file format d efines follow the ‘‘natu ral’’ size and

alignmen t guidelines for the relevant class. If necessary, data structures contain

explicit pad ding to ensu re 4-byte alignm ent for 4-byte objects, to force structu re

sizes to a mu ltiple of 4, and so on. Data also have suitable alignm ent from the

beginning of the file. Thus, for examp le, a structur e containing an Elf32 _Addr

member w ill be aligned on a 4-byte bound ary w ithin the file.

For por tability reasons, ELF uses no bit-fields.

Introduction 4-3



Page: 47



ELF Header

Some object file control structur es can grow , because the ELF head er contains their

actual sizes. If the object file form at changes, a program m ay encoun ter control

structures that are larger or smaller than expected. Programs might therefore

ignore ‘‘extra’’ information . The treatm ent of ‘‘missing’’ information dep end s on

context and will be specified wh en and if extensions are defined.

Figure 4-3: ELF Header

#define EI _NIDENT 16

typedef struct {

unsigned char e _ident[EI _NIDENT];

Elf32 _Half e _type;

Elf32 _Half e _machine;Elf32 _Word e _version;

Elf32 _Addr e _entry;

Elf32 _Off e _phoff;

Elf32 _Off e _shoff;

Elf32 _Word e _flags;

Elf32 _Half e _ehsize;

Elf32 _Half e _phentsize;

Elf32 _Half e _phnum;

Elf32 _Half e _shentsize;

Elf32 _Half e _shnum;

Elf32 _Half e _shstrndx;

} Elf32 _Ehdr;

e _ident The initial bytes mark th e file as an object file and pr ovide

machine-independ ent data with w hich to decode and interpret

the file’s contents. Comp lete descriptions app ear below, in ‘‘ELF

Identification.’’

4-4 OBJECT FILES



Page: 48



e _type This member identifies the object file type.

Nam e Value Meaning _ ______________________________________ET _NONE 0 No file type

ET _REL 1 Relocatable file

ET _EXEC 2 Executable fileET _DYN 3 Shared object file

ET _CORE 4 Core file

ET _LOPROC 0xff00 Processor-specific

ET _HIPROC 0xffff Processor-specific _ ______________________________________

Although the core file contents are unspecified, type ET _CORE is

reserved to mar k the file. Values from ET _LOPROC through

ET _HIPROC (inclusive) are reserved for processor-specific seman-

tics. If mean ings are specified, the processor sup plemen t explains

them. Other values are reserved and will be assigned to new

object file types as necessary.

e _machine This member’s value specifies the requ ired architecture for an

individual file.

Nam e Value Meaning _ _________________________________________________EM _NONE 0 No machine

EM _M32 1 AT&T WE 32100

EM _SPARC 2 SPARC

EM _386 3 Intel 80386

EM _68K 4 Motorola 68000

EM _88K 5 Motorola 88000

EM _860 7 Intel 80860

EM _MIPS 8 MIPS RS3000 Big-Endian E

EM _MIPS _RS4 _BE 10 MIPS RS4000 Big-Endian E

RESERVED 11-16 Reserved for futur e use E

_ _________________________________________________

Other values are reserved an d w ill be assigned to new machines

as necessary. Processor-specific ELF names use the machine name

to distinguish them. For example, the flags mentioned below use

the prefix EF _; a flag nam ed WIDGET for the EM _XYZ machine

would be called EF _XYZ _WIDGET.

e _version This member identifies the object file version.

ELF Header 4-5



Page: 49



Name Value Meaning _ ____________________________________EV _NONE 0 Invalid version

EV _CURRENT 1 Current version _ ____________________________________

The value 1 signifies the or iginal file format; extensions will create

new versions with higher numbers. The value of EV _CURRENT,though given as 1 above, will change as n ecessary to reflect the

current version nu mber.

e _entry This member gives the virtual ad dress to w hich the system first

transfers control, thu s starting the process. If the file has no asso-

ciated entry point, this member holds zero.

e _phoff This member h olds the p rogram head er table’s file offset in bytes.

If the file has no p rogram h eader table, this member h olds zero.

e _shoff This member h olds the section header table’s file offset in bytes. If

the file has no section head er table, this mem ber holds zero.

e _flags This member h olds pr ocessor-specific flags associated with th e

file. Flag nam es take the form EF _machine _ flag. See ‘‘Machine

Information’’ in the processor sup plemen t for flag definitions.

e _ehsize This member holds the ELF head er’s size in bytes.

e _phentsize This member h olds the size in bytes of one entry in the file’s pro-

gram head er table; all entries are the sam e size.

e _phnum This member h olds the num ber of entries in the p rogram head er

table. Thus the prod uct of e _phentsize an d e _phnum gives the

table’s size in bytes. If a file has no progr am header table,

e _phnum holds the value zero.

e _shentsize This member h olds a section head er’s size in bytes. A section

head er is one entry in the section head er table; all entries are thesame size.

e _shnum This member holds the n um ber of entries in the section header

table. Thus the prod uct of e _shentsize an d e _shnum gives the

section head er table’s size in bytes. If a file has no section header

table, e _shnum holds the value zero.

e _shstrndx This member hold s the section head er table ind ex of the entry

associated w ith the section nam e string table. If the file has no

section nam e string table, this member holds the value

SHN _UNDEF. See ‘‘Section s’’ and ‘‘String Table’’ below for more

information.

4-6 OBJECT FILES



Page: 50



ELF Identification

As mentioned above, ELF provides an object file framework to support multiple

processors, mu ltiple da ta encodings, and mu ltiple classes of machines. To sup por t

this object file family, the initial bytes of the file specify how to interp ret the file,

independ ent of the processor on wh ich the inquiry is made and independ ent of

the file’s remaining contents.

The initial bytes of an ELF head er (and an object file) correspon d to the e _ident

member.

Figure 4-4: e _ident[ ] Identification Indexes

Nam e Value Purp ose _ _________________________________________EI _MAG0 0 File identification

EI _MAG1 1 File identification



EI _CLASS 4 File classEI _DATA 5 Data encoding

EI _VERSION 6 File version

EI _PAD 7 Start of pad ding bytes

EI _NIDENT 16 Size of e _ident[] _ _________________________________________

These indexes access bytes that hold the following values.

EI _MAG0 to EI _MAG3

A file’s first 4 bytes hold a ‘‘mag ic num ber,’’ iden tifying th e file

as an ELF object file.

Name Value Position _ ____________________________________ELFMAG0 0x7f e _ident[EI _MAG0]

ELFMAG1 ’E’ e _ident[EI _MAG1]

ELFMAG2 ’L’ e _ident[EI _MAG2]

ELFMAG3 ’F’ e _ident[EI _MAG3] _ ____________________________________

ELF Header 4-7



Page: 51



EI _CLASS The next byte, e _ident[EI _CLASS], iden tifies the file’s class, or

capacity.

Nam e Value Meaning _ ___________________________________ELFCLASSNONE 0 Invalid class

ELFCLASS32 1 32-bit objectsELFCLASS64 2 64-bit objects _ ___________________________________

The file format is designed to be por table among m achines of

various sizes, withou t imposing the sizes of the largest machine

on the smallest. Class ELFCLASS32 supp orts machines with files

and virtual address spaces up to 4 gigabytes; it uses the basic

types defined above.

Class ELFCLASS64 is reserved for 64-bit architectures. Its appear -

ance here show s how the object file may change, but the 64-bit

format is otherw ise un specified. Other classes will be defined a s

necessary, with d ifferent basic types and sizes for object file data.

EI _DATA Byte e _ident[EI _DATA] specifies the data encoding of thepr ocessor-specific da ta in the object file. The following encodings

are currently defined .

Nam e Value Meaning _ __________________________________________ELFDATANONE 0 Invalid data encoding

ELFDATA2LSB 1 See below

ELFDATA2MSB 2 See below _ __________________________________________

More information on these encodings appears below. Other

values are reserved and will be assigned to new encodings as

necessary.

EI _VERSION Byte e _ident[EI _VERSION] specifies the ELF head er version

num ber. Currently, this value must be EV _CURRENT, as explainedabove for e _version.

EI _PAD This value m arks the beginning of the unu sed bytes in e _ident.

These bytes are reserved and set to zero; programs that read

object files shou ld ignore them. The value of EI _PAD will change

in the future if currently u nused bytes are given m eanings.

A file’s data en coding sp ecifies how to interpr et the basic objects in a file. As

described above, class ELFCLASS32 files use objects that occup y 1, 2, and 4 bytes.

Und er the defined encodings, objects are represented as shown below. Byte

nu mbers app ear in the upp er left corners.

4-8 OBJECT FILES



Page: 52



Encoding ELFDATA2LSB specifies 2’s complement values, with the least significant

byte occupying the lowest ad dress.

Figure 4-5: Data Encoding ELFDATA2LSB

010

0x01

020

011

0x0102

040

031

022

013

0x01020304

Encoding ELFDATA2MSB specifies 2’s complem ent values, with the m ost significant

byte occupying the lowest ad dress.

Figure 4-6: Data Encoding ELFDATA2MSB

010

0x01

010

021

0x0102

010

021

032

043

0x01020304

Machine Information (Processor-Specific)

NOTE


ELF Header 4-9



Page: 53



Sections

An ob ject file’s section head er table lets one locate all the file’s sections. The sec-

tion head er table is an array of Elf32 _Shdr structu res as described below. A sec-

tion head er table ind ex is a subscript into this array. The ELF header’s e _shoff

mem ber gives the byte offset from the beginn ing of the file to the section head er

table; e _shnum tells how m any entr ies the section head er table contains;

e _shentsize gives the size in bytes of each en try.

Some section head er table indexes are reserved ; an object file will not hav e sec-

tions for these special indexes.

Figure 4-7: Special Section Indexes

Name Value _ _______________________SHN _UNDEF 0

SHN _LORESERVE 0xff00SHN _LOPROC 0xff00

SHN _HIPROC 0xff1f

SHN _ABS 0xfff1

SHN _COMMON 0xfff2

SHN _HIRESERVE 0xffff _ _______________________

SHN _UNDEF This value m arks an un defined , missing, irrelevant, or other-

wise mean ingless section reference. For examp le, a symbol

‘‘defin ed’’ relative to section n um ber SHN _UNDEF is an

und efined symbol.

NOTE

Although index 0 is reserved as the undefined value, the section header tablecontains an entry for index 0. That is, if the e _shnum member of the ELFheader says a file has 6 entries in the section header table, they have theindexes 0 through 5. The contents of the initial entry are specified later in thissection.

SHN _LORESERVE This value specifies the lower boun d of the range of reserved

indexes.

SHN _LOPROC through SHN _HIPROC

Values in this inclusive range are reserved for processor-

specific seman tics. If mean ings are specified, the processor

supp lement explains them.

4-10 OBJECT FILES



Page: 54



SHN _ABS This value specifies absolute values for the correspond ing

reference. For example, symbols defined relative to section

number SHN _ABS have absolu te values and are not affected by

relocation.

SHN _COMMON Symbols defined relative to this section are common sym bols,such as FORTRAN COMMON or un allocated C external vari-

ables.

SHN _HIRESERVE This value sp ecifies the u pp er boun d of the range of reserved

indexes. The system reserves ind exes between

SHN _LORESERVE and SHN _HIRESERVE, inclusive; the values d o

not reference the section header table. That is, the section

header table does not contain entries for the reserved indexes.

Sections contain all informa tion in an object file, except th e ELF head er, the p ro-

gram h eader table, and the section head er table. Moreover, object files’ sections

satisfy several cond itions.

Every section in an object file has exactly one section h eader describing it.

Section head ers may exist that do not have a section.

Each section occup ies one contiguous (possibly empty) sequen ce of bytes

with in a file.

Sections in a file may not overlap . No byte in a file resides in more than on e

section.

An object file may have inactive space. The various head ers and the sec-

tions migh t not ‘‘cover’’ every byte in an object file. The contents of the

inactive data are unsp ecified.

A section header has the following structure.

Sections 4-11



Page: 55



Figure 4-8: Section Header

typedef struct {

Elf32 _Word sh _name;Elf32 _Word sh _type;

Elf32 _Word sh _flags;

Elf32 _Addr sh _addr;

Elf32 _Off sh _offset;

Elf32 _Word sh _size;

Elf32 _Word sh _link;

Elf32 _Word sh _info;

Elf32 _Word sh _addralign;

Elf32 _Word sh _entsize;

} Elf32 _Shdr;

sh _name This member specifies the name of the section. Its value is an

index in to the section head er string table section [see ‘‘StringTable’’ below], giving th e location of a null-terminated string.

sh _type This member categorizes the section’s contents and seman tics.

Section types and their descriptions appear below.

sh _flags Sections su pp ort 1-bit flags tha t describe miscellaneous a ttri-

butes. Flag definitions app ear below.

sh _addr If the section w ill app ear in the m emory im age of a process,

this mem ber gives the add ress at which the section’s first byte

shou ld reside. Otherw ise, the member contains 0.

sh _offset This member ’s value gives the byte offset from the beginn ing

of the file to the first byte in the section. One section type,

SHT _NOBITS described below, occupies no space in the file,

and its sh _offset member locates the conceptual placement

in the file.

sh _size This member gives the section’s size in bytes. Unless the sec-

tion type is SHT _NOBITS, the section occupies sh _size bytes

in the file. A section of type SHT _NOBITS may hav e a non-zero

size, but it occup ies no space in the file.

sh _link This member hold s a section header table ind ex link, whose

interpr etation depen ds on the section type. A table below

describes the values.

4-12 OBJECT FILES



Page: 56



sh _info This member holds extra information, whose interpretation

dep end s on the section type. A table below describes the

values.

sh _addralign Some sections have addr ess alignmen t constraints. For exam-

ple, if a section holds a d oubleword, the system m ust ensuredou bleword alignmen t for the entire section. That is, the value

of sh _addr mu st be congruent to 0, mod ulo the value of

sh _addralign. Cur rently, only 0 and p ositive integral pow ers

of two are allowed . Values 0 and 1 mean the section has no

alignment constraints.

sh _entsize Some sections hold a table of fixed-size entries, such as a sym -

bol table. For such a section, this mem ber gives the size in

bytes of each entry. The member contains 0 if the section does

not hold a table of fixed-size entries.

A section head er’s sh _type mem ber sp ecifies the section’s semantics.

Figure 4-9: Section Types, sh _type

Name Value _ ___________________________SHT _NULL 0

SHT _PROGBITS 1

SHT _SYMTAB 2

SHT _STRTAB 3

SHT _RELA 4

SHT _HASH 5

SHT _DYNAMIC 6

SHT _NOTE 7

SHT _NOBITS 8

SHT _REL 9

SHT _SHLIB 10SHT _DYNSYM 11

SHT _LOPROC 0x70000000

SHT _HIPROC 0x7fffffff

SHT _LOUSER 0x80000000

SHT _HIUSER 0xffffffff _ ___________________________

SHT _NULL This value mar ks the section header a s inactive; it does not

have an associated section. Other m embers of the section

header have und efined values.

Sections 4-13



Page: 57



SHT _PROGBITS The section holds information defined by the pr ogram, wh ose

format and m eaning are determined solely by the program.

SHT _SYMTAB an d SHT _DYNSYM

These sections hold a sym bol table. Cur rently, an object file

may h ave only one section of each typ e, but this restrictionmay be relaxed in the future. Typically, SHT _SYMTAB provides

symbols for link editing, thou gh it may also be used for

dynam ic linking. As a comp lete symbol table, it may contain

many symbols unnecessary for dyn amic linking. Conse-

quently, an object file may a lso contain a SHT _DYNSYM section,

wh ich hold s a minimal set of dynam ic linking symbols, to save

space. See ‘‘Symbol Table’’ below for de tails.

SHT _STRTAB The section holds a string table. An object file may h ave mu lti-

ple string table sections. See ‘‘String Table’’ below for details.

SHT _RELA The section holds relocation entries with explicit add end s, such

as type Elf32 _Rela for the 32-bit class of object files. An

object file may have m ultip le relocation sections. See ‘‘Reloca-tion’’ below for details.

SHT _HASH The section holds a sym bol hash table. All objects participating in dyn amic linking must contain a symbol hash table.

Cur rently, an object file may have only one hash table, but this

restr iction may be relaxed in the futu re. See ‘‘Hash Table’’ in

Chap ter 5 for details.

SHT _DYNAMIC The section holds information for dynam ic linking . Cur rently,

an object file may hav e only one dynam ic section, but th is res-

triction m ay be r elaxed in th e futu re. See ‘‘Dynamic Section’’

in Chap ter 5 for details.

SHT _NOTE The section holds informat ion that ma rks the file in some w ay.See ‘‘Note Section’’ in Ch ap ter 5 for d etails.

SHT _NOBITS A section of this type occupies no space in the file bu t other-

wise resembles SHT _PROGBITS. Although this section contains

no bytes, the sh _offset member contains the conceptual file

offset.

SHT _REL The section holds relocation entries without explicit add end s,

such as type Elf32 _Rel for the 32-bit class of object files. An

object file may have m ultip le relocation sections. See ‘‘Reloca-

tion’’ below for details.

4-14 OBJECT FILES



Page: 58



SHT _SHLIB This section type is reserved but has unspecified semantics.

Program s that contain a section of this type do not conform to

the ABI.

SHT _LOPROC through SHT _HIPROC

Values in this inclusive range are reserved for pr ocessor-specific seman tics. If mean ings are specified, the processor


SHT _LOUSER This value specifies the lower bound of the range of indexes

reserved for application program s.

SHT _HIUSER This value sp ecifies the u pp er bound of the range of indexes

reserved for app lication program s. Section types between

SHT _LOUSER an d SHT _HIUSER may be u sed by the ap plication,

without conflicting w ith current or future system-defined sec-

tion types.

Other section type values are reserved . As mentioned before, the section header

for index 0 (SHN _UNDEF) exists, even thou gh the ind ex marks un defined sectionreferences. This entry holds the following.

Figure 4-10: Section Header Table Entry: Index 0

Nam e Value Note _ ___________________________________________________sh _name 0 No name

sh _type SHT _NULL Inactive

sh _flags 0 No flags

sh _addr 0 No add ress

sh _offset 0 No file offset

sh _size 0 No size

sh _link SHN _UNDEF No link information

sh _info 0 No auxiliary informationsh _addralign 0 No alignment

sh _entsize 0 No entries _ ___________________________________________________

A section head er’s sh _flags mem ber hold s 1-bit flags that d escribe the section’s

attributes. Defined values app ear below; other values are reserved.

Sections 4-15



Page: 59



Figure 4-11: Section Attribute Flags, sh _flags

Name Value _ ____________________________SHF _WRITE 0x1

SHF _ALLOC 0x2

SHF _EXECINSTR 0x4

SHF _MASKPROC 0xf0000000 _ ____________________________

If a flag bit is set in sh _flags, the attr ibute is ‘‘on’’ for the section. Oth erw ise, the

attribute is ‘‘off’’ or does no t app ly. Und efined attributes are set to zero.

SHF _WRITE The section contains data th at should be writable during p ro-

cess execution.

SHF _ALLOC The section occup ies mem ory du ring pr ocess execution .

Some control sections do not reside in the mem ory image of

an object file; this attribute is off for those sections.

SHF _EXECINSTR The section contains executable m achine instructions.

SHF _MASKPROC All bits includ ed in th is mask are reserved for processor-

specific seman tics. If mean ings are specified, the processor


Two m embers in the section header, sh _link an d sh _info, hold sp ecial informa-

tion, depend ing on section typ e.

4-16 OBJECT FILES



Page: 60



Figure 4-12: sh _link and sh _info Interpretation

sh _type sh _link sh _info _ ____________________________________________________________________SHT _DYNAMIC 0The section head er index of

the string table used byentries in the section. _ ____________________________________________________________________

SHT _HASH 0The section head er index of

the sym bol table to which

the hash table applies. _ ____________________________________________________________________SHT _REL

SHT _RELA

The section head er index of

the associated symbol table.


the section to which the

relocation ap plies. _ ____________________________________________________________________SHT _SYMTAB

SHT _DYNSYM


the associated string table.

One greater than the sym-

bol table index of the last

local symbol (bind ing

STB _LOCAL). _ ____________________________________________________________________

other SHN _UNDEF 0 _ ____________________________________________________________________

Special Sections

Various sections hold p rogram and control inform ation. Sections in the list below

are used by the system and have the indicated typ es and attributes.

Figure 4-13: Special Sections

Nam e Type Attributes

_ _______________________________________________________.bss SHT _NOBITS SHF _ALLOC + SHF _WRITE

.comment SHT _PROGBITS none

.data SHT _PROGBITS SHF _ALLOC + SHF _WRITE

.data1 SHT _PROGBITS SHF _ALLOC + SHF _WRITE

.debug SHT _PROGBITS none

.dynamic SHT _DYNAMIC see below

.dynstr SHT _STRTAB SHF _ALLOC

.dynsym SHT _DYNSYM SHF _ALLOC

.fini SHT _PROGBITS SHF _ALLOC + SHF _EXECINSTR

.got SHT _PROGBITS see below

Sections 4-17



Page: 61



Figure 4-13: Special Sections (continued )

.hash SHT _HASH SHF _ALLOC

.init SHT _PROGBITS SHF _ALLOC + SHF _EXECINSTR

.interp SHT _PROGBITS see below

.line SHT _PROGBITS none

.note SHT _NOTE none

.plt SHT _PROGBITS see below

.relname SHT _REL see below

.relaname SHT _RELA see below

.rodata SHT _PROGBITS SHF _ALLOC

.rodata1 SHT _PROGBITS SHF _ALLOC

.shstrtab SHT _STRTAB none

.strtab SHT _STRTAB see below

.symtab SHT _SYMTAB see below

.text SHT _PROGBITS SHF _ALLOC + SHF _EXECINSTR _ _______________________________________________________

.bss This section hold s unin itialized data that contribu te to the

pr ogram ’s memory image. By definition, the system initializes the

data w ith zeros wh en the program begins to run. The section occu-

pies no file space, as ind icated by the section typ e, SHT _NOBITS.

.comment This section holds version control information.

.data an d .data1

These sections hold initialized d ata that contribu te to the program’s

memory image.

.debug This section holds informa tion for symbolic debu gging. The con-

tents are unspecified. All section names w ith the prefix .debug are E

reserved for futu re use in the ABI.

.dynamic This section holds d ynam ic linking information. The section’s attributes will include the SHF _ALLOC bit. Whether the SHF _WRITE bit is set is pr ocessor specific. See Chap ter 5 for more inform ation.

.dynstr This section hold s strings needed for dynamic linking, most com-

monly the strings that rep resent the names associated w ith symbol

table entries. See Chapter 5 for more information .

.dynsym This section hold s the d ynam ic linking sym bol table, as ‘‘Symbol

Table’’ describes. See Chap ter 5 for more informa tion.

4-18 OBJECT FILES



Page: 62



.shstrtab This section hold s section nam es.

.strtab This section hold s strings, most comm only the strings that

repr esent the nam es associated with symbol table entries. If the file

has a loadab le segmen t that includes the sym bol string table, the

section’s attributes will includ e the SHF _ALLOC bit; otherw ise, thatbit w ill be off.

.symtab This section holds a symbol table, as ‘‘Symbol Table’’ in this chapter

describes. If the file has a loadable segment that includes the sym-

bol table, the section’s attributes will includ e the SHF _ALLOC bit;

otherw ise, that bit w ill be off.

.text This section holds the ‘‘text,’’ or executable instructions, of a pro-

gram.

Section names w ith a d ot (.) prefix are reserved for the system, although applica-

tions may u se these sections if their existing mean ings are satisfactory. Applica-

tions may u se names w ithout the p refix to avoid conflicts with system sections.

The object file form at lets one define sections not in the list above. An object filemay h ave more than one section with the same name.

Section names reserved for a processor architecture ar e formed by placing an abbreviation of the architectur e name ahead of the section name. The name should be taken from the architecture nam es used for e _machine. For instance .FOO.psect is the psect section d efined by the FOO architecture. Existing extensions are called by their historical nam es.

Pre-existing Extensions _ _____________________

.sdata .tdesc

.sbss .lit4

.lit8 .reginfo

.gptab .liblist .conflict

NOTE

For information on processor-specific sections, see the ABI supplement forthe desired processor.

4-20 OBJECT FILES



Page: 64



String Table

String tab le sections hold nu ll-termina ted char acter sequences, commonly called

strings. The object file uses these strings to represent symbol and section names.

One references a string as an ind ex into the string table section. The first byte,

which is index zero, is defin ed to hold a nu ll character. Likewise, a string table’s

last byte is defined to hold a n ull character, ensu ring nu ll termina tion for all

strings. A string whose ind ex is zero specifies either no nam e or a nu ll nam e,

dep end ing on the context. An emp ty string table section is permitted; its section

header’s sh _size member w ould contain zero. Non-zero indexes are invalid for

an em pty string table.

A section head er’s sh _name member h olds an ind ex into the section h eader string

table section, as designated by the e _shstrndx mem ber of the ELF head er. The

following figu res show a string table with 25 bytes and the strings associated w ith

various indexes.

Ind ex + 0 + 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 _ _____________________________________________________0 \0 n a m e . \0 V a r _ _____________________________________________________

10 i a b l e \0 a b l e _ _____________________________________________________20 \0 \0 x x \0 _ _____________________________________________________

Figure 4-14: String Table Indexes

Index String _ ________________0 none

1 name.

7 Variable

11 able16 able

24 null string _ ________________

As the examp le show s, a string table index may refer to any byte in the section. A

string may ap pear m ore than on ce; references to substrings m ay exist; and a single

string may be referenced mu ltiple times. Unr eferenced strings also are allowed .

String Table 4-21



Page: 65



Symbol Table

An ob ject file’s symbol table hold s information n eeded to locate and relocate a

pr ogram ’s symbolic defin itions and references. A symbol table ind ex is a sub-

script into this array. Index 0 both designates the first entry in the table and serves

as the und efined sym bol ind ex. The contents of the initial entry are specified later

in th is section.

Name Value _ __________________STN _UNDEF 0 _ __________________

A symbo l table entry ha s the following forma t.

Figure 4-15: Symbol Table Entry

typedef struct {

Elf32 _Word st _name;

Elf32 _Addr st _value;

Elf32 _Word st _size;

unsigned char st _info;

unsigned char st _other;

Elf32 _Half st _shndx;

} Elf32 _Sym;

st _name This member holds an ind ex into the object file’s symbol string

table, which holds the character repr esentations of the symbol

nam es. If the value is non-zero, it represents a string table indexthat gives the symbol name. Otherw ise, the symbol table entry

has no name.

NOTE

External C symbols have the same names in C and object files’ symbol tables.

st _value This mem ber gives the value of the associated sym bol. Depen d-

ing on the context, this may be an absolute value, an ad dress, and

so on; details appear below.

4-22 OBJECT FILES



Page: 66



st _size Many sym bols have associated sizes. For example, a data object’s

size is the number of bytes contained in the object. This member

holds 0 if the symbol has no size or an un know n size.

st _info This member specifies the symbol’s type and binding attributes.

A list of the values and m eanings app ears below. The followingcode shows how to manipu late the values.

#define ELF32 _ST _BIND(i) ((i)>>4)

#define ELF32 _ST _TYPE(i) ((i)&0xf)

#define ELF32 _ST _INFO(b,t) (((b)<<4)+((t)&0xf))

st _other This member currently holds 0 and h as no defined meaning.

st _shndx Every sym bol table entry is ‘‘defin ed’’ in relation to some section;

this member holds the relevant section head er table index. As

Figu re 4-7 and the related text describe, some section indexesindicate special mean ings.

A symbol’s bind ing determ ines the linkage visibility and behavior.

Figure 4-16: Symbol Binding, ELF32 _ST _BIND

Name Value _ ___________________STB _LOCAL 0

STB _GLOBAL 1

STB _WEAK 2

STB _LOPROC 13

STB _HIPROC 15

_ ___________________

STB _LOCAL Local symbols are n ot visible outside the object file containing

their defin ition. Local symbols of the same name m ay exist in

multiple files without interfering with each other.

STB _GLOBAL Global symbols are visible to all object files being combined . One

file’s definition of a global symbo l will satisfy an other file’s

und efined reference to the same global symbol.

Symbol Table 4-23



Page: 67



STB _WEAK Weak symbo ls resemble global symbols, but their definitions

have lower precedence.

STB _LOPROC through STB _HIPROC

Values in this inclusive ran ge are reserved for processor-specific

seman tics. If mean ings are specified, the processor sup plemen texplains them.

Global and weak symbols differ in two major ways.

When the link ed itor combines several relocatable object files, it does n ot

allow mu ltiple d efinitions of STB _GLOBAL symbols with the same name. On

the other han d, if a defined global symbol exists, the ap pearance of a weak

symbol with the same name w ill not cause an error. The link editor honors

the global definition and ign ores the weak ones. Similarly, if a common symbo l exists (that is, a symbol whose st _shnd x field holds SHN _COMMON), the app earance of a weak sym bol with the same nam e will not cause an error. The link editor honors the common definition and ignores the weak ones.

When the link editor searches archive libraries [see ‘‘Archive File’’ in

Chap ter 7], it extracts archive members that contain defin itions of un defin ed

global symbols. The member ’s definition may be either a global or a weak

symbo l. The link editor does not extract archive mem bers to resolve

un defined w eak symbols. Unresolved w eak symbols have a zero value.

In each symbo l table, all symbols with STB _LOCAL binding precede the weak and

global symbols. As ‘‘Sections’’ abov e describes, a sym bol table section’s sh _info

section head er mem ber holds the symbol table ind ex for the first non -local symbo l.

A sym bol’s type p rovides a general classification for the associated entity.

Figure 4-17: Symbol Types, ELF32 _ST _TYPE

Name Value _ ____________________STT _NOTYPE 0

STT _OBJECT 1

STT _FUNC 2

STT _SECTION 3

STT _FILE 4

STT _LOPROC 13

STT _HIPROC 15 _ ____________________

4-24 OBJECT FILES



Page: 68



STT _NOTYPE The symbol’s type is not specified.

STT _OBJECT The symbol is associated with a data object, such as a var iable,

an array, and so on.

STT _FUNC The symbol is associated w ith a function or other executable

code.

STT _SECTION The symbol is associated w ith a section. Symbol table entries of

this type exist prim arily for relocation and norm ally have

STB _LOCAL binding.

STT _FILE Conven tionally, the sym bol’s nam e gives the nam e of the source

file associated w ith the object file. A file symbol has STB _LOCAL

bind ing, its section ind ex is SHN _ABS, and it precedes the other

STB _LOCAL symbols for the file, if it is pr esent.

STT _LOPROC through STT _HIPROC


seman tics. If mean ings are specified, the pr ocessor supp lement

explains them.

Function sym bols (those w ith type STT _FUNC) in shared object files have special

significance. When another object file references a function from a shar ed object,

the link editor au tomatically creates a procedu re linkage table entry for

the referenced sym bol. Shared object symbols with types other than STT _FUNC

will not be referenced automatically through the procedure linkage table.

If a symbol’s value refers to a specific location within a section, its section index

member, st _shndx, holds an ind ex into the section header table. As the section

moves du ring relocation, the symbol’s value changes as well, and references to the

symbol continu e to ‘‘point’’ to the sam e location in the pr ogram . Some sp ecial sec-

tion index values give other seman tics.

SHN _ABS The symbol has an absolute valu e that will not chan ge because of relocation.

SHN _COMMON The symbol labels a comm on block that has n ot yet been allo-

cated. The symbol’s value gives alignm ent constraints, similar to

a section ’s sh _addralign mem ber. That is, the link editor will

allocate the storage for the symbol at an addr ess that is a mu ltiple

of st _value. The symbol’s size tells how m any bytes are

required.

SHN _UNDEF This section table index mean s the symbol is un defin ed. When

the link editor combines this object file with another tha t defines

the ind icated symbol, this file’s references to the sym bol will be

linked to the actual d efinition.

Symbol Table 4-25



Page: 69



As men tioned abov e, the symbol table entry for index 0 (STN _UNDEF) is reserved ; it

holds the following.

Figure 4-18: Symbol Table Entry: Index 0

Nam e Value Note _ ____________________________________________st _name 0 No name

st _value 0 Zero value

st _size 0 No size

st _info 0 No typ e, local bind ing

st _other 0

st _shndx SHN _UNDEF No section _ ____________________________________________

Symbol Values

Symbol table entries for d ifferent object file types have slightly d ifferent interp re-

tations for the st _value member.

In relocatable files, st _value holds alignment constraints for a symbol

whose section ind ex is SHN _COMMON.

In relocatable files, st _value holds a section offset for a defined symbol.

That is, st _value is an offset from the beginning of the section that

st _shndx identifies.

In executab le and shared object files, st _value holds a virtual address. To

make these files’ symbols m ore u seful for the d ynam ic linker, the section

offset (file interp retation) gives way to a virtual ad dr ess (mem ory interp re-

tation) for w hich the section num ber is irrelevant.

Althou gh the symbol table values have similar mean ings for different object files,

the data allow efficient access by the appropriate programs.

4-26 OBJECT FILES



Page: 70



Relocation

Relocation is the p rocess of connecting symbolic references with sym bolic

defin itions. For examp le, when a program calls a function, the associated call

instruction mu st transfer control to the p roper d estination ad dress at execution.

In other words, relocatable files must have information that describes how to

mod ify their section contents, thu s allowing executab le and shared object files to

hold the right information for a process’s program image. Relocation entries are

these data.

Figure 4-19: Relocation Entries

typedef struct {

Elf32 _Addr r _offset;

Elf32 _Word r _info;

} Elf32 _Rel;

typedef struct {

Elf32 _Addr r _offset;

Elf32 _Word r _info;

Elf32 _Sword r _addend;

} Elf32 _Rela;

r _offset This member gives the location at wh ich to ap ply the relocation

action. For a relocatable file, the value is the byte offset from the

beginning o f the section to the storage u nit affected by the relocation.

For an executable file or a shared object, the valu e is the virtual

addr ess of the storage u nit affected by the relocation.

r _info This member gives both the sym bol table index with respect to

which the relocation must be made, and the type of relocation to

app ly. For examp le, a call instru ction’s relocation entry w ould h old

the sym bol table ind ex of the function being called. If the ind ex is

STN _UNDEF, the und efined sym bol ind ex, the relocation uses 0 as the

‘‘sym bol value.’’ Relocation typ es are pr ocessor-specific; descrip-

tions of their behavior appear in the p rocessor supplement. When

the text in the p rocessor supp lement refers to a relocation entr y’s

relocation typ e or symbol table ind ex, it means the resu lt of app lying

ELF32 _R _TYPE or ELF32 _R _SYM, respectively, to the en try’s r _info

member.

Relocation 4-27



Page: 71



#define ELF32 _R _SYM(i) ((i)>>8)

#define ELF32 _R _TYPE(i) ((unsigned char)(i))

#define ELF32 _R _INFO(s,t) (((s)<<8)+(unsigned char)(t))

r _addend This member specifies a constant addend used to comp ute the value

to be stored into th e relocatable field.

As shown above, only Elf32 _Rela entries contain an explicit adden d. Entries of

type Elf32 _Rel store an imp licit add end in the location to be modified. Depend -

ing on the p rocessor architectur e, one form or th e other migh t be necessary or

more convenient. Consequently, an imp lementation for a particular machine may

use one form exclusively or either form dep end ing on context.

A relocation section references two other sections: a symbol table and a section to

mod ify. The section header’s sh _info an d sh _link members, described in ‘‘Sec-

tions’’ above, specify these relationsh ips. Relocation entries for d ifferen t objectfiles have slightly different interp retations for the r _offset member.

In relocatable files, r _offset holds a section offset. That is, the relocation

section itself describes how to m odify anoth er section in the fi le; relocation

offsets designate a storage u nit with in the second section.

In executab le and shared object files, r _offset holds a virtual address. To

make these files’ relocation entr ies more useful for the dynam ic linker, the

section offset (file interpr etation) gives way to a virtu al add ress (memory

interpretation).

Although th e interpretation of r _offset changes for d ifferent object files to allow

efficient access by the relevant p rogram s, the relocation types’ mean ings stay the

same.

Relocation Types (Processor-Specific)

NOTE


4-28 OBJECT FILES



Page: 72



5 PROGRAM LOADING ANDDYNAMIC LINKING

Introduction 5-1

Program Header 5-2

Base Address 5-5

Segment Permissions 5-5

Segment Contents 5-7

Note Section 5-8



Program Interpreter 5-12

Dynamic Linker 5-13

Dynamic Section 5-14

Shared Object Dependencies 5-19

Global Offset Table (Processor-Specific) 5-21Procedure Linkage Table (Processor-Specific) 5-21

Hash Table 5-21

Initialization and Termination Functions 5-22

Table of Contents i


386:adm.book:sum

Page: 73



Introduction

This chap ter describes the object file information and system actions that create

running program s. Some information here app lies to all systems; information

specific to one p rocessor resides in sections marked accord ingly.

Executable and shared object files statically represen t progr ams. To execute such

program s, the system u ses the files to create dynamic program representations, or

process images. As section ‘‘Virtual Add ress Space’’ in Chap ter 3 of the processor

sup plemen t describes, a process image has segments that hold its text, da ta, stack,

and so on. This chap ter’s major sections d iscuss the following.

Program header. This section comp lements Ch apter 4, describing object file

structu res that relate directly to program execution. The primary data

structure, a program header table, locates segment images within the file

and contains other information necessary to create the memory image for

the program.Program loading. Given an object file, the system m ust load it into memor y

for the program to run.

Dynamic linking. After the system loads the program , it must complete the

process image by resolving sym bolic references among th e object files that

compose the process.

NOTE The processor supplement defines a naming convention for ELF constants that have processor ranges specified. Names such as DT _, PT _, for processor specific extensions, incorporate the name of the processor: DT _M32 _SPECIAL, for example. Pre–existing processor extensions not using this convention will be supported.

Pre-existing Extensions _ ____________________

DT _JMP _REL

Introduction 5-1



Page: 74



Program Header

An executable or shared object file’s prog ram head er table is an arr ay of struc-

tures, each d escribing a segment or other information the system needs to p repare

the prog ram for execution. An object file segment contains one or more sections, as

‘‘Segmen t Contents’’ describes below. Program head ers are meaningful only for

executab le and shared object files. A file specifies its own program h eader size

with the ELF header’s e _phentsize an d e _phnum mem bers [see ‘‘ELF Head er’’ in

Chapter 4].

Figure 5-1: Program Header

typedef struct {

Elf32 _Word p _type;

Elf32 _Off p _offset;

Elf32 _Addr p _vaddr;

Elf32 _Addr p _paddr;

Elf32 _Word p _filesz;

Elf32 _Word p _memsz;

Elf32 _Word p _flags;

Elf32 _Word p _align;

} Elf32 _Phdr;

p _type This member tells w hat kind of segment this array element

describes or how to interpret the array element’s information.

Type values and their meanings appear below.

p _offset This member gives the offset from the beginning of the fi le atwh ich the first byte of the segmen t resides.

p _vaddr This member gives the virtual ad dress at w hich the first byte of

the segment resides in mem ory.

p _paddr On systems for which physical addressing is relevant, this

mem ber is reserved for the segment’s ph ysical addr ess. Because

System V ignores physical addressing for application programs,

this member has un specified contents for executable files and

shared objects.

5-2 PROGRAM LOADING AND DYNAMIC LINKING



Page: 75



p _filesz This member gives the num ber of bytes in the file image of the

segment; it may be zero.

p _memsz This member gives the num ber of bytes in the m emory image of

the segmen t; it may be zero.

p _flags This mem ber gives flags relevan t to the segment. Defined flagvalues appear below.

p _align As ‘‘Program Loading’’ describes in this chap ter of the p rocessor

supp lement, loadable process segments mu st have congruent

values for p _vaddr an d p _offset, mod ulo the page size. This

member gives the value to w hich the segments are aligned in

memory an d in the file. Values 0 and 1 mean no alignment is

required. Otherwise, p _align should be a positive, integral

pow er of 2, and p _vaddr should equal p _offset, modulo

p _align.

Some entries describe process segments; others give sup plemen tary information

and do n ot contribute to the process image. Segment entries may ap pear in anyorder, except as explicitly noted below. Defined type values follow; other values

are reserved for futu re use.

Figure 5-2: Segment Types, p _type

Name Value _________________________PT _NULL 0

PT _LOAD 1

PT _DYNAMIC 2

PT _INTERP 3

PT _NOTE 4

PT _SHLIB 5

PT _PHDR 6PT _LOPROC 0x70000000

PT _HIPROC 0x7fffffff _________________________

PT _NULL The array element is unused; other members’ values are

und efined. This type lets the program head er table have ignored

entries.

PT _LOAD The array element specifies a loadable segment, described by

p _filesz an d p _memsz. The bytes from the file are map ped to

the beginning of the memory segment. If the segment’s mem ory

size (p _memsz) is larger than the file size (p _filesz), the ‘‘extra’’

Program Header 5-3



Page: 76



bytes are defined to hold th e value 0 and to follow the segment’s

initialized area. The file size may not be larger than th e memor y

size. Loadable segment entries in the prog ram head er table

app ear in ascending ord er, sorted on the p _vaddr member.

PT _DYNAMIC The array element specifies dynam ic linking information . See‘‘Dynamic Section’’ below for more information.

PT _INTERP The array element sp ecifies the location and size of a nu ll-

terminated path nam e to invoke as an interpreter. This segment

type is mean ingful only for executable files (though it may occur

for shared objects); it may not occur m ore than once in a file. If it

is present, it mu st precede any load able segment entry . See ‘‘Pro-

gram Interpr eter’’ below for further inform ation.

PT _NOTE The array elemen t specifies the location and size of auxiliary

inform ation . See ‘‘Note Section’’ below for details.

PT _SHLIB This segmen t type is reserved bu t has un specified semantics. Pro-

grams that contain an array element of this type do not conform

to the ABI.

PT _PHDR The array elemen t, if presen t, specifies the location and size of the

program header table itself, both in the file and in the m emory

image of the program. This segment type may not occur m ore

than on ce in a file. Moreover, it may occur only if the prog ram

head er table is pa rt of the mem ory image of the program . If it is

presen t, it must precede any loadable segmen t entry. See ‘‘Pro-

gram Interpr eter’’ below for further inform ation.

PT _LOPROC through PT _HIPROC


seman tics. If mean ings are specified, the processor supp lement

explains them.

NOTE

Unless specifically required elsewhere, all program header segment types areoptional. That is, a file’s program header table may contain only those ele-ments relevant to its contents.




Page: 77



Base Address

As ‘‘Program Loading ’’ in this chapter of the processor sup plemen t describes, the E

virtual add resses in the program headers might not represent the actual virtual E

addr esses of the program ’s mem ory image. Executable files typically contain E

absolute code. To let the pr ocess execute correctly, the segmen ts mu st reside at E

the virtual add resses used to build the executable file. On the other hand , shared E

object segments typically contain position-indep end ent code. This lets a segmen t’s E

virtual add ress change from one process to another, without invalidating execu- E

tion behavior. Though the system chooses virtual add resses for individual E

processes, it maintains the segmen ts’ relativ e positions. Because position- E

independ ent code uses relative add ressing between segments, the difference E

between virtual add resses in memory must match the difference between virtual E

addr esses in the file. The difference between the virtua l addr ess of any segment in E

memory and the corresponding virtual address in the file is thus a single constant E

value for any one executable or shared object in a given process. This difference is E

the base address. On e use of the base addr ess is to relocate the mem ory image of E

the program d uring d ynamic linking.

An executable or sha red object file’s base addr ess is calculated d ur ing execution

from three values: the virtual memory load add ress, the maximum page size, and M

the lowest virtual addr ess of a program ’s loadable segmen t. To compu te the base E

add ress, one determines the memory ad dress associated w ith the lowest p _vaddr

value for a PT _LOAD segment. This addr ess is trun cated to the nearest mu ltiple of E

the maximu m page size. The corresponding p _vaddr value itself is also trun cated E

to the nearest mu ltiple of the maximu m page size. The base add ress is the differ- E

ence between the truncated memory ad dress and the trun cated p _vaddr value.

See this chapter in the p rocessor supp lement for more information and examples.

‘‘Operating System Interface’’ of Chapter 3 in the p rocessor supplemen t contains

more information about th e virtual address space and p age size.

Segment Permissions

A program to be loaded by the system m ust mu st have at least one loadable seg-

men t (although this is not required by the file format). When the system creates

loadable segm ents’ mem ory images, it gives access perm issions as sp ecified in the

p _flags member.

Program Header 5-5



Page: 78



Figure 5-3: Segment Flag Bits, p _flags

Nam e Value Meaning _ _______________________________________PF _X 0x1 Execute

PF _W 0x2 Write

PF _R 0x4 Read

PF _MASKPROC 0xf0000000 Unspecified _ _______________________________________

All bits includ ed in the PF _MASKPROC mask ar e reserved for processor-specific

seman tics. If mean ings are specified, the processor supp lement explains them .

If a perm ission bit is 0, that typ e of access is denied . Actual mem ory perm issions

dep end on the m emory managem ent unit, which may vary from one system to

another. Although all flag combinations are valid, the system m ay grant more

access than requested. In no case, how ever, will a segment hav e write permission

un less it is specified explicitly. The following table show s both the exact flag

interpr etation and the allowable flag interpretation. ABI-conforming systems may

provide either.

Figure 5-4: Segment Permissions

Flags Value Exact Allowable _ __________________________________________________________________none 0 All access den ied All access den ied

PF _X 1 Execute only Read, execute

PF _W 2 Write only Read, write, execute

PF _W + PF _X 3 Write, execute Read, write, execute

PF _R 4 Read only Read, execute

PF _R + PF _X 5 Read, execute Read, execute

PF _R + PF _W 6 Read, write Read, wr ite, executePF _R + PF _W + PF _X 7 Read, write, execute Read, wr ite, execute _ __________________________________________________________________

For example, typical text segments have read and execute—but not write—

perm issions. Data segments norma lly have read, write, and execute permissions.




Page: 79



Segment Contents

An object file segment comp rises one or more sections, though this fact is tran-

sparent to the program h eader. Whether the file segment holds one or many sec-

tions also is imm aterial to program loading. Non etheless, various data m ust be

present for program execution, dynam ic linking, and so on. The diagrams below

illustra te segmen t contents in general terms. The order and m embersh ip of sec-

tions within a segm ent may vary; moreover, processor-specific constraints m ay

alter the examp les below. See the pr ocessor sup plem ent for details.

Text segmen ts contain read -only instru ctions and da ta, typically includ ing the fol-

lowing sections described in Chap ter 4. Other sections may also reside in loadable

segmen ts; these examples are not meant to give comp lete and exclusive segment

contents.

Figure 5-5: Text Segment _ __________

.text _ __________.rodata _ __________.hash _ __________.dynsym _ __________.dynstr _ __________.plt _ __________

.rel.got _ __________

Data segmen ts contain w ritable data and instructions, typically includ ing the fol-

lowing sections.

Figure 5-6: Data Segment _ __________

.data _ __________.dynamic _ __________.got _ __________.bss _ __________

A PT _DYNAMIC program h eader element p oints at the .dynamic section, explained

in ‘‘Dyn am ic Section’’ below . The .got an d .plt sections also hold information

related to position-ind epend ent code and dynam ic linking. Although the .plt

app ears in a text segment above, it may reside in a text or a data segment,

Program Header 5-7



Page: 80



dep end ing on the p rocessor. See ‘‘Global Offset Table’’ and ‘‘Procedu re Linkage

Table’’ in this chap ter of the pr ocessor supp lement for details.

As ‘‘Sections’’ in Ch ap ter 4 d escribes, the .bss section has the type SHT _NOBITS.

Althou gh it occup ies no space in the file, it contribu tes to the segment’s memory

image. Norm ally, these uninitialized d ata reside at the end of the segment,thereby making p _memsz larger th an p _filesz in the associated program header

element.

Note Section

Sometimes a vendor or system bu ilder needs to m ark an object file with sp ecial

information th at other p rogram s will check for conformance, comp atibility, etc.

Sections of typ e SHT _NOTE and program h eader elements of type PT _NOTE can be

used for this purp ose. The note information in sections and program header ele-

men ts holds any num ber of entries, each of which is an array of 4-byte word s in

the format of the target processor. Labels app ear below to help explain note infor-

mation organization, but they are not part of the specification.

Figure 5-7: Note Information _ ________namesz _ ________descsz _ ________type _ ________name. . .

_ ________desc. . .

_ ________

namesz an d name

The first namesz bytes in name contain a null-terminated character

repr esentation of the entry’s owner or originator. There is no form al

mechan ism for avoiding nam e conflicts. By conven tion, vend ors use

their own name, such as ‘‘XYZ Comp uter Com pan y,’’ as the iden tifier.

If no nam e is presen t, namesz contains 0. Padding is pr esent, if neces-

sary, to ensu re 4-byte alignmen t for the descriptor. Such padd ing is

not includ ed in namesz.




Page: 81



NOTE

Note information is optional. The presence of note information does not affecta program’s ABI conformance, provided the information does not affect theprogram’s execution behavior. Otherwise, the program does not conform tothe ABI and has undefined behavior.




Page: 83



Program Loading (Processor-Specific)





Page: 84



Dynamic Linking

Program Interpreter

An executable file that p articipates in dynam ic linking shall have one PT _INTERP E

program h eader element. During the function exec, the system retrieves a path X

name from the PT _INTERP segmen t and creates the initial process image from the

interpr eter file’s segmen ts. That is, instead of using th e original executable file’s

segmen t images, the system composes a memory image for the interpr eter. It then

is the interpreter’s responsibility to receive control from the system and prov ide

an environmen t for the application p rogram.

As ‘‘Process Initialization’’ in Chapter 3 of the pr ocessor supplemen t m entions, the

interpr eter receives control in one of two w ays. First, it may receive a file descrip-

tor to read th e executable file, positioned a t the beginning. It can u se this file

descriptor to read an d/ or map the executable file’s segments into memory.

Second, depending on the executab le file format, the system may load the execut-able file into memory instead of giving the interpreter an open file descriptor.

With the possible exception of the file d escriptor, th e interp reter’s initial process

state matches what the executab le file would have received. The interp reter itself

may n ot require a second interpreter. An interpreter may be either a shared object

or an executable file.

A shared object (the norm al case) is load ed as position-indep end ent, with

addr esses that may var y from one pr ocess to another; the system creates its

segments in the d ynamic segment area used by the function mmap and X

related services [see ‘‘Virtual Ad dr ess Space’’ in Chap ter 3 of the pr ocessor

sup plemen t]. Consequ ently, a shared object interpr eter typically will not

conflict with the or iginal executable file’s original segment add resses.

An executable file is loaded at fixed ad dr esses; the system creates its seg-

ments using the virtual add resses from the program header table. Conse-

quently, an executab le file interpreter’s virtual add resses may collide w ith

the fir st executab le file; the interp reter is respon sible for resolving confl icts.




Page: 85



Dynamic Linker

When bu ilding an executable file that uses d ynamic linking, the link editor add s a

program header element of type PT _INTERP to an executab le file, telling the sys-

tem to invoke the d ynamic linker as the p rogram interpreter.

NOTE The locations of the system provided dynamic linkers are processor–specific.

Exec and the d ynamic linker cooperate to create the pr ocess image for the p ro-

gram , which entails the following actions:

Adding the executable file’s memor y segments to the p rocess image;

Add ing shared object mem ory segments to the p rocess image;

Performing r elocations for the executable file and its shared objects;

Closing the file descriptor that w as used to read the executable file, if one

was given to th e dyn amic linker;

Transferring control to the program, making it look as if the program had

received control directly from the fun ction exec X

The link ed itor also constru cts various da ta that assist the dynam ic linker for exe-

cutable and sh ared ob ject files. As show n above in ‘‘Program Head er,’’ these da ta

reside in loadable segmen ts, making them available du ring execution. (Once

again, recall the exact segment conten ts are p rocessor-specific. See the p rocessor

supplement for complete information.)

A .dynamic section with typ e SHT _DYNAMIC holds various data. The struc-

tur e residing at the beginning of the section hold s the add resses of other

dynamic linking information.

The .hash section with typ e SHT _HASH holds a symbol hash table.

The .got an d .plt sections with type SHT _PROGBITS hold two separate

tables: the global offset table and the p rocedu re linkage table. Chap ter 3

discusses how programs use the global offset table for position-independent

code. Sections below explain how the dyn amic linker uses and changes the

tables to create mem ory images for object files.




Page: 86



Because every ABI-conforming p rogram imports the basic system services from a

shared object library [see ‘‘System Library’’ in Ch apter 6], the d ynam ic linker p ar-

ticipates in every ABI-conforming pr ogram execution.

As ‘‘Program Loading’’ explains in the p rocessor supp lement, shar ed objects may

occup y virtual memory add resses that are d ifferent from the ad dresses recordedin the file’s program h eader table. The dynamic linker relocates the memory

image, updating absolute addresses before the application gains control.

Although th e absolute ad dress values w ould be correct if the library w ere loaded

at the ad dresses specified in the p rogram h eader table, this normally is not the

case.

If the p rocess environm ent [see the function exec] contains a variable nam ed X

LD _BIND _NOW with a n on-nu ll value, the d ynam ic linker processes all relocation

before transferring control to the prog ram . For examp le, all the following

environment en tries w ould specify this behavior.

LD _BIND _NOW=1

LD _BIND _NOW=on

LD _BIND _NOW=off

Otherwise, LD _BIND _NOW either d oes not occur in the environment or h as a nu ll

value. The dynamic linker is perm itted to evaluate p rocedure linkage table entries

lazily, thus avoiding symbol resolution and relocation overhead for functions that

are not called. See ‘‘Proced ure Linkage Table’’ in this chapter of the processor

supp lement for m ore information.

Dynamic Section

If an object file participates in d ynam ic linking, its prog ram h eader table will have

an element of type PT _DYNAMIC. This ‘‘segm ent’’ contain s the .dynamic section.A special symbol, _DYNAMIC, labels the section, wh ich contains an array of the fol-

lowing structures.




Page: 87



Figure 5-9: Dynamic Structure

typedef struct {

Elf32 _Sword d _tag;union {

Elf32 _Word d _val;

Elf32 _Addr d _ptr;

} d _un;

} Elf32 _Dyn;

extern Elf32 _Dyn _DYNAMIC[];

For each object with th is type, d _tag controls the interpretation of d _un.

d _val These Elf32 _Word objects repr esent integer values with various

interpretations.

d _ptr These Elf32 _Addr objects represen t prog ram virtual addr esses. Asmentioned previously, a file’s virtual add resses might n ot match th e

memory virtual add resses during execution. When interpreting

add resses contained in the d ynamic structure, the d ynamic linker

computes actual add resses, based on the original file value and the

mem ory base add ress. For consistency, files do not contain relocation

entries to ‘‘correct’’ addr esses in the d ynam ic structure.

The following table summarizes the tag requirements for executable and shared

object files. If a tag is marked ‘‘man da tory,’’ then th e dyn amic linking a rray for an

ABI-conforming file m ust h ave an entry of tha t type. Likewise, ‘‘optiona l’’ mean s

an entry for the tag may app ear but is not required.

Figure 5-10: Dynamic Array Tags, d _tag

Name Value d _un Executable Shared Object _ ___________________________________________________________________DT _NULL 0 ignored mandatory mandatory

DT _NEEDED 1 d _val optional optional

DT _PLTRELSZ 2 d _val optional optional

DT _PLTGOT 3 d _ptr optional optional

DT _HASH 4 d _ptr mandatory mandatory

DT _STRTAB 5 d _ptr mandatory mandatory

DT _SYMTAB 6 d _ptr mandatory mandatory




Page: 88



Figure 5-10: Dynamic Array Tags, d _tag (continued )

Name Value d _un Executable Shared Object _ ___________________________________________________________________DT _RELA‡ 7 d _ptr mandatory optional

DT _RELASZ 8 d _val mandatory optionalDT _RELAENT 9 d _val mandatory optional

DT _STRSZ 10 d _val mandatory mandatory

DT _SYMENT 11 d _val mandatory mandatory

DT _INIT 12 d _ptr optional optional

DT _FINI 13 d _ptr optional optional

DT _SONAME 14 d _val ignored optional

DT _RPATH 15 d _val optional ignored

DT _SYMBOLIC 16 ignored ignored optional

DT _REL† 17 d _ptr mandatory optional

DT _RELSZ 18 d _val mandatory optional

DT _RELENT 19 d _val mandatory optional

DT _PLTREL 20 d _val optional optional

DT _DEBUG 21 d _ptr optional ignoredDT _TEXTREL 22 ignored optional optional

DT _JMPREL 23 d _ptr optional optional

DT _BIND _NOW 24 ignored optional optional M

DT _LOPROC 0x70000000 unspecified unspecified unspecified

DT _HIPROC 0x7fffffff unspecified unspecified unspecified _ ___________________________________________________________________

† See the d escription of DT _RELA and DT _REL below for the relationship between these M

two tags.

DT _NULL An entry with a DT _NULL tag marks the end of the _DYNAMIC

array.

DT _NEEDED This element holds th e string table offset of a null-terminated

string, giving the nam e of a needed library. The offset is an index

into the table recorded in the DT _STRTAB entry. See ‘‘Shared

Object Depen den cies’’ for more informa tion abou t these names.

The dynam ic array m ay contain m ultiple entries with this type.

These entries’ relative order is significant, thou gh th eir relation to

entries of other types is not.

DT _PLTRELSZ This elemen t hold s the total size, in bytes, of the relocation entries

associated w ith the procedu re linkage table. If an entry of type

DT _JMPREL is present, a DT _PLTRELSZ mu st accompany it.




Page: 89



DT _PLTGOT This element h olds an ad dress associated with the p rocedu re link-

age table and / or the global offset table. See this section in the

processor supplement for details.

DT _HASH This element hold s the add ress of the symbol hash table,

described in ‘‘Hash Table.’’ This ha sh tab le refers to the sym bol table referenced by th e DT _SYMTAB element.

DT _STRTAB This elemen t holds th e add ress of the string table, described in

Chap ter 4. Symbol nam es, library names, and oth er strings reside

in this table.

DT _SYMTAB This elemen t holds the add ress of the sym bol table, described in

Chapter 4, with Elf32 _Sym entr ies for the 32-bit class of files.

DT _RELA This elemen t holds th e add ress of a relocation table, described in

Chap ter 4. Entries in the table have explicit add end s, such as

Elf32 _Rela for the 32-bit file class. An ob ject file may have mu l-

tiple relocation sections. When building th e relocation table for

an executable or sha red object file, the link editor catenates those

sections to form a single table. Althou gh the sections remain

indep end ent in the object file, the d ynam ic linker sees a single

table. When the dynamic linker creates the process image for an

executab le file or adds a shared object to the process image, it

reads the relocation table and perform s the associated actions. If

this element is present, the d ynamic structure mu st also have

DT _RELASZ and DT _RELAENT elements. When relocation is ‘‘man -

datory’’ for a file, either DT _RELA or DT _REL mu st occur (both are M

permitted bu t only one is required).

DT _RELASZ This element holds th e total size, in bytes, of the DT _RELA reloca-

tion table.

DT _RELAENT This elemen t holds the size, in bytes, of the DT _RELA relocationentry.

DT _STRSZ This element holds th e size, in bytes, of the string table.

DT _SYMENT This element holds th e size, in bytes, of a symbol table entry.

DT _INIT This elemen t holds the add ress of the initialization function, dis-

cussed in ‘‘Initialization an d Termination Functions’’ below.

DT _FINI This element hold s the add ress of the termina tion function, dis-

cussed in ‘‘Initialization an d Termination Functions’’ below.




Page: 90



DT _SONAME This element holds th e string table offset of a null-terminated

string, giving the nam e of the shared object. The offset is an index

into the table recorded in the DT _STRTAB entry. See ‘‘Shared

Object Depen den cies’’ below for m ore information about these

names.

DT _RPATH This element holds th e string table offset of a null-terminated

search library search p ath str ing, discussed in ‘‘Shared Object

Depen den cies.’’ The offset is an ind ex into the table recorded in

the DT _STRTAB entry.

DT _SYMBOLIC This elemen t’s pr esence in a shar ed object library alters the

dynam ic linker’s symbol resolution algorithm for references

with in the library. Instead of starting a symbol search with the

executable file, the dyn amic linker starts from the shar ed object

itself. If the shared object fails to sup ply the referenced sym bol,

the dynam ic linker then searches the executab le file and oth er

shared objects as usu al.

DT _REL This element is similar to DT _RELA, except its table has imp licitaddend s, such as Elf32 _Rel for the 32-bit file class. If this ele-

ment is present, the dynam ic structure must also have DT _RELSZ

an d DT _RELENT elements.

DT _RELSZ This element holds the total size, in bytes, of the DT _REL reloca-

tion table.

DT _RELENT This element holds th e size, in bytes, of the DT _REL relocation

entry.

DT _PLTREL This member sp ecifies the type of relocation entry to w hich the

procedur e linkage table refers. The d _val member holds DT _REL

or DT _RELA, as app rop riate. All relocations in a procedur e link-

age table must u se the same relocation.DT _DEBUG This mem ber is used for debu gging. Its contents are not specified

for the ABI; program s that access this entry are n ot ABI-

conforming.

DT _TEXTREL This member’s absence signifies that no relocation entry shou ld

cause a mod ification to a non -writable segment, as specified by

the segment perm issions in the p rogram h eader table. If this

member is present, one or more relocation entries might request

mod ifications to a non -writable segment, and the d ynamic linker

can pr epare accordingly.




Page: 91



NOTE

Even when a shared object is referenced multiple times in the dependencylist, the dynamic linker will connect the object only once to the process.

Names in the dependen cy list are copies either of the DT _SONAME strings or thepa th nam es of the shared objects used to build the object file. For examp le, if the

link editor bu ilds an executable file using on e shared object with a DT _SONAME

entry of lib1 and another shared object library w ith the path n ame

/usr/lib/lib2, the executable file w ill contain lib1 an d /usr/lib/lib2 in its

dep endency list.

If a shared object name has one or mor e slash (/) characters anywh ere in the

name, such as /usr/lib/lib2 above or directory/file, the dynamic linker

uses that string d irectly as the path n ame. If the nam e has no slashes, such as

lib1 above, three facilities specify sha red object path searching, with the follow-

ing precedence.

First, the dynamic array tag DT _RPATH may give a string tha t holds a list of

directories, separa ted by colons (:). For examp le, the string

/home/dir/lib:/home/dir2/lib: tells the dynam ic linker to search first

the directory /home/dir/lib, then /home/dir2/lib, and then the current

directory to find dep endencies.

Second, a variable called LD _LIBRARY _PATH in the pr ocess environm ent [see X

the function exec] may hold a list of directories as above, optionally fol-

lowed by a semicolon (;) and anoth er directory list. The following values

wou ld be equivalent to the previous examp le:

LD _LIBRARY _PATH=/home/dir/lib:/home/dir2/lib:

LD _LIBRARY _PATH=/home/dir/lib;/home/dir2/lib:

LD _LIBRARY _PATH=/home/dir/lib:/home/dir2/lib:;All LD _LIBRARY _PATH directories are searched a fter those from DT _RPATH.

Althou gh som e programs (such as the link editor) treat the lists before and

after the semicolon differently, the dynamic linker does not. Nevertheless,

the dynam ic linker accepts the semicolon notation, with the semantics

described above.

Finally, if the other tw o grou ps of d irectories fail to locate the d esired

library, the dynamic linker searches /usr/lib.




Page: 93



NOTE

For security, the dynamic linker ignores environmental search specifications(such as LD _LIBRARY _PATH) for set-user and set-group ID programs. It does, Mhowever, search DT _RPATH directories and /usr/lib. The same restriction Mmay be applied to processes that have more than minimal privileges on sys-tems with installed extended security systems.

Global Offset Table (Processor-Specific)

NOTE


Procedure Linkage Table (Processor-Specific)

NOTEThis section requires processor-specific information. The ABI supplement forthe desired processor describes the details.

Hash Table

A hash tab le of Elf32 _Word objects sup por ts symbol table access. Labels app ear

below to help explain the hash table organization, but they are not part of the

specification.

Figure 5-11: Symbol Hash Table _ _____________________nbucket _ _____________________nchain _ _____________________

bucket[0]

. . .

bucket[nbucket - 1] _ _____________________chain[0]

. . .

chain[nchain - 1] _ _____________________




Page: 94



The bucket array contains nbucket entries, and the chain array contains nchain

ent ries; ind exes start at 0. Both bucket an d chain hold symbol table indexes.

Chain table entries parallel the symbol table. The num ber of symbol table entries

should equal nchain; so symbol table ind exes also select chain table entries. A

hashing function (shown below) accepts a symbol nam e and returns a value that

may be used to compu te a bucket index. Consequ ently, if the hashing functionreturns the value x for some nam e, bucket[ x%nbucket] gives an index, y , into

both the symbol table and the chain table. If the symbo l table entry is not the one

desired, chain[ y] gives the next symbol table entry with the same hash value.

One can follow th e chain links until either the selected sym bol table entry holds

the desired name or the chain entry contains the value STN _UNDEF.

Figure 5-12: Hashing Function

unsigned long

elf _hash(const unsigned char *name)

{

unsigned long h = 0, g;

while (*name)

{

h = (h << 4) + *name++;

if (g = h & 0xf0000000)

h ̂ = g >> 24;

h &= ̃ g;

}

return h;

}

Initialization and Termination Functions

After the dyn amic linker h as built the p rocess image and performed th e reloca-

tions, each sha red ob ject gets the opportun ity to execute som e initialization code.

All shared object initializations happ en before the executable file gains control.

Before the initialization code for any object A is called, the initialization code for M

any other objects that object A dep end s on are called. For these pu rposes, an M

object A dep end s on anoth er object B, if B appears in A’s list of need ed objects M

(recorded in th e DT _NEEDED entries of the dynam ic structu re). The ord er of ini- M

tialization for circular dep end encies is un defin ed. M




Page: 95



The initialization of objects occur s by recursing throu gh the needed entries of each M

object. The initialization code for an object is invoked after the needed entries for M

that object have been processed. The ord er of processing amon g the entries of a M

par ticular list of needed objects is un specified. M

NOTE MEach processor supplement may optionally further restrict the algorithm used MMto determine the order of initialization. Any such restriction, however, may not MMconflict with the rules described by this specification. MM

The following examp le illustra tes two of the possible correct orderings which can M

be generated for the example NEEDED lists. In this examp le the a.out is dep en- M

dent on b, d, and e. b is depen dent on d and f, wh ile d is depen dent on e and g. M

From this information a dep endency graph can be draw n. The above algorithm M

on initialization will then allow the following specified initialization ord erings M

among others.




Page: 96



Initialization Ordering Example




Page: 97



Figure 5-13: Initialization Ordering Example

a.out b d a.out

b d e

d f g

e

b d e

f g

NEEDED Lists Dependen cy Graph

e g d f b a.out

g f e d b a.out

Init Orderings:




Page: 98



Similarly, shared objects may have term ination functions, wh ich are executed w ith

the function atexit mechan ism after the base process begins its termina tion X

sequen ce. The order in wh ich the dynam ic linker calls termina tion functions is the M

exact reverse order of their correspond ing initialization functions. If a shared M

object has a termination function, but no initialization function, the termina tion M

function will execute in the order it wou ld have as if the shared object’s initializa- Mtion function was presen t. The dynam ic linker ensu res that it will not execute any M

initialization or termination fun ctions mor e than on ce.

Shared objects designate their initialization and termination functions through the

DT _INIT an d DT _FINI entries in the dynam ic structu re, described in ‘‘Dynamic

Section’’ above. Typically, the code for these functions resides in th e .init an d

.fini sections, mentioned in ‘‘Sections’’ of Chapter 4.

NOTE

Although the function atexit termination processing normally will be done, itis not guaranteed to have executed upon process death. In particular, the Xprocess will not execute the termination processing if it calls _exit [see thefunction exit] or if the process dies because it received a signal that it neithercaught nor ignored.

The dynam ic linker is not respon sible for calling th e executab le file’s .init sec- M

tion or registering the executable file’s .fini section w ith the function atexit. M

Termination functions specified by users via the atexitmechan ism mu st be exe- M

cuted before any termina tion functions of shared objects.




Page: 99



6 LIBRARIES

Introduction 6-1

Shared Library Names 6-3

Dependencies Among Libraries 6-3

System Service Synonyms 6-3

C Library 6-5

Additional Entry Points (Processor-Specific) 6-10

Support Routines (Processor-Specific) 6-11

Global Data Symbols 6-11

Application Constraints 6-13

Implementation of libc Routines 6-13

Vendor Extensions 6-14


Dynamic Linking Library6-17


Socket Library 6-21

Table of Contents i


386:adm.book:sum

Page: 100



Curses Library 6-22


X11 Nonrectangular Window ShapeExtension Library 6-33




Required Sizes for Some Data Objects 6-46

Data Definitions (Processor-Specific) 6-47



386:adm.book:sum

Page: 101



Introduction

Every ABI-conforming system su pp orts some general-pu rpose libraries. Facilities

in these libraries manipulate system d ata files, trap to the op erating system, and so

on. Together, these libraries hold rou tines appear ing in sections BA _OS, BA _LIB,

KE _OS, RS _LIB, and MT _LIB of the System V Interface Definition, Fourth Edition.

libc The C library, containing various facilities defined by System V, ANSI

C, ISO MSE, POSIX, and so on. It contains inter faces to basic system

services. M

libthread M

The thread library, containing interfaces to sup port mu ltiprocessing M

app lications and asynchronous I/ O operations included in the MT M

extension of the System V Interface Definition, Fourth Edition. M

libdl MThe dynam ic linking library, containing rou tines that give the user M

direct access to the dynam ic linking facilities.

libnsl The netw orking services library, contains the transp ort layer interface X

routines, as well as routines for machine-independ ent data representa- X

tion, remote procedure calls, and other networking supp ort. These X

routines are described in the Networ king Services volum e of the X

X/Open CA E Specification, Issue 4.2, and th e BA _OS and RS _LIB section s X

of the Syst em V Interface Definition, Fourth Edition (see the Conformance X

Rule in chap ter1).

libsocket

A library containing the sockets routines as described in the Netw ork- X

ing Services volum e of the X/Open CA E Specification, Issue 4.2. X

libcurses XThis library prov ides rou tines for up da ting character screens as X

described in th e X/ Open Curses, Issue 4 of the X/Open CAE X

Specification, Issue 4.2.

The following libraries may be sup por ted as extensions to the ABI. G

libX GA library for building app lications using the X11 Window System pro- G

tocol described in the Grap hics chapter. G

libXt GA library for building app lications using the X Toolkit Intrinsics. G

Introduction 6-1



Page: 102



libXext MA library for building app lications using the X11 Nonrectangu lar Win- M

dow Shape Extension. M

libXm MA library for bu ild ing app lications using the Motif 1.2 Interface. M

libMrm MA library containing the resour ce man ager for the Motif 1.2 Interface. M

NOTE

libsys has been removed from the Application Binary Interface. Originally Mlibsys was devised as a subset of libc functionality comprised of a useful Msuperset of system calls. Difficulties in the division between the two libraries, Madditional maintenance efforts and lack of use of libsys by applicationspointing to the ABI have led to the elimination of the library from the ABI .

As a binary specification, the ABI gives shared library organ ization; that is, it tells

wh at services reside in w hat shared libraries. Programs use the d ynamic linking

mechan ism described in Chap ter 5 to access their services.

The ABI does not d up licate the descriptions available in the X/Open CAE X

Specification, Issue 4.2 and the System V Interface Definition, Fourth Edition and other

references that tell what the facilities do, how to use them , and so on. However,

the interfaces to some services may hav e different nam es and syntax at the systemlevel than th ey do at the sou rce level. When th ese differences exist, this docum ent

(the System V A BI ) specifies the nam e of the source-level services that m ust be su p-

ported on conforming systems, and the nam es and descriptions of these interfaces

are given in each processor sup plement to the ABI .

Shared libraries contribute to the app lication execution environm ent and thus

app ear in the ABI . Functions that reside directly in application files are not

specified. For example, math ematical rou tines, such as sin, do not appear below.

They wou ld be available in a System V d evelopment environment, but an

application’s executable file would contain the associated code. Assum ing the

imp lementations of the functions them selves are ABI-conforming, their presence

does not affect the conformance of the application. Moreover, the absence of

shared library versions of pa rticular services does not imp ly a depr ecation of thoseservices.

The ABI requires conforming applications to use the dynamic linking mechanism

described in Ch apter 5 to access the services prov ided in the C Library, libc, the M

Dynamic Linking Library, libdl, the threads Library, libthread, and in the N et-

working Services Library, libnsl. In add ition, on systems that supp ort the M

graph ical wind owing terminal interface, the dyn amic linking mechanism must be M

used to access the X Wind ow System Library serv ices, libX. Use of the other

shared libraries documen ted here is optiona l for app lications; the services they

contain may be obtained throu gh the use of equivalent archive library rou tines. E

An app lication that accesses ABI services from both the shared library and the E

static archive version of the sam e library is not ABI conform ing.

6-2 LIBRARIES



Page: 103



Shared Library Names

As Chap ter 5 describes, executable and shared object files contain the nam es of

required shared libraries. In the names below, number represents the current ver- M

sion nu mber of the library. The version nu mber of each library is specified in the M

ABI supp lement for the d esired p rocessor.

Figure 6-1: Shared Library Names

Library Reference Name _ ____________________________________________________________________________libc /usr/lib/libc.so.number

libthread /usr/lib/libthread.so.numberM

libdl /usr/lib/libdl.so.number M

libnsl /usr/lib/libnsl.so.number

libsocket /usr/lib/libsocket.so.2 X

libcurses /usr/lib/libcurses.so.1 X

libX /usr/lib/libX11.so.number

libXt /usr/lib/libXt.so.number G

libXext /usr/lib/libXext.so.number M

libXm /usr/lib/libXm.so.number M

libMrm /usr/lib/libMrm.so.number M _ ____________________________________________________________________________

Dependencies Among Libraries

System libraries may depend on other libraries both defined by the ABI and not M

defined by the ABI. The runtime environment should not require that such M

dep end encies be reflected in the executab le if the executable itself does not have M

any dependencies on those libraries.

System Service Synonyms

In add ition to the routine nam es listed in the tables below, the C library includes

synonyms for some of its services. These other symbols are available to conform

to language and system stand ards. As an example, System V defines read as the

name of an op erating system facility. On th e other hand , ANSI C does not d efine

read, and it proh ibits a strictly conforming implementation from u surping ap plica-

tion names without a leading un derscore ( _ ). Thus if a synonym for read were

not available, the system could not support a strictly conforming implementation

of the ANSI C language.

Introduction 6-3



Page: 104



name This gives the trad itional name, such as read.

_name This gives a system service name that follows th e ANSI C convention

of reserving symbols beginning with an u nd erscore, such as _read.

The title of each of the below tables specifies whether syn onym s mu st exist for the

entries in that table.

Although many system services have two names, two exceptions exist to this

synon ym convention. System V defin es both exit an d _exit as d ifferen t facili-

ties. Con sequen tly, the symbo ls exit an d _exit have no synonym s and refer to

different services.

6-4 LIBRARIES



Page: 105



C Library

The C library, libc, contains all of the sym bols listed in th e following tw o tables.

libc contains the basic system services. Although special instructions are neces-

sary to change from u ser to kernel mode, the ABI explicitly does n ot sp ecify the

correspond ence of these instructions to system calls. The tables below contain

rou tines that correspond to ba sic system services, as well as to service routines

that p rovide a functional interface to system da ta files.

Though all the fun ction sym bols listed in the tables below mu st be present in

libc, not all of the fun ctions they reference may actually be imp lemented . See the

‘‘Implem entation of libc Routines’’ section th at follows for mor e detail.

The first table lists rout ines associated with the ANSI C stand ard and th e ISO MSE M

rou tines as they are currently defined in th e SVID.

NOTE

Although synonyms are not required for the following interfaces, they are per- Mmitted to exist. However applications that make use of the synonyms are notconsidered ABI compliant.

Figure 6-2: libc Contents, Names without Synonyms

abort ferror fscanf isdigit iswupper*

abs fflush fseek isgraph iswxdigit*

asctime fgetc fsetpos islower isxdigit

atexit fgetpos ftell isprint labs

atof fgets fwprintf* ispunct ldexp

atoi fgetwc* fwrite isspace ldiv

atol fgetws* fwscanf* isupper localeconvbsearch fopen getc iswalnum* localtime

calloc fprintf getchar iswalpha* longjmp

clearerr fputc getenv iswcntrl* malloc

clock fputs gets iswctype* mblen

ctime fputwc* getwchar* iswdigit* mbrlen*

difftime fputws* getwc* iswgraph* mbrtowc*

div fread gmtime iswlower* mbsinit*

exit free isalnum iswprint* mbsrtowcs*

fclose freopen isalpha iswpunct* mbstowcs

feof frexp iscntrl iswspace* mbtowc

C Library 6-5



Page: 106



Figure 6-2: libc Contents, Names without Synonyms (continued )

memchr rewind strncmp towupper* wcsncmp*

memcmp scanf strncpy ungetc wcsncpy*

memcpy setbuf strpbrk ungetwc* wcspbrk*

memmove setjmp strrchr vfprintf wcsrchr*

memset setlocale strspn vfwprintf* wcsrtombs*

mktime setvbuf strstr vprintf wcsspn*

modf signal strtod vsprintf wcsstr*

perror sprintf strtok vswprintf* wcstod*

printf srand strtol vwprintf* wcstok*

putc sscanf strtoul wcrtomb* wcstol*

putchar strcat strxfrm wcscat* wcstombs

puts strchr swprintf* wcschr* wcstoul*

putwchar* strcmp swscanf* wcscmp* wcsxfrm*

putwc* strcoll system wcscoll* wctob*

qsort strcpy tmpfile wcscpy* wctomb

raise strcspn tmpnam wcscspn* wctype*rand strerror tolower wcsftime* wprintf*

realloc strftime toupper wcslen* wscanf*

remove strlen towlower* wcsncat* _exit

rename strncat

*Function is new to the Fourth Edition of the ABI. M

Each of the routines listed in the table below is present in libc in the listed form,

as well as in synonym form, as described in a following section.

Figure 6-3: libc Contents, Names with Synonyms

access flockfile* getsubopt modload*acct# fnmatch* gettxt modpath*

alarm fork getuid modstat*

asctime _r* fork1* getw moduload*

catclose forkall* glob* monitor

catgets fpathconf globfree* mount

catopen fstatvfs gmtime _r* mprotect

cfgetispeed fsync grantpt msgctl

cfgetospeed ftok hcreate msgget

cfsetispeed ftrylockfile* hdestroy msgrcv

cfsetospeed funlockfile* hsearch msgsnd

6-6 LIBRARIES



Page: 107



Figure 6-3: libc Contents, Names with Synonyms (continued )

chdir getc _unlocked* iconv* msync

chmod getchar _unlocked* iconv _close* munlock

chown getcontext iconv _open* munmap

chroot getcwd initgroups nextafter

close getdate ioctl nftw

closedir getegid isascii nice

confstr* geteuid isastream nl _langinfo

creat getgid isatty open

ctermid getgrgid isnan opendir

ctime _r* getgrnam isnand# pathconf

cuserid getgroups kill pause

dup getksym* lchown pclose

dup2 getlogin lfind pipe

execl getlogin _r* link poll

execle getmsg localtime _r* popen

execlp getopt lockf pread*execv getpass logb priocntl*

execve getpass _r* lsearch profil#

execvp getpgid lseek ptrace

fattach getpgrp makecontext ptsname

fchdir getpid memccpy putc _unlocked*

fchmod getpmsg memcntl putchar _unlocked*

fchown getppid mkdir putenv

fcntl getpwnam mkfifo putmsg

fdetach getpwuid mktemp putpmsg

fdopen getrlimit mlock putw

fileno getsid mmap pwrite*

rand _r* shmctl strfmon* ttyname

read shmdt strptime* ttyname _r*readdir shmget strtof* twalk

readdir _r* sigaction strtok _r* tzset

readlink sigaddset strtold* ulimit

readv sigaltstack swab umask

regcomp* sigdelset swapcontext umount

regerror* sigemptyset symlink unlink

regexec* sigfillset sync unlockpt

regfree* sighold sysconf utime

rewinddir sigignore tcdrain vfscanf*

C Library 6-7



Page: 108



Figure 6-3: libc Contents, Names with Synonyms (continued )

rmdir sigismember tcflow vfwscanf*

scalb siglongjmp tcflush vscanf*

seekdir sigpause tcgetattr vsnprintf*

semctl sigpending tcgetpgrp vsscanf*

semget sigprocmask tcgetsid vswscanf*

semop sigrelse tcsendbreak vwscanf*

setcat* sigsend tcsetattr wait

setcontext sigsendset tcsetpgrp waitid

setgid sigset tdelete waitpid

setgroups sigsetjmp tell# wcstof*

setlabel# sigsuspend telldir wcstold*

setpgid sigwait* tempnam wcswidth*

setpgrp sleep tfind wcwidth*

setrlimit snprintf* time wordexp*

setsid statvfs times wordfree*

setuid stime toascii writeshmat strdup tsearch writev


# Function is DEPRECATED X

NOTE

Other than for use in streams devices, the specific devices supported by ioctl are processor specific.

libc in the System V Application Binary In terface, Edition 4.1 also contains the fol- X

lowing routines wh ich are conformant to the System Interfaces and Head ers X

volume of the X/Open CA E Specification Guide, Issue 4.2 (see the Conformance Rule Xin Chap ter 1). This table lists rou tines from the ANSI C stand ard . X

Figure 6-4: libc Contents from XSH4.2, Names without Synonyms X

advance# erand48 lrand48 nrand48 srand48 X

compile# jrand48 mrand48 seed48 step# X

drand48 lcong48 X


6-8 LIBRARIES



Page: 109



Additionally,libc holds the following services (not contained in the AN SI C stan-

dard).

Figure 6-5: libc Contents from XSH4.2, Names with Synonyms

_longjmp dbm _store getpwent re _comp setstate _setjmp dirname getrusage re _exec setutxent

a64l ecvt gettimeofday realpath siginterrupt

basename endgrent getutxent regcmp signgam

bcmp endpwent getutxid regex sigstack

bcopy endutxent getutxline regexp srandom

brk fcvt getwd remque strcasecmp

bsd _signal ffs ilogb rindex strncasecmp

bzero ftime index rint syslog

closelog ftruncate initstate sbrk truncate

dbm _clearerr ftw insque select ttyslot

dbm _close gcvt killpg setgrent ualarm

dbm _delete getdtablesize l64a setitimer usleep

dbm _error getgrent log1p setlogmask utimesdbm _fetch gethostid mkstemp setpriority valloc

dbm _firstkey getitimer openlog setpwent vfork

dbm _nextkey getpagesize pututxline setregid wait3

dbm _open getpriority random setreuid wcswcs

The routines listed in the table below are need ed by the library to w ork p roperly.

These routines should not be used by app lications. E

Figure 6-6: libc Contents, Internal Names without Synonyms

_cleanup _xftw _ _flsbuf _ _trwctype* _tolower _ _assert _ _iswctype* _ _ _errno*

_toupper _ _filbuf _ _thr _errno*


Of the routines listed in the table above, the following are not defined elsewhere.

void _cleanup(void); E

Functionally equivalent to fflush(NULL).

C Library 6-9



Page: 110



int _ _filbuf(FILE *f);

This fun ction retu rns the next inp ut character for f, filling its buffer as approp riate. _ _filbuf is intend ed to be called when its bu ffer is E

empty, as it will return the first character add ed to the buffer, wh at- E

ever the content of the bu ffer wh en the call to _ _filbuf is mad e. It

returns EOF if an error occurs.

int _ _flsbuf(int x, FILE *f);

This fun ction flushes the outp ut characters for f as if putc(x,f) had

been called and then app ends the value of x to the resulting outpu t

stream. It returns EOF if an error occur s and x otherwise.

int _xftw(int, char *, int (*)(char *, struct stat *, int), int);

Calls to the ftw function are map ped to this fun ction when app lica-

tions are comp iled. This fun ction is identical to ftw, except th at

_xftw() takes an interposed first argum ent, which m ust have the

value 2. M

int * _ _thr _errno(void); M

This function retur ns a pointer to the location of the thread -specific Merrno for a par ticular thread of control when mu ltiple thread s of con- M

trol are being used in a program . A ssignments to errno are map ped M

to this function wh en mu lti-threaded app lications are comp iled. M

int * _ _ _errno(void); M

Functionally equivalent to _ _thr _errno(void) described above.

int _ _iswctype(wint _t wc, wctype _t charclass);

This function retur ns 0 if the wide character repr esented by the M

wint _t argu men t is a mem ber of the wide character classification, M

charclass, or a non -zero value if it is not. It is the un der lying M

engine for the isw*macros and functions. M

wint _t _ _trwctype(wint _t wc, wctype _t charclass); MThis fun ction retu rns the valu e of the wide character wc, converted M

to the corresponding character class as d efined by charclass, or wc M

if no transform ation could be don e. It is the un der lying engine for M

the tow*macros and functions.

See this chapter’s other library sections for more SVID, ANSI C, and POSIX facili-

ties. See ‘‘System Data Inte rfaces’’ later in this chapter for more inform ation .

6-10 LIBRARIES



Page: 111



Additional Entry Points (Processor-Specific)

ABI-conforming systems m ust p rovide a libc entry p oint for each of the sour ce-

level services show n in the list below. The name and syntax of this entry point

may be the sam e as those characteristics of the source-level service or they may

vary across processor architectures. The actual names of the entry points are

specified in each processor’s supplemen t to the ABI, together w ith the entry

points’ syntax information if names d iffer from those of the sour ce-level services.

This information is for the use of system imp lementors and compiler writers, and

does not affect the source-level system interface used by ap plication p rogram mers.

Figure 6-7: libc Contents, Additional Services

fstat lstat mknod stat uname

NOTEThis section requires processor–specific information. Consequently, the ABI supplement for the desired processor describes the details.

NOTE

Because the ABI specifies neither the correspondence of system calls to trapsnor the formats of system data files, ABI–conforming programs access libcservices through dynamic linking.

See ‘‘System Data Interfaces’’ later in this chap ter for more information.

Support Routines (Processor-Specific)

NOTE

This section requires processor–specific information. The ABI supplement forthe desired processor describes the details.

C Library 6-11



Page: 112



Global Data Symbols

The libc library requires that som e global external data sym bols be defined for its

routines to work prop erly. All the data sym bols listed in the table below m ust be

provided by the libc library.

For formal declarations of the da ta objects repr esented by these symbo ls, see the X

X /Open CA E Specification, Issue 4.2 and the Syst em V Interface Definition, Fourth Edi-

tion (see the Conform ance Rule in chapter 1) or the ‘‘Data Definitions’’ section of

Chapter 6 in the approp riate processor sup plement to the System V ABI .

For entries in the following table that are in name - _name form, both sym bols in

each pair represent the same data. The underscore synonym s are provided to

satisfy the ANSI C stand ard . If the app lication references a weak symbol that has E

a global synonym, it mu st define both the weak symbol and the global synonym at E

the same ad dress. An AN SI C-conforming ap plication can d efine its own name

symbols, un related to th e X/Open CA E Specification, Issue 4.2 and the System V X

Interface Definition, Fourth Edition mean ings. If the app lication intend s those sym- X

bols to have the X/Open CA E Specification, Issue 4.2 and the System V Interface

Definition, Fourth Edition semantics, it must also define the _name symbols so that

both refer to the sam e data ob ject.

Figure 6-8: libc Contents, Global External Data Symbols

_ _ctype _getdate _err daylight loc2 optind

_ _iob _numeric errno locs optopt

_ _loc1 _timezone getdate _err optarg timezone

_altzone _tzname loc1 opterr tzname

_daylight altzone*

_ _xpg4 X


time _t _altzone;

This variable contains th e difference, in seconds, between Un iver-

sal Coordinated Time and th e alternate time zone, as established

with the function tzset. X

unsigned char _numeric[2];

This array hold s local-specific information , as established by the

function setlocale. Specifically, _numeric[0] holds the X

decimal-point character, and _numeric[1] holds the character

used to separate grou ps of digits to the left of the decimal-point

character in formatted non -monetary quantities. See the function X

localeconv for more information.

6-12 LIBRARIES



Page: 113



extern int _ _xpg4;

This variable’s value sp ecifies the execution environmen t for the

prog ram . If the value is 0 or unset, results are imp lementation-

specific. Otherw ise, if the value is 1, the ap plication w ill get Sys-

tem V Application Binary Interface, Edition 4.1 functionality. All

other values for _ _xpg4 are reserved for futu re use.

NOTE

Typically, _ _xpg4 being initialized to 0 or uninitialized would Xrepresent a backwards compatibility environment for SystemV Application Binary Interface, Fourth Edition applications.

Application Constraints

As described above, libc prov ides symbols for app lications. In a few cases, how -

ever, an app lication is obliged to pr ovide sym bols for the library.

extern char **environ;

Norm ally, this symbol is synonymous with environ, as the function Xexec describes. This isn’t always true, though, because ANSI C does

not define environ. Thus, an ANSI C-conforming ap plication can

define its own environ symbol, unrelated to the p rocess environ-

men t. If the application defin es environ and intends it to have the X

X/Open CA E Specification, Issue 4.2 and the System V Interface X

Definition, Fourth Edition seman tics (see the Conform ance Rule in X

chapter 1), it mu st also define _environ so that the two sym bols

refer to the sam e da ta object.

extern const int _lib _version;

This variable’s value specifies the compilation and execution m ode

for the program. If the value is zero, the program wan ts to preserve

the sem antics of older (pre-ANSI) C, where conflicts exist withANSI. Otherwise, the value is non-zero, and the program w ants

AN SI C seman tics.

C Library 6-13



Page: 114



Implementation of libc Routines

All ABI-conforming systems m ust p rovide a libc entry point for all routines

listed as belonging to this library. How ever, only the routines necessary to pro -

vide the source-level program ming interfaces defined in the X/Open CA E X

Specification, Issue 4.2 and d efined in the System V Interface Definition, Fourth Edition

sections BA _OS, BA _LIB, and KE _OS, as described in the introd uction to the Sys-

tem V ABI , must be implemented on a conforming system. For examp le, this

means that the routine memcntl(RT _OS) need not be fully implemented on an

ABI-conforming system, though the entry point for this function must be present

in the library.

Routines not required for the System V Interface Definition, Fourth Edition sections

listed above or X/Open CA E Specification, Issue 4.2 may or may not be imple- X

mented, at the discretion of the system implementor. Unimplemented routines E

mu st be represented in the library by a stub that wh en called causes failure and E

sets the the assignable lvalue errno to the value ENOSYS.

Vendor Extensions

Besides the services listed above, libc may contain other symbols. An ABI-

conforming system vendor m ay add a symbol to the C library to provide vendor-

specific services. The ABI does not d efine these services, and programs u sing

these services are not ABI-conforming. Nonetheless, the ABI defin es a recom- E

mend ed extension mechanism , providing a w ay to avoid conflict among the ser-

vices from multiple vendors.

A sym bol of the form _$vendor.company provides an op erating system entry for

the vendor named company . The C library does not have unad orned alternatives

for these names. Conventionally, a vend or uses the single name to p rovide mu lti-

ple services, letting the first argu men t to _$vendor.company select amon g thealternatives. As an examp le, the ‘‘XYZ Comp uter Com pan y’’ might ad d

_$vendor.xyz to the C library. M

6-14 LIBRARIES



Page: 115



Threads Library M

The Threads Library, libthread, contains interfaces supp orting mu ltithreaded M

app lications and asynchronous input/ outpu t wh ich are defined in the MT exten- M

sion of the System V Interface Definition, Fourth Edition. The mu ltithreading inter- M

faces in the SVID MT extension are seman tically similar to those found in the IEEE M

POSIX 1003.1c 1995 dr aft stand ard (former ly know n as 1003.4a or the Pthread s M

stand ard ), although the MT extension is more powerful in terms of the synchron i- M

zation and thread control interfaces prov ided . It is anticipated that a futu re ver- M

sion of the ABI and SVID will contain all interfaces in the comp leted POSIX mu l- M

tithreading standard . M

The following mu ltithreading fun ctions reside in libthread and mu st be pro- M

vided on all ABI-conforming systems. M

Figure 6-9: libthread Contents *, Part 1 of 2

barrier _destroy rmutex _unlock thr _getconcurrency

barrier _init rw _rdlock thr _getprio

barrier _wait rw _tryrdlock thr _getscheduler

cond _broadcast rw _trywrlock thr _getspecific

cond _destroy rw _unlock thr _join

cond _init rw _wrlock thr _keycreate

cond _signal rwlock _destroy thr _keydelete

cond _timedwait rwlock _init thr _kill

cond _wait sema _destroy thr _minstack

mutex _destroy sema _init thr _self

mutex _init sema _post thr _setconcurrency

mutex _lock sema _trywait thr _setprio

mutex _trylock sema _wait thr _setschedulermutex _unlock thr _continue thr _setspecific

rmutex _destroy thr _create thr _sigsetmask

rmutex _init thr _exit thr _suspend

rmutex _lock thr _get _rr _interval thr _yield

rmutex _trylock

* All fun ctions in this table are new to the Four th Edition of the ABI. M

The following fun ctions to sup port asynchronou s I/ O also reside in libthread M

and mu st be provided on all ABI-conforming systems. M




Page: 116



Figure 6-10: libthread Contents *, Part 2 of 2

aio _cancel aio _read aio _suspend lio _listio

aio _error aio _return aio _write


6-16 LIBRARIES



Page: 117



Dynamic Linking Library M

The Dynam ic Linking library, libdl, contains the library rou tines that provide the M

user direct access to the dynam ic linking facilities. The following functions reside M

in libdl and mu st be provided on all ABI-conforming systems. M

Figure 6-11: libdl Contents * M

dlclose dlerror dlopen dlsym M


Dynamic Linking Library 6-17



Page: 118



Network Services Library

The Netw ork Services library, libnsl, contains library routines that provide a

transp ort-level interface to n etwor king services for app lications, facilities for

machine-independ ent d ata representation, a rem ote procedure call mechanism,

and other netw orking services useful for app lication prog ram s. This library con- M

tains two sets of interfaces: one conforming to the Transp ort Level Interface (TLI) M

specification an d another to the X/Open Transport Interface (XTI) V ersion 2 M

specification . The TLI interface allows for binary compatibility with systems that M

conform to p revious ed itions of the ABI.

The following TLI conforming functions reside in libnsl and m ust be provided

on all ABI-conforming systems.

Figure 6-12: libnsl Contents, Part 1 of 3

t _accept t _listen t _rcvudatat _alloc t _look t _rcvuderr

t _bind t _open t _snd

t _close t _optmgmt t _snddis

t _connect t _rcv t _sndrel

t _error t _rcvconnect t _sndudata

t _free t _rcvdis t _sync

t _getinfo t _rcvrel t _unbind

t _getstate

The following XTI interfaces also reside in libnsl and mu st be provided on all M

ABI-conforming systems. M

Figure 6-13: libnsl Contents *, Part 2 of 3

_xti _accept _xti _getinfo _xti _rcvconnect

_xti _alloc _xti _getprotaddr _xti _rcvdis

_xti _bind _xti _getstate _xti _rcvrel

_xti _close _xti _listen _xti _rcvudata

_xti _connect _xti _look _xti _rcvuderr

_xti _error _xti _open _xti _snd

_xti _free _xti _rcv _xti _snddis

6-18 LIBRARIES



Page: 119



Figure 6-13: libnsl Contents *, Part 2 of 3 (continued )

_xti _sndrel _xti _strerror _xti _unbind

_xti _sndudata _xti _sync


In add ition, the following functions m ust be p rovided in libnsl on all ABI-

conforming systems with a n etworking capability. Systems with no n etworking

capability are not required to implement these functions, but m ust p rovide an

entry point into libnsl for each of the following function nam es. Functions that E

are present only as stubs and are not implemented mu st fail normally and per- E

form no action other setting the external errno variable to the value ENOSYS when

they are called by an app lication.

Figure 6-14: libnsl Contents, Part 3 of 3

authdes _getucred getpublickey rpc _broadcast _exp *

authdes _seccreate getsecretkey rpc _call

authnone _create host2netname rpc _reg

authsys _create key _decryptsession setnetconfig

authsys _create _default key _encryptsession setnetpath

clnt _create key _gendes svcerr _auth

clnt _dg _create key _setsecret svcerr _decode

clnt _pcreateerror nc _perror svcerr _noproc

clnt _perrno nc _sperror * svcerr _noprog

clnt _perror netdir _free svcerr _progvers

clnt _raw _create netdir _getbyaddr svcerr _systemerr

clnt _spcreateerror netdir _getbyname svcerr _weakauth

clnt _sperrno netdir _options svc _create

clnt _sperror netdir _perror * svc _dg _createclnt _tli _create netdir _sperror * svc _fd _create

clnt _tp _create netname2host svc _getreqset

clnt _vc _create netname2user svc _getreq _common*

endnetconfig rpcb _getaddr svc _getreq _poll *

endnetpath rpcb _getmaps svc _raw _create

freenetconfigent rpcb _gettime svc _reg

getnetconfig rpcb _rmtcall svc _run

getnetconfigent rpcb _set svc _sendreply

getnetname rpcb _unset svc _tli _create

getnetpath rpc _broadcast svc _tp _create




Page: 120



Figure 6-14: libnsl Contents, Part 3 of 3 (continued )

svc _unreg xdr _bytes xdr _rejected _reply

svc _vc _create xdr _callhdr xdr _replymsg

taddr2uaddr xdr _callmsg xdr _short

uaddr2taddr xdr _char xdr _string

user2netname xdr _double xdr _union

xdrmem _create xdr _enum xdr _u _char

xdrrec _create xdr _float xdr _u _int *

xdrrec _endofrecord* xdr _free xdr _u _long

xdrrec _eof xdr _int xdr _u _short

xdrrec _skiprecord * xdr _long xdr _vector

xdrstdio _create xdr _opaque xdr _void

xdr _accepted _reply xdr _opaque _auth xdr _wrapstring

xdr _array xdr _pointer xprt _register

xdr _authsys _parms xdr _reference xprt _unregister

xdr _bool


Figure 6-15: libnsl Contents, Global External Data Symbols

rpc _createerr svc _fdset t _errno _nderror

See ‘‘Data Definitions’’ later in this chap ter for m ore inform ation.

6-20 LIBRARIES



Page: 121



Socket Library

The socket library, libsocket, contains the socket functions as described in the X

Networking Services volume of the X/Open CA E Specification, Issue 4.2. This X

library is requ ired for all ABI-conforming systems. X

Figure 6-16: libsocket Contents, Part 1 of 2 X

accept listen sendmsg X

bind pool sendto X

connect recv setsockopt X

getpeername recvfrom shutdown X

getsockname recvmsg socket X

getsockopt send socketpair X

The socket library, libsocket, also contains these IP Ad dr ess Resolution func- X

tions as described in the Netw orking Services volume of the X/Open CAE X

Specification, Issue 4.2. X

X

Figure 6-18: libsocket Contents, Part 2 of 2 X

endhostent getprotobyname inet _makeaddr X

endnetent getprotobynumber inet _netof X

endprotoent getprotoent inet _network X

endservent getservbyname inet _ntoa X

gethostbyaddr getservbyport ntohl X

gethostbyname getservent ntohs Xgethostent htonl sethostent X

gethostname htons setnetent X

getnetbyaddr inet _addr setprotoent X

getnetbyname inet _lnaof setservent X

getnetent X

Socket Library 6-21



Page: 122



Curses Library

The curses library, libcurses, contains functions that up da te character screens as X

described in th e Curses volume of the X/Open CA E Specification, Issue 4.2. X

Figure 6-19: libcurses Contents X

addch getnstr mvgetnstr X

addchnstr getn _wstr mvgetn _wstr X

addchstr getparyx mvgetstr X

addnstr getstr mvget _wch X

addnwstr getwin mvget _wstr X

addstr getyx mvhline X

addwstr get _wch mvhline _set X

add _wch get _wstr mvinch X

add _wchnstr halfdelay mvinchnstr X

add _wchstr has _colors mvinchstr X

attroff has _ic mvinnstr X

attron has _il mvinnwstr X

attrset hline mvinsch X

attr _get hline _set mvinsnstr X

attr _off idcok mvinsstr X

attr _on idlok mvinstr X

attr _set immedok mvins _nwstr X

baudrate inch mvins _wch X

beep inchnstr mvins _wstr X

bkgd inchstr mvinwstr X

bkgdset initscr mvin _wch X

bkgrnd init _color mvin _wchnstr Xbkgrndset init _pair mvin _wchstr X

border innstr mvprintw X

border _set innwstr mvscanw X

box insch mvvline X

box _set insdelln mvvline _set X

can _change _color insertln mvwaddch X

cbreak insnstr mvwaddchnstr X

chgat insstr mvwaddchstr X

clear instr mvwaddnstr X

clearok ins _nwstr mvwaddnwstr X

6-22 LIBRARIES



Page: 123



Figure 6-19: libcurses Contents (continued ) X

clrtobot ins _wch mvwaddstr X

clrtoeol ins _wstr mvwaddwstr X

color _content intrflush mvwadd _wch X

copywin inwstr mvwadd _wchnstr X

curscr in _wch mvwadd _wchstr X

curs _set in _wchnstr mvwchgat X

cur _term in _wchstr mvwdelch X

def _prog _mode isendwin mvwgetch X

def _shell _mode is _linetouched mvwgetnstr X

delay _output is _wintouched mvwgetn _wstr X

delch keyname mvwgetstr X

deleteln keypad mvwget _wch X

delscreen key _name mvwget _wstr X

delwin killchar mvwhline X

del _curterm killwchar mvwhline _set X

derwin leaveok mvwin Xdoupdate longname mvwinch X

dupwin meta mvwinchnstr X

echo move mvwinchstr X

echochar mvaddch mvwinnstr X

echo _wchar mvaddchnstr mvwinnwstr X

endwin mvaddchstr mvwinsch X

erase mvaddnstr mvwinsnstr X

erasechar mvaddnwstr mvwinsstr X

erasewchar mvaddstr mvwinstr X

filter mvaddwstr mvwins _nwstr X

flash mvadd _wch mvwins _wch X

flushinp mvadd _wchnstr mvwins _wstr X

getbegyx mvadd _wchstr mvwinwstr Xgetbkgd mvchgat mvwin _wch X

getbkgrnd mvcur mvwin _wchnstr X

getcchar mvdelch mvwin _wchstr X

getch mvderwin mvwprintw X

getmaxyx mvgetch mvwscanw X

mvwvline slk _set wbkgdset X

mvwvline _set slk _touch wbkgrnd X

napms slk _wset wbkgrndset X

newpad standend wborder X

Curses Library 6-23



Page: 124




newterm standout wborder _set X

newwin start _color wchgat X

nl stdscr wclear X

no subpad wclrtobot X

nocbreak subwin wclrtoeol X

nodelay syncok wcursyncup X

noecho termattrs wdelch X

nonl termname wdeleteln X

noqiflush tgetent # wechochar X

noraw tgetflag # wecho _wchar X

notimeout tgetnum # werase X

overlay tgetstr # wgetbkgrnd X

overwrite tgoto# wgetch X

pair _content tigetflag wgetnstr X

pechochar tigetnum wgetn _wstr X

pecho _wchar tigetstr wgetstr Xpnoutrefresh timeout wget _wch X

prefresh touchline wget _wstr X

printw touchwin whline X

putp tparm whline _set X

putwin tputs winch X

qiflush typeahead winchnstr X

raw unctrl winchstr X

redrawwin ungetch winnstr X

refresh unget _wch winnwstr X

resetty untouchwin winsch X

reset _prog _mode use _env winsdelln X

reset _shell _mode vidattr winsertln X

restartterm vidputs winsnstr Xripoffline vid _attr winsstr X

savetty vid _puts winstr X

scanw vline wins _nwstr X

scrl vline _set wins _wch X

scroll vwprintw # wins _wstr X

scrollok vwscanw # winwstr X

scr _dump vw _printw win _wch X

scr _init vw _scanw win _wchnstr X

scr _restore waddch win _wchstr X

6-24 LIBRARIES



Page: 125




scr _set waddchnstr wmove X

setcchar waddchstr wnoutrefresh X

setscrreg waddnstr wprintw X

setupterm waddnwstr wredrawln X

set _curterm waddstr wrefresh X

set _term waddwstr wscanw X

slk _attroff wadd _wch wscrl X

slk _attron wadd _wchnstr wsetscrreg X

slk _attrset wadd _wchstr wstandend X

slk _attr _off wattroff wstandout X

slk _attr _on wattron wsyncdown X

slk _attr _set wattrset wsyncup X

slk _clear wattr _get wtimeout X

slk _init wattr _off wtouchln X

slk _label wattr _on wunctrl X

slk _noutrefresh wattr _set wvline Xslk _refresh wbkgd wvline _set X

slk _restore X


Figure 6-20: libcurses Contents, Global External Data Symbols

bit _attributes cur _strs strfnames X

boolcodes Mouse _status strnames X

boolfnames numcodes TABSIZE X

boolnames numfnames term _errno X

curs _errno numnames term _parm _err X

curs _parm _err outchcount ttytype X

cur _bools SP wcolor _set X

cur _nums strcodes X

Curses Library 6-25



Page: 126



X Window System Library E

The X Window System library, libX, contains library rou tines that pr ovide prim i- E

tives for the opera tion of the X Window System. This library is requ ired for all E

ABI-conforming systems that imp lement a grap hical window ing termina l inter- E

face. See Chapter 10 of the System V A BI , ‘‘Wind ow ing and Termin al Interfaces’’ E

for more information on wind owing software requirements on ABI-conforming E

systems. E

The following functions reside in libX and mu st be provided on all ABI- E

conforming systems. E

6-26 LIBRARIES



Page: 127



Figure 6-21: libX Contents

XActivateScreenSaver XCheckTypedEvent XcmsCIEXYZToCIELab

XAddExtension XCheckTypedWindowEvent XcmsCIEXYZToCIEuvY

XAddHost XCheckWindowEvent XcmsCIEXYZToCIExyY

XAddHosts XCirculateSubwindows XcmsCIEXYZToRGBi

XAddPixel XCirculateSubwindowsDown XcmsClientWhitePointOfCCC

XAddToExtensionList XCirculateSubwindowsUp XcmsConvertColors

XAddToSaveSet XClearArea XcmsCreateCCC

XAllocClassHint XClearWindow XcmsDefaultCCC

XAllocColor XClipBox XcmsDisplayOfCCC

XAllocColorCells XCloseDisplay XcmsFormatOfPrefix

XAllocColorPlanes XCloseIM XcmsFreeCCC

XAllocIconSize XcmsAddColorSpace XcmsLookupColor

XAllocNamedColor XcmsAddFunctionSet XcmsPrefixOfFormat

XAllocSizeHints XcmsAllocColor XcmsQueryBlack

XAllocStandardColormap XcmsAllocNamedColor XcmsQueryBlue

XAllocWMHints XcmsCCCofColormap XcmsQueryColorXAllowEvents XcmsCIELabClipab* XcmsQueryColors

XAllPlanes XcmsCIELabClipLab* XcmsQueryGreen

XAutoRepeatOff XcmsCIELabClipL* XcmsQueryRed

XAutoRepeatOn XcmsCIELabQueryMaxC XcmsQueryWhite

XBaseFontNameListOfFontSet XcmsCIELabQueryMaxL XcmsRGBiToCIEXYZ

XBell XcmsCIELabQueryMaxLC XcmsRGBiToRGB

XBitmapBitOrder XcmsCIELabQueryMinL XcmsRGBToRGBi

XBitmapPad XcmsCIELabToCIEXYZ XcmsScreenNumberOfCCC

XBitmapUnit XcmsCIELabWhiteShiftColors* XcmsScreenWhitePointOfCCC

XBlackPixel XcmsCIELuvClipLuv* XcmsSetCompressionProc

XBlackPixelOfScreen XcmsCIELuvClipL* XcmsSetWhiteAdjustProc

XCellsOfScreen XcmsCIELuvClipuv* XcmsSetWhitePoint

XChangeActivePointerGrab XcmsCIELuvQueryMaxC XcmsStoreColor

XChangeGC XcmsCIELuvQueryMaxL XcmsStoreColors

XChangeKeyboardControl XcmsCIELuvQueryMaxLC XcmsTekHVCClipC*

XChangeKeyboardMapping XcmsCIELuvQueryMinL XcmsTekHVCClipVC*

XChangePointerControl XcmsCIELuvToCIEuvY XcmsTekHVCClipV*

XChangeProperty XcmsCIELuvWhiteShiftColors* XcmsTekHVCQueryMaxC

XChangeSaveSet XcmsCIEuvYToCIELuv XcmsTekHVCQueryMaxV

XChangeWindowAttributes XcmsCIEuvYToCIEXYZ XcmsTekHVCQueryMaxVC

XCheckIfEvent XcmsCIEuvYToTekHVC XcmsTekHVCQueryMaxVSamples

XCheckMaskEvent XcmsCIExyYToCIEXYZ XcmsTekHVCQueryMinV




Page: 128



Figure 6-21: libX Contents (continued )

XcmsTekHVCToCIEuvY XDeleteContext XEmptyRegion

XcmsTekHVCWhiteShiftColors* XDeleteModifiermapEntry XEnableAccessControl

XcmsVisualOfCCC XDeleteProperty XEqualRegion

XConfigureWindow XDestroyIC XEventMaskOfScreen

XConnectionNumber XDestroyImage XEventsQueued

XContextDependentDrawing XDestroyRegion XExtentsOfFontSet

XConvertSelection XDestroySubwindows XFetchBuffer

XCopyArea XDestroyWindow XFetchBytes

XCopyColormapAndFree XDisableAccessControl XFetchName

XCopyGC XDisplayCells XFillArc

XCopyPlane XDisplayHeight XFillArcs

XCreateBitmapFromData XDisplayHeightMM XFillPolygon

XCreateColormap XDisplayKeycodes XFillRectangle

XCreateFontCursor XDisplayMotionBufferSize XFillRectangles

XCreateFontSet XDisplayName XFilterEvent

XCreateGC XDisplayOfIM XFindContextXCreateGlyphCursor XDisplayOfScreen XFindOnExtensionList*

XCreateIC XDisplayPlanes XFlush

XCreateImage XDisplayString XFlushGC

XCreatePixmap XDisplayWidth XFontsOfFontSet

XCreatePixmapCursor XDisplayWidthMM XForceScreenSaver

XCreatePixmapFromBitmapData XDoesBackingStore XFree

XCreateRegion XDoesSaveUnders XFreeColormap

XCreateSimpleWindow XDrawArc XFreeColors

XCreateWindow XDrawArcs XFreeCursor

XDefaultColormap XDrawImageString XFreeExtensionList

XDefaultColormapOfScreen XDrawImageString16 XFreeFont

XDefaultDepth XDrawLine XFreeFontInfo

XDefaultDepthOfScreen XDrawLines XFreeFontNames

XDefaultGC XDrawPoint XFreeFontPath

XDefaultGCOfScreen XDrawPoints XFreeFontSet

XDefaultRootWindow XDrawRectangle XFreeGC

XDefaultScreen XDrawRectangles XFreeModifiermap

XDefaultScreenOfDisplay XDrawSegments XFreePixmap

XDefaultString XDrawString XFreeStringList

XDefaultVisual XDrawString16 XGContextFromGC

XDefaultVisualOfScreen XDrawText XGeometry

XDefineCursor XDrawText16 XGetAtomName

6-28 LIBRARIES



Page: 129




XGetClassHint XGetWMName XLookupKeysym

XGetCommand XGetWMNormalHints XLookupString

XGetDefault XGetWMProtocols XLowerWindow

XGetErrorDatabaseText XGetWMSizeHints XMapRaised

XGetErrorText XGrabButton XMapSubwindows

XGetFontPath XGrabKey XMapWindow

XGetFontProperty XGrabKeyboard XMaskEvent

XGetGCValues XGrabPointer XMatchVisualInfo

XGetGeometry XGrabServer XMaxCmapsOfScreen

XGetIconName XHeightMMOfScreen XMaxRequestSize

XGetIconSizes XHeightOfScreen XmbDrawImageString

XGetICValues XIconifyWindow XmbDrawString

XGetImage XIfEvent XmbDrawText

XGetIMValues XImageByteOrder XmbLookupString

XGetInputFocus XIMOfIC XmbResetIC

XGetKeyboardControl XInitExtension XmbSetWMPropertiesXGetKeyboardMapping XInsertModifiermapEntry XmbTextEscapement

XGetModifierMapping XInstallColormap XmbTextExtents

XGetMotionEvents XInternAtom XmbTextListToTextProperty

XGetNormalHints XIntersectRegion XmbTextPerCharExtents

XGetPixel XKeycodeToKeysym XmbTextPropertyToTextList

XGetPointerControl XKeysymToKeycode XMinCmapsOfScreen

XGetPointerMapping XKeysymToString XMoveResizeWindow

XGetRGBColormaps XKillClient XMoveWindow

XGetScreenSaver XLastKnownRequestProcessed XNewModifiermap

XGetSelectionOwner XListDepths XNextEvent

XGetSizeHints XListExtensions XNextRequest

XGetStandardColormap XListFonts XNoOp

XGetSubImage XListFontsWithInfo XOffsetRegion

XGetTextProperty XListHosts XOpenDisplay

XGetTransientForHint XListInstalledColormaps XOpenIM

XGetVisualInfo XListPixmapFormats XParseColor

XGetWindowAttributes XListProperties XParseGeometry

XGetWindowProperty XLoadFont XPeekEvent

XGetWMClientMachine XLoadQueryFont XPeekIfEvent

XGetWMColormapWindows XLocaleOfFontSet XPending

XGetWMHints XLocaleOfIM Xpermalloc

XGetWMIconName XLookupColor XPlanesOfScreen




Page: 130




XPointInRegion XrmDestroyDatabase XSetAccessControl

XPolygonRegion XrmEnumerateDatabase XSetAfterFunction

XProtocolRevision XrmGetDatabase XSetArcMode

XProtocolVersion XrmGetFileDatabase XSetBackground

XPutBackEvent XrmGetResource XSetClassHint

XPutImage XrmGetStringDatabase XSetClipMask

XPutPixel XrmInitialize XSetClipOrigin

XQLength XrmLocaleOfDatabase XSetClipRectangles

XQueryBestCursor XrmMergeDatabases XSetCloseDownMode

XQueryBestSize XrmParseCommand XSetCommand

XQueryBestStipple XrmPermStringToQuark XSetDashes

XQueryBestTile XrmPutFileDatabase XSetErrorHandler

XQueryColor XrmPutLineResource XSetFillRule

XQueryColors XrmPutResource XSetFillStyle

XQueryExtension XrmPutStringResource XSetFont

XQueryFont XrmQGetResource XSetFontPathXQueryKeymap XrmQGetSearchList XSetForeground

XQueryPointer XrmQGetSearchResource XSetFunction

XQueryTextExtents XrmQPutResource XSetGraphicsExposures

XQueryTextExtents16 XrmQPutStringResource XSetICFocus

XQueryTree XrmQuarkToString XSetIconName

XRaiseWindow XrmSetDatabase XSetIconSizes

XReadBitmapFile XrmStringToBindingQuarkList XSetICValues

XRebindKeysym XrmStringToQuark XSetInputFocus

XRecolorCursor XrmStringToQuarkList XSetIOErrorHandler

XReconfigureWMWindow XrmUniqueQuark XSetLineAttributes

XRectInRegion XRootWindow XSetLocaleModifiers

XRefreshKeyboardMapping XRootWindowOfScreen XSetModifierMapping

XRemoveFromSaveSet XRotateBuffers XSetNormalHints

XRemoveHost XRotateWindowProperties XSetPlaneMask

XRemoveHosts XSaveContext XSetPointerMapping

XReparentWindow XScreenCount XSetRegion

XResetScreenSaver XScreenNumberOfScreen XSetRGBColormaps

XResizeWindow XScreenOfDisplay XSetScreenSaver

XResourceManagerString XScreenResourceString XSetSelectionOwner

XRestackWindows XSelectInput XSetSizeHints

XrmCombineDatabase XSendEvent XSetStandardColormap

XrmCombineFileDatabase XServerVendor XSetStandardProperties

6-30 LIBRARIES



Page: 131




XSetState XStoreName XUnmapWindow

XSetStipple XStoreNamedColor XUnsetICFocus

XSetSubwindowMode XStringListToTextProperty XVaCreateNestedList

XSetTextProperty XStringToKeysym XVendorRelease

XSetTile XSubImage XVisualIDFromVisual

XSetTransientForHint XSubtractRegion XWarpPointer

XSetTSOrigin XSupportsLocale XwcDrawImageString

XSetWindowBackground XSync XwcDrawString

XSetWindowBackgroundPixmap XSynchronize XwcDrawText

XSetWindowBorder XTextExtents XwcFreeStringList

XSetWindowBorderPixmap XTextExtents16 XwcLookupString

XSetWindowBorderWidth XTextPropertyToStringList XwcResetIC

XSetWindowColormap XTextWidth XwcTextEscapement

XSetWMClientMachine XTextWidth16 XwcTextExtents

XSetWMColormapWindows XTranslateCoordinates XwcTextListToTextProperty

XSetWMHints XUndefineCursor XwcTextPerCharExtentsXSetWMIconName XUngrabButton XwcTextPropertyToTextList

XSetWMName XUngrabKey XWhitePixel

XSetWMNormalHints XUngrabKeyboard XWhitePixelOfScreen

XSetWMProperties XUngrabPointer XWidthMMOfScreen

XSetWMProtocols XUngrabServer XWidthOfScreen

XSetWMSizeHints XUninstallColormap XWindowEvent

XShrinkRegion XUnionRectWithRegion XWithdrawWindow

XStoreBuffer XUnionRegion XWMGeometry

XStoreBytes XUnloadFont XWriteBitmapFile

XStoreColor XUnmapSubwindows XXorRegion

XStoreColors





Page: 132



The table below contains callback functions wh ich are well know n entry points in M

libX. These can be defin ed and used by ABI conforming app lications pr ovided M

that their defin ition and use complies with the X11R5 grap hical user interface M

specification. E

Figure 6-22: libX Contents, Callback Function Names

GeometryCallback PreeditDrawCallback StatusDrawCallback

PreeditCaretCallback PreeditStartCallback StatusStartCallback

PreeditDoneCallback StatusDoneCallback

The libX library requ ires that some global external da ta symbols be defin ed for its M

routines to work properly. All the data symbols listed in the table below must be M

provided by the libX library. M

For formal declarations of the da ta objects repr esented by these symbo ls, see the M

‘‘Data Definitions’’ section of Chap ter 6 in the app rop riate pr ocessor sup plem ent M

to the System V A BI . M

Figure 6-23: libX Contents *, Global External Data Symbols

XcmsCIELabColorSpace XcmsLinearRGBFunctionSet

XcmsCIELuvColorSpace XcmsRGBColorSpace

XcmsCIEuvYColorSpace XcmsRGBiColorSpace

XcmsCIExyYColorSpace XcmsTekHVCCColorSpace

XcmsCIEXYZColorSpace XcmsUNDEFINEDColorSpace


6-32 LIBRARIES



Page: 133



X11 Nonrectangular Window Shape Extension M

Library M

The X11 Nonrectangu lar Window Shap e Extension Library Version 1.0, libXext, M

contains library routines that prov ide mechan isms for changing the visible shap e M

of a window to an arbitrary, possibly disjoint, non rectangu lar form. This library is M

requ ired for all ABI-conforming systems that imp lement a grap hical window ing M

termina l interface. See Chap ter 10 of the System V A BI , ‘‘Windowing and Termi- M

nal Interfaces’’ for more information on window ing software requ irements on M

ABI-conforming systems. M

The following functions reside in libXext and mu st be provided on all ABI- M

conforming systems that implement a graph ical wind owing terminal interface. M

Figure 6-24: libXext Contents *

XShapeCombineMask XShapeGetRectangles XShapeQueryExtents

XShapeCombineRectangles XShapeInputSelected XShapeQueryVersion

XShapeCombineRegion XShapeOffsetShape XShapeSelectInput

XShapeCombineShape XShapeQueryExtension


X11 Nonrectangular Window Shape Extension Library 6-33



Page: 134



X Toolkit Intrinsics Library G

The X Toolkit Intrinsics library, libXt, contains library rou tines that pr ovide G

pr imitives for the opera tion of the X Toolkit Intrinsics of the X Window System. G

This library is requ ired for all ABI-conforming systems that implemen t a grap hical G

window ing terminal interface. See Chapter 10 of the System V A BI , ‘‘Windowing G

and Terminal Interfaces’’ for mor e information on window ing software requ ire- G

men ts on ABI-conforming systems. G

The following functions reside in libXt and mu st be provided on all ABI- G

conforming systems that implement a graphical wind owing terminal interface. G

6-34 LIBRARIES



Page: 135



Figure 6-25: libXt Contents

XtAddCallback XtCallbackExclusive XtCvtStringToFloat

XtAddCallbacks XtCallbackNone XtCvtStringToFont

XtAddEventHandler XtCallbackNonexclusive XtCvtStringToFontSet

XtAddExposureToRegion XtCallbackPopdown XtCvtStringToFontStruct

XtAddGrab XtCallbackReleaseCacheRef XtCvtStringToInitialState

XtAddRawEventHandler XtCallbackReleaseCacheRefList XtCvtStringToInt

XtAllocateGC XtCallCallbackList XtCvtStringToPixel

XtAppAddActionHook XtCallCallbacks XtCvtStringToShort

XtAppAddActions XtCallConverter XtCvtStringToTranslationTable

XtAppAddInput XtCalloc XtCvtStringToUnsignedChar

XtAppAddTimeOut XtClass XtCvtStringToVisual

XtAppAddWorkProc XtCloseDisplay XtDatabase

XtAppCreateShell XtConfigureWidget XtDestroyApplicationContext

XtAppError XtConvertAndStore XtDestroyWidget

XtAppErrorMsg XtConvertCase XtDisownSelection

XtAppGetErrorDatabase XtCreateApplicationContext XtDispatchEventXtAppGetErrorDatabaseText XtCreateManagedWidget XtDisplay

XtAppGetSelectionTimeout XtCreatePopupShell XtDisplayInitialize

XtAppInitialize XtCreateWidget XtDisplayOfObject

XtAppMainLoop XtCreateWindow XtDisplayStringConversionWarning

XtAppNextEvent XtCvtColorToPixel XtDisplayToApplicationContext

XtAppPeekEvent XtCvtIntToBool XtFindFile

XtAppPending XtCvtIntToBoolean XtFree

XtAppProcessEvent XtCvtIntToColor XtGetActionKeysym

XtAppReleaseCacheRefs XtCvtIntToFloat XtGetActionList

XtAppSetErrorHandler XtCvtIntToFont XtGetApplicationNameAndClass

XtAppSetErrorMsgHandler XtCvtIntToPixel XtGetApplicationResources

XtAppSetFallbackResources XtCvtIntToPixmap XtGetConstraintResourceList

XtAppSetSelectionTimeout XtCvtIntToShort XtGetGC

XtAppSetTypeConverter XtCvtIntToUnsignedChar XtGetKeysymTable

XtAppSetWarningHandler XtCvtStringToAcceleratorTable XtGetMultiClickTime

XtAppSetWarningMsgHandler XtCvtStringToAtom XtGetResourceList

XtAppWarning XtCvtStringToBool XtGetSelectionRequest

XtAppWarningMsg XtCvtStringToBoolean XtGetSelectionValue

XtAugmentTranslations XtCvtStringToCursor XtGetSelectionValueIncremental

XtBuildEventMask XtCvtStringToDimension XtGetSelectionValues

XtCallAcceptFocus XtCvtStringToDisplay XtGetSelectionValuesIncremental

XtCallActionProc XtCvtStringToFile XtGetSubresources




Page: 136



Figure 6-25: libXt Contents (continued )

XtGetSubvalues XtMoveWidget XtSetMappedWhenManaged

XtGetValues XtName XtSetMultiClickTime

XtGrabButton XtNameToWidget XtSetSensitive

XtGrabKey XtOpenDisplay XtSetSubvalues

XtGrabKeyboard XtOverrideTranslations XtSetTypeConverter

XtGrapPointer XtOwnSelection XtSetValues

XtHasCallbacks XtOwnSelectionIncremental XtSetWMColormapWindows

XtInitializeWidgetClass XtParent XtSuperclass

XtInsertEventHandler XtParseAcceleratorTable XtToolkitInitialize

XtInsertRawEventHandler XtParseTranslationTable XtTranslateCoords

XtInstallAccelerators XtPopdown XtTranslateKey

XtInstallAllAccelerators XtPopup XtTranslateKeycode

XtIsApplicationsShell* XtPopupSpringLoaded XtUngrabButton

XtIsComposite* XtQueryGeometry XtUngrabKey

XtIsConstraint* XtRealizeWidget XtUngrabKeyboard

XtIsManaged XtRealloc XtUngrabPointerXtIsObject XtRegisterCaseConverter XtUninstallTranslations

XtIsOverrideShell* XtRegisterGrabAction XtUnmanageChild

XtIsRealized XtReleaseGC XtUnmanageChildren

XtIsRectObj* XtRemoveActionHook XtUnmapWidget

XtIsSensitive XtRemoveAllCallbacks XtUnrealizeWidget

XtIsShell* XtRemoveCallback XtVaAppCreateShell

XtIsSubclass XtRemoveCallbacks XtVaAppInitialize

XtIsTopLevelShell* XtRemoveEventHandler XtVaCreateArgsList

XtIsTransientShell* XtRemoveGrab XtVaCreateManagedWidget

XtIsVendorShell XtRemoveInput XtVaCreatePopupShell

XtIsWidget* XtRemoveRawEventHandler XtVaCreateWidget

XtIsWMShell* XtRemoveTimeOut XtVaGetApplicationResources

XtKeysymToKeycodeList XtRemoveWorkProc* XtVaGetSubresources

XtLastTimestampProcessed XtResizeWidget XtVaGetSubvalues

XtMakeGeometryRequest XtResizeWindow XtVaGetValues

XtMakeResizeRequest XtResolvePathname XtVaSetSubvalues

XtMalloc XtScreen XtVaSetValues

XtManageChild XtScreenDatabase XtWidgetToApplicationContext

XtManageChildren XtScreenOfObject XtWindow

XtMapWidget XtSetKeyboardFocus XtWindowOfObject

XtMenuPopupAction* XtSetKeyTranslator XtWindowToWidget

XtMergeArgLists XtSetLanguageProc


6-36 LIBRARIES



Page: 137



The libXt library requ ires that some global external da ta objects be defin ed for G

the routines to work properly. The data symbols listed in the table below mu st be G

provided by the libXt library. G

For formal declarations of the data objects repr esented by these symbols, see the G

‘‘Data Definitions’’ section of Chap ter 6 in the app rop riate processor sup plemen t Gto the System V A BI . The nam es of those symbols not defin ed in the Processor G

Sup plement are reserved for the imp lementation of libXt. G

Figure 6-26: libXt Contents, Global External Data Symbols

applicationShellClassRec overrideShellClassRec transientShellWidgetClass

applicationShellWidgetClass overrideShellWidgetClass vendorShellClassRec

colorConvertArgs rectObjClass vendorShellWidgetClass

compositeClassRec rectObjClassRec widgetClass

compositeWidgetClass screenConvertArg widgetClassRec

constraintClassRec shellClassRec wmShellClassRec

constraintWidgetClass shellWidgetClass wmShellWidgetClass

coreWidgetClass topLevelShellClassRec XtShellStringsobjectClass topLevelShellWidgetClass XtStrings

objectClassRec transientShellClassRec

NOTE

The Data Symbols XtShellStrings and XtStrings may not be maintained Gin an upwardly compatible manner. Future treatment of these arrays may behandled differently on each platform.




Page: 138



Motif Libraries M

The libraries libXm an d libXMrm contains library routines that provide the M

Grap hical User Interface components of the Motif interface. The current version M

of Motif sup ported by the gABI is Motif 1.2 as defined in OSF’s Motif Program mer M

Reference Revision 1.2. This library is requ ired for all ABI-conforming system s M

that implem ent a grap hical window ing terminal interface. See Chap ter 10 of the M

System V A BI , ‘‘Windowing and Terminal Interfaces’’ for more information on M

window ing software requ irements on ABI-conforming systems. M

The following functions reside in libXm and mu st be provided on all ABI- M

conforming systems that implement a graphical wind owing terminal interface. M

6-38 LIBRARIES



Page: 139



Figure 6-27: libXm Contents *

XmActivateProtocol XmCreateDrawingArea

XmAddProtocolCallback XmCreateDrawnButton

XmAddProtocols XmCreateErrorDialog

XmAddTabGroup XmCreateFileSelectionBox

XmCascadeButtonGadgetHighlight XmCreateFileSelectionDialog

XmCascadeButtonHighlight XmCreateForm

XmChangeColor XmCreateFormDialog

XmClipboardCancelCopy XmCreateFrame

XmClipboardCopy XmCreateInformationDialog

XmClipboardCopyByName XmCreateLabel

XmClipboardEndCopy XmCreateLabelGadget

XmClipboardEndRetrieve XmCreateList

XmClipboardInquireCount XmCreateMainWindow

XmClipboardInquireFormat XmCreateMenuBar

XmClipboardInquireLength XmCreateMenuShell

XmClipboardInquirePendingItems XmCreateMessageBoxXmClipboardLock XmCreateMessageDialog

XmClipboardRegisterFormat XmCreateOptionMenu

XmClipboardRetrieve XmCreatePanedWindow

XmClipboardStartCopy XmCreatePopupMenu

XmClipboardStartRetrieve XmCreatePromptDialog

XmClipboardUndoCopy XmCreatePulldownMenu

XmClipboardUnlock XmCreatePushButton

XmClipboardWithdrawFormat XmCreatePushButtonGadget

XmCommandAppendValue XmCreateQuestionDialog

XmCommandError XmCreateRadioBox

XmCommandGetChild XmCreateRowColumn

XmCommandSetValue XmCreateScale

XmConvertUnits XmCreateScrollBar

XmCreateArrowButton XmCreateScrolledList

XmCreateArrowButtonGadget XmCreateScrolledText

XmCreateBulletinBoard XmCreateScrolledWindow

XmCreateBulletinBoardDialog XmCreateSelectionBox

XmCreateCascadeButton XmCreateSelectionDialog

XmCreateCascadeButtonGadget XmCreateSeparator

XmCreateCommand XmCreateSeparatorGadget

XmCreateDialogShell XmCreateSimpleCheckBox

XmCreateDragIcon XmCreateSimpleMenuBar




Page: 140



Figure 6-27: libXm Contents * (continued )

XmCreateSimpleOptionMenu XmFontListEntryGetTag

XmCreateSimplePopupMenu XmFontListEntryLoad

XmCreateSimplePulldownMenu XmFontListFree

XmCreateSimpleRadioBox XmFontListFreeFontContext

XmCreateTemplateDialog XmFontListGetNextFont

XmCreateText XmFontListInitFontContext

XmCreateTextField XmFontListNextEntry

XmCreateToggleButton XmFontListRemoveEntry

XmCreateToggleButtonGadget XmGetAtomName

XmCreateWarningDialog XmGetColorCalculation

XmCreateWorkArea XmGetColors

XmCreateWorkingDialog XmGetDestination

XmCvtCTToXmString XmGetDragContext

XmCvtStringToUnitType XmGetFocusWidget

XmCvtXmStringToCT XmGetMenuCursor

XmDeactivateProtocol XmGetPixmapXmDestroyPixmap XmGetPixmapByDepth

XmDragCancel XmGetPostedFromWidget

XmDragStart XmGetSecondaryResourceData

XmDropSiteConfigureStackingOrder XmGetTabGroup

XmDropSiteEndUpdate XmGetTearOffControl

XmDropSiteQueryStackingOrder XmGetVisibility

XmDropSiteRegister XmGetXmDisplay

XmDropSiteRetrieve XmGetXmScreen

XmDropSiteStartUpdate XmInstallImage

XmDropSiteUnregister XmInternAtom

XmDropSiteUpdate XmIsMotifWMRunning

XmDropTransferAdd XmIsTraversable

XmDropTransferStart XmListAddItem

XmFileSelectionBoxGetChild XmListAddItems

XmFileSelectionDoSearch XmListAddItemsUnselected

XmFontListAdd XmListAddItemUnselected

XmFontListAppendEntry XmListDeleteAllItems

XmFontListCopy XmListDeleteItem

XmFontListCreate XmListDeleteItems

XmFontListEntryCreate XmListDeleteItemsPos

XmFontListEntryFree XmListDeletePos

XmFontListEntryGetFont XmListDeletePositions

6-40 LIBRARIES



Page: 141




XmListDeselectAllItems XmRemoveProtocols

XmListDeselectItem XmRemoveTabGroup

XmListDeselectPos XmRepTypeAddReverse

XmListGetKbdItemPos XmRepTypeGetId

XmListGetMatchPos XmRepTypeGetNameList

XmListGetSelectedPos XmRepTypeGetRecord

XmListItemExists XmRepTypeGetRegistered

XmListItemPos XmRepTypeInstallTearOffModelConverter

XmListPosSelected XmRepTypeRegister

XmListPosToBounds XmRepTypeValidValue

XmListReplaceItems XmResolveAllPartOffsets

XmListReplaceItemsPos XmResolvePartOffsets

XmListReplaceItemsPosUnselected XmScaleGetValue

XmListReplaceItemsUnselected XmScaleSetValue

XmListReplacePositions XmScrollBarGetValues

XmListSelectItem XmScrollBarSetValuesXmListSelectPos XmScrolledWindowSetAreas

XmListSetAddMode XmScrollVisible

XmListSetBottomItem XmSelectionBoxGetChild

XmListSetBottomPos XmSetColorCalculation

XmListSetHorizPos XmSetFontUnit

XmListSetItem XmSetFontUnits

XmListSetKbdItemPos XmSetMenuCursor

XmListSetPos XmSetProtocolHooks

XmListUpdateSelectedList XmStringBaseline

XmListYToPos XmStringByteCompare

XmMainWindowSep1 XmStringCompare

XmMainWindowSep2 XmStringConcat

XmMainWindowSep3 XmStringCopy

XmMainWindowSetAreas XmStringCreate

XmMapSegmentEncoding XmStringCreateLocalized

XmMenuPosition XmStringCreateLtoR

XmMessageBoxGetChild XmStringCreateSimple

XmOptionButtonGadget XmStringDirectionCreate

XmOptionLabelGadget XmStringDraw

XmProcessTraversal XmStringDrawImage

XmRegisterSegmentEncoding XmStringDrawUnderline

XmRemoveProtocolCallback XmStringEmpty




Page: 142




XmStringExtent XmTextFieldInsert

XmStringFree XmTextFieldInsertWcs

XmStringFreeContext XmTextFieldPaste

XmStringGetLtoR XmTextFieldPosToXY

XmStringGetNextComponent XmTextFieldRemove

XmStringGetNextSegment XmTextFieldReplace

XmStringHasSubstring XmTextFieldReplaceWcs

XmStringHeight XmTextFieldSetAddMode

XmStringInitContext XmTextFieldSetEditable

XmStringLength XmTextFieldSetHighlight

XmStringLineCount XmTextFieldSetInsertionPosition

XmStringNConcat XmTextFieldSetMaxLength

XmStringNCopy XmTextFieldSetSelection

XmStringPeekNextComponent XmTextFieldSetString

XmStringSegmentCreate XmTextFieldSetStringWcs

XmStringSeparatorCreate XmTextFieldShowPositionXmStringWidth XmTextFieldXYToPos

XmTargetsAreCompatible XmTextFindString

XmTextClearSelection XmTextFindStringWcs

XmTextCopy XmTextGetBaseLine

XmTextCut XmTextGetBaseline

XmTextDisableRedisplay XmTextGetEditable

XmTextEnableRedisplay XmTextGetInsertionPosition

XmTextFieldClearSelection XmTextGetLastPosition

XmTextFieldCopy XmTextGetMaxLength

XmTextFieldCut XmTextGetSelection

XmTextFieldGetBaseline XmTextGetSelectionPosition

XmTextFieldGetEditable XmTextGetSelectionWcs

XmTextFieldGetInsertionPosition XmTextGetSource

XmTextFieldGetLastPosition XmTextGetString

XmTextFieldGetMaxLength XmTextGetStringWcs

XmTextFieldGetSelection XmTextGetSubstring

XmTextFieldGetSelectionPosition XmTextGetSubstringWcs

XmTextFieldGetSelectionWcs XmTextGetTopCharacter

XmTextFieldGetString XmTextInsert

XmTextFieldGetStringWcs XmTextInsertWcs

XmTextFieldGetSubstring XmTextPaste

XmTextFieldGetSubstringWcs XmTextPosToXY

6-42 LIBRARIES



Page: 143




XmTextRemove XmToggleButtonGadgetSetState

XmTextReplace XmToggleButtonGetState

XmTextReplaceWcs XmToggleButtonSetState

XmTextScroll XmTrackingEvent

XmTextSetAddMode XmTrackingLocate

XmTextSetEditable XmTranslateKey

XmTextSetHighlight XmUninstallImage

XmTextSetInsertionPosition XmUpdateDisplay

XmTextSetMaxLength XmVaCreateSimpleCheckBox

XmTextSetSelection XmVaCreateSimpleMenuBar

XmTextSetSource XmVaCreateSimpleOptionMenu

XmTextSetString XmVaCreateSimplePopupMenu

XmTextSetStringWcs XmVaCreateSimplePulldownMenu

XmTextSetTopCharacter XmVaCreateSimpleRadioBox

XmTextShowPosition XmWidgetGetBaselines

XmTextXYToPos XmWidgetGetDisplayRectXmToggleButtonGadgetGetState

* All fun ctions in this table are new to the Four th Edition of the ABI. The libXm library M

requ ires that some global external da ta objects be defin ed for the routines to work M

prop erly. The data symbols listed in the table below mu st be provided by the M

libXm library. M

For formal declarations of the data objects repr esented by these symbols, see the M

‘‘Data Definitions’’ section of Chap ter 6 in the app rop riate processor sup plemen t M

to the System V A BI . The nam es of those symbols not defin ed in the Processor M

Sup plement are reserved for the imp lementation of libXm. M




Page: 144



Figure 6-28: libXm Contents *, Global External Data Symbols

vendorShellClassRec xmExtObjectClass

vendorShellWidgetClass xmFileSelectionBoxClassRec

xmArrowButtonClassRec xmFileSelectionBoxWidgetClass

xmArrowButtonGadgetClass xmFormClassRec

xmArrowButtonGadgetClassRec xmFormWidgetClass

xmArrowButtonWidgetClass xmFrameClassRec

xmBulletinBoardClassRec xmFrameWidgetClass

xmBulletinBoardWidgetClass xmGadgetClass

xmCascadeButtonClassRec xmGadgetClassRec

xmCascadeButtonGadgetClass xmLabelClassRec

xmCascadeButtonGadgetClassRec xmLabelGadgetClass

xmCascadeButtonGCacheObjClassRec xmLabelGadgetClassRec

xmCascadeButtonWidgetClass xmLabelGCacheObjClassRec

xmCommandClassRec xmLabelWidgetClass

xmCommandWidgetClass xmListClassRec

xmDesktopClass xmListWidgetClassxmDesktopClassRec xmMainWindowClassRec

xmDialogShellClassRec xmMainWindowWidgetClass

xmDialogShellExtClassRec xmManagerClassRec

xmDialogShellExtObjectClass xmManagerWidgetClass

xmDialogShellWidgetClass xmMenuShellClassRec

xmDisplayClass xmMenuShellWidgetClass

xmDisplayClassRec xmMessageBoxClassRec

xmDragContextClass xmMessageBoxWidgetClass

xmDragContextClassRec xmPanedWindowClassRec

xmDragIconClassRec xmPanedWindowWidgetClass

xmDragIconObjectClass xmPrimitiveClassRec

xmDragOverShellClassRec xmPrimitiveWidgetClass

xmDragOverShellWidgetClass xmProtocolClassRec

xmDrawingAreaClassRec xmProtocolObjectClass

xmDrawingAreaWidgetClass xmPushButtonClassRec

xmDrawnButtonClassRec xmPushButtonGadgetClass

xmDrawnButtonWidgetClass xmPushButtonGadgetClassRec

xmDropSiteManagerClassRec xmPushButtonGCacheObjClassRec

xmDropSiteManagerObjectClass xmPushButtonWidgetClass

xmDropTransferClassRec XmQmotif

xmDropTransferObjectClass xmRowColumnClassRec

xmExtClassRec xmRowColumnWidgetClass

6-44 LIBRARIES



Page: 145



Figure 6-28: libXm Contents *, Global External Data Symbols (continued )

xmSashClassRec xmShellExtObjectClass

xmSashWidgetClass xmTearOffButtonClassRec

xmScaleClassRec xmTearOffButtonWidgetClass

xmScaleWidgetClass xmTextClassRec

xmScreenClass xmTextFieldClassRec

xmScreenClassRec xmTextFieldWidgetClass

xmScrollBarClassRec xmTextWidgetClass

xmScrollBarWidgetClass xmToggleButtonClassRec

xmScrolledWindowClassRec xmToggleButtonGadgetClass

xmScrolledWindowWidgetClass xmToggleButtonGadgetClassRec

xmSelectionBoxClassRec xmToggleButtonGCacheObjClassRec

xmSelectionBoxWidgetClass xmToggleButtonWidgetClass

xmSeparatorClassRec xmUseVersion

xmSeparatorGadgetClass xmVendorShellExtClassRec

xmSeparatorGadgetClassRec xmVendorShellExtObjectClass

xmSeparatorGCacheObjClassRec xmWorldClassxmSeparatorWidgetClass xmWorldClassRec

xmShellExtClassRec


The following functions reside in libMrm and mu st be provided on all ABI- M

conforming systems that implement a graph ical wind owing terminal interface. M

Figure 6-29: libMrm Contents *

MrmCloseHierarchy MrmFetchWidgetOverride

MrmFetchBitmapLiteral MrmInitialize

MrmFetchColorLiteral MrmOpenHierarchyMrmFetchIconLiteral MrmOpenHierarchyPerDisplay

MrmFetchLiteral MrmRegisterClass

MrmFetchSetValues MrmRegisterNames

MrmFetchWidget MrmRegisterNamesInHierarchy





Page: 146



System Data Interfaces

Standar d header files that d escribe system data a re available for C application

developers to use. These files are referred to by their nam e in angle brackets:

<name.h>, <sys/name.h> an d <X11/name.h>. Included in these headers are M

macro defin itions, da ta definitions, and fun ction declarations. The parts of the

head er files specified in the AN SI C stand ard are the only pa rts available to

strictly-conform ing AN SI C app lications. Similarly, only the p ortions of the

head er files defined in the POSIX P1003.1 Op erating System Standard are avail-

able to strictly POSIX-conforming app lications.

Some of the following h eader files define inter faces directly available to applica-

tions, and those interfaces will be common to system s on all processors. Other

header files show sp ecific imp lementations of stand ard interfaces, where the

implementation or data definitions might change from one p rocessor to another.

The ABI does not distingu ish between these files. It gives data defin itions to pro-

mote binar y app lication por tability, not to repeat sou rce interface definitionsavailable elsewh ere. System providers and app lication d evelopers should u se the

ABI to sup plemen t—not to replace—source interface defin ition docum ents.

NOTE

Some type and data definitions appear in multiple headers. Specialdefinitions are included in the headers to avoid conflicts.

The app lication execution environm ent pr esents the interfaces described below,

but the ABI does not requ ire the presence of the header files them selves. In other

words, an ABI-conforming system is not required to provide an application

development environment.

Required Sizes for Some Data Objects

The continued evolution of System V requires that some fun dam ental data objects

be expanded so that the op erating system w ill work m ore efficiently with systems

of different sizes and with netw orks of systems. To pr omote both binary portabil-

ity for app lications and interop erability for networ ks of systems, the System V A BI

requires that all conforming implementations use the expanded data object sizes

shown in the table below at a m inimum.

6-46 LIBRARIES



Page: 147



A given architecture m ay expan d on e or more of the following objects’ sizes, but

any su ch further expansion mu st be mad e explicit in the p rocessor supp lement to

the System V A BI for that processor architectur e. Further, the sizes in the table

below should be considered as absolute (not minimal) for pur poses of interopera-

tion among networks of heterogeneous systems.

Figure 6-30: Minimum Sizes of Fundamental Data Objects

Data Object Type Definition Size (bits) _ _______________________________________________User identifier uid _t 32

Group Identifier gid _t 32

Process identifier pid _t 32

Inode identifier ino _t 32

Device identifier dev _t 32

File system identifier dev _t 32

Error identifier int 32

Time time _t 32

File mod e indicator mode _t 32

Link count nlink _t 32 _ _______________________________________________

Data Definitions (Processor-Specific)

NOTE

This section requires processor-specific information. The ABI supplement forthe d esired processor describes the details.




Page: 148



7 FORMATS AND PROTOCOLS

Introduction 7-1

Archive File 7-2

Other Archive Formats 7-6



XDR: External Data Representation 7-10

XDR Data Types 7-11

Messaging Catalogues 7-22

RPC: Remote Procedure Call Protocol 7-22

Terminology 7-22

Transports and Semantics 7-22

Binding and Rendezvous Independence 7-23

Authentication 7-23

Programs and Procedures 7-24

Authentication 7-25

Program Number Assignment 7-25

Other Uses of the RPC Protocol 7-26

Batching 7-26

Broadcast RPC 7-26

The RPC Message Protocol 7-27

DES Authentication Protocol (in XDR language) 7-33

Record Marking Standard 7-36

Table of Contents i


386:adm.book:sum

Page: 149



rpcbind Mechanism 7-37



386:adm.book:sum

Page: 150



Introduction

This chap ter describes file and d ata formats and pr otocols that are visible to app li-

cations or that mu st be por table across System V imp lementations. Although the

system p rovides standard programs to man ipulate files in the formats described

here, portability is imp ortant enough to w arrant d escriptions of their formats.

This does not mean app lications are encouraged to circum vent the system p ro-

gram s and manipu late the files directly. Instead, it mean s an ABI for any target

processor architecture mu st provide the system programs and library rou tines for

manipu lating these file formats and implementing these protocols. Moreover,

those program s mu st accept formats compatible with the on es described h ere.

Some system file forma ts explicitly do not app ear in this chapter . For examp le,

the m oun t table file, traditionally called /etc/mnttab, is not a d ocumented for-

mat. For informa tion such as this, the system libraries described in Chap ter 6 pro-

vide functions that app lications may use to access the data. Programs that d ependon un documen ted formats—or that dep end on the existence of und ocumented

files—are not ABI-conforming. Other files, such as the passwor d file in

/etc/passwd, have formats defined in other documen ts. These cases therefore do

not ap pear in the ABI, because the ABI does not rep licate information available in

other standard s documents. Nonetheless, an ABI-conforming program may u se

the files when th e file nam es and form ats are defin ed imp licitly for the ABI

through references to other d ocuments.

Introduction 7-1



Page: 151



Archive File

Archives package mu ltiple files into one. They are comm only used as libraries of

relocatable object files to be searched by the link ed itor. An archive file has the fol-

lowing format:

An archive magic string, ARMAG below;

An op tional archive symbol table (created only if at least one mem ber is an

object file that d efines non-local symbols);

An op tional archive string table (created only if at least one ar chive

mem ber’s nam e is more than 15 bytes long);

For each ‘‘norm al’’ file in the archive, an archive h eader and the u nchanged

contents of the file.

The archive file’s m agic string contains SARMAG bytes and d oes not include a ter-

minating nu ll byte.

Figure 7-1: <ar.h>

#define ARMAG "!<arch>\n"

#define SARMAG 8

#define ARFMAG "‘\n"

struct ar _hdr {

char ar _name[16];

char ar _date[12];

char ar _uid[6];

char ar _gid[6];

char ar _mode[8];

char ar _size[10];

char ar _fmag[2];

};

All information in the mem ber head ers is printable ASCII.

ar _name This mem ber represents the mem ber’s file name. If the nam e fits,

it resides in the m ember d irectly, termina ted w ith slash (/) and

pad ded with blanks on the right. If the member’s name is too

long to fit, the member contains a slash, followed by th e decimal

repr esentation of the name’s offset in the archive string table.

7-2 FORMATS AND PROTOCOLS



Page: 152



ar _date This member holds the decimal representation of the

mod ification d ate of the file at the time of its insertion into the

archive. Stat an d time describe the mod ification time value. X

ar _uid This member holds the decimal representation of the member’s

user identification nu mber.ar _gid This member holds the decimal representation of the member’s

group identification number.

ar _mode This member h olds the octal representation o f the file system

mode.

ar _size This member holds the decimal representation of the member’s

size in bytes.

ar _fmag This member holds the first tw o bytes of the ARFMAG string,

defined above.

Each m ember begins on an even byte bound ary; a newline is inserted between

files if necessary. Nevertheless the ar _size mem ber reflects the actual size of the

mem ber exclusive of pad ding. There is no provision for empty areas in an archive

file.

If some archive m ember’s name is mor e than 15 bytes long, a special archive

mem ber contains a table of file nam es, each followed by a slash and a newline.

This string table m ember, if pr esent, w ill precede all ‘‘norm al’’ archive m embers.

The special archive symbol table is not a ‘‘norm al’’ mem ber, and mu st be first if it

exists (see below ). The ar _name entry of the string table’s mem ber header holds a

zero length nam e (ar _name[0]= =’/’), followed by one trailing slash

(ar _name[1]= =’/’), followed by blanks (ar _name[2]= =’ ’, and so on). Offsets

into the string table begin at zero. Example ar _name values for short an d long file

names app ear below.

Offset +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 _ ____________________________________________________0 f i l e n a m e s a _ ____________________________________________________10 m p l e / \n l o n g _ ____________________________________________________20 e r f i l e n a m e _ ____________________________________________________30 x a m p l e / \n _ ____________________________________________________

Archive File 7-3



Page: 153



Figure 7-2: Example String Table

Member N ame ar _name Note _ ____________________________________________________________short-name short-name/ Not in string table

filenamesample /0 Offset 0 in string tablelongerfilenamexample /16 Offset 16 in string table _ ____________________________________________________________

If an ar chive file has one or m ore object file members, its first mem ber w ill be an

archive symbol table. This archive member has a zero length n ame, followed by

blanks (ar _name[0]= =’/’, ar _name[1]= =’ ’, and so on). All words in this

symbol table have four bytes, using the machine-independ ent encoding shown

below.

NOTE

All machines use the encoding described here for the symbol table, even if themachine’s ‘‘natural’’ byte order is different.

Figure 7-3: Archive Word Encoding

010

021

032

043

0x01020304

The symbol table holds the following:

A w ord containing the n um ber of symbols in the symbol table (wh ich is the

same as the number of entries in the file offset array);

An arr ay of word s, holding file offsets into the archive;

The string table containing ar _size-4*(number symbols+1) bytes, whose

initial byte is num bered 0 and wh ose last byte holds a 0 value.

Entries in the string table and in the file offset array exactly correspond to each

other, and they both parallel the order of archive members. Thus if two or more

archive m embers define symbols with the sam e nam e (which is allowed ), their

string table entries will appear in the same ord er as their correspond ing mem bers

in the archive file. Each array entry associates a symbol with the archive member

that d efines the sym bol; the file offset is the location of the archive head er for the

designated archive member.




Page: 154



As an examp le, the following symbol table defines 4 symbols. The archive

mem ber at file offset 114 defin es name an d object. The archive member at file

offset 426 defines function and a second version of name.

Figure 7-4: Example Symbol Table

Offset +0 +1 +2 +3 _ ____________________0 4 4 offset ent ries _ ____________________4 114 name _ ____________________8 114 object _ ____________________

12 426 function _ ____________________16 426 name _ ____________________20 n a m e _ ____________________24 \0 o b j _ ____________________28 e c t \0 _ ____________________32 f u n c _ ____________________

36 t i o n _ ____________________40 \0 n a m _ ____________________44 e \0 _ ____________________

Archive File 7-5



Page: 155



Other Archive Formats

ABI-conforming system s supp ort archives created by the cpio command. These

archives are comm only u sed a s a veh icle for collecting ASCII files for storage or

transmission.

For more information abou t these archives see the cpio manu al page in the X

X /Open CA E Specification, Issue 4.2 and the Syst em V Interface Definition, Fourth Edi- X

tion (see the Conform ance Rule in chap ter 1). The format of the archives the com-

mand creates is includ ed in th e IEEE POSIX P1003.1 specification. Also sup por ted E

are archives in the ASC/ CRC format, created u sing th e cpio command with the E

‘‘-H crc’’ option .




Page: 156



Terminfo Data Base

Each terminal’s capabilities are stored in a sepa rate file nam ed

/usr/share/lib/terminfo/ L/terminal _name, where terminal _name is the name of the terminal, and L is the first letter of the terminal’s name. The specific capabili-

ties described in th e database and their names are given in the System V Interface

Definition, Fourth Edition on the terminfo(TI _ENV) pages. The form at of this file

is given in the separate section that follows.

The terminfo database format is hardw are-independ ent. An 8-bit byte is

assum ed. Short integers are stored in two contiguous 8-bit bytes. The first byte

contains the least significant 8 bits of the value, and th e second byte contains the

most significant 8 bits. (Thu s, the value represented is 256∗second+first.) The

value –1 is represented by 0377, 0377, and the value –2 is represented by 0376,

0377; other negative values are illegal. Comp uters where this does not

correspond to the hardw are read the integers as two bytes and comp ute the result,

mak ing the compiled entries portable across machine types. A –1 or a –2 in acapability field m eans that th e capability is missing from a term inal.

The file contains six sections:

head er The head er contains six short integers in the format described

below. These integers are (1) the magic nu mber (octal 0432);

(2) the size, in by tes, of the nam es section; (3) the nu mber of

bytes in the boolean section; (4) the num ber of short integers in

the num bers section; (5) the num ber of offsets (short integer s)

in the strings section; (6) the size, in bytes, of the string table.

termina l nam es The termina l nam es section contains the first line of the

terminfo(TI _ENV) description, listing the va rious names for

the terminal, separated by the ’|’ character. The section is ter-minated with an ASCII NUL character.

boolean flags The boolean flags contain one byte for each flag. This byte is

either 0 or 1 to indicate wheth er a capability is present or

absent. The terminal capabilities are stored here in the same

order in w hich that are listed un der the Booleans heading of

the capability table in the terminfo(TI _ENV) section of the

System V Interface Definition, Fourth Edition. The flag value of 2

means that the flag is invalid.




Page: 157



Between th e boolean section and the nu mber section, a null

byte will be inserted, if necessary, to insure that th e number

section begins on a byte with an even-num bered add ress. All

short integers are aligned on a short w ord bou nd ary.

nu mbers The nu mbers section is similar to the pr eceding boolean flagssection. Each capability is stored in tw o bytes as a short

integer. Terminal capabilities are stored here in the same ord er

in which they are listed u nd er the Numbers heading of the

capability table in the terminfo(TI _ENV) section of the System

V Interface Definition, Fourth Edition. If the value represented is

–1 or –2, the capability is m issing.

strings In the strings section, each capability is stored as a short

integer, in the same format given for preceding section. Termi-

nal capabilities are stored here in the same ord er in wh ich they

are listed und er the Strings head ing of the capability table in

the terminfo(TI _ENV) section of the System V Interface

Definition, Fourth Edition. A value of –1 or –2means that a

capability is missing. Otherw ise, the value is taken as an offset

from the beginning of the string table. ∗

string table The final section is the string table. It contains all the values of

string capabilities referenced in th e string section. Each capa - bility is stored as a nu ll termina ted string. Special characters in ˆX or \ notation are stored in their interpreted form, not the printing representation. Padd ing information ($<nn>) and param eter information (%x) are stored intact in uninterpreted form.

As an examp le, an octal dum p of the compiled d escription for an AT&T Model 37

KSR is included :




Page: 158



37|tty37|AT&T model 37 teletype,

hc, os, xon,

bel=ˆG, cr=\r, cub1=\b, cud1=\n, cuu1=\E7, hd=\E9,

hu=\E8, ind=\n,

0000000 032 001 \0 032 \0 013 \0 021 001 3 \0 3 7 | t0000020 t y 3 7 | A T & T m o d e l

0000040 3 7 t e l e t y p e \0 \0 \0 \0 \0

0000060 \0 \0 \0 001 \0 \0 \0 \0 \0 \0 \0 001 \0 \0 \0 \0

0000100 001 \0 \0 \0 \0 \0 377 377 377 377 377 377 377 377 377 377

0000120 377 377 377 377 377 377 377 377 377 377 377 377 377 377 & \0

0000140 \0 377 377 377 377 377 377 377 377 377 377 377 377 377 377

0000160 377 377 " \0 377 377 377 377 ( \0 377 377 377 377 377 377

0000200 377 377 0 \0 377 377 377 377 377 377 377 377 - \0 377 377

0000220 377 377 377 377 377 377 377 377 377 377 377 377 377 377 377 377

*

0000520 377 377 377 377 377 377 377 377 377 377 377 377 377 377 $ \0

0000540 377 377 377 377 377 377 377 377 377 377 377 377 377 377 * \0

0000560 377 377 377 377 377 377 377 377 377 377 377 377 377 377 377 377*

0001160 377 377 377 377 377 377 377 377 377 377 377 377 377 377 3 7

0001200 | t t y 3 7 | A T & T m o d e

0001220 l 3 7 t e l e t y p e \0 \r \0

0001240 \n \0 \n \0 007 \0 \b \0 033 8 \0 033 9 \0 033 7

0001260 \0 \0

0001261

Some limitations: total compiled entries cannot exceed 4096 bytes and all entries in

the nam e field cannot exceed 128 bytes.




Page: 159



Formats and Protocols for Networking

This section describes a language for machine-independent data representation

and two p rotocols used in rem ote procedu re call service. All ABI-conforming sys-

tems that provide th ese services mu st implement these formats and protocols in

the app ropriate routines in the libnsl library. See Chapter 6 of the System V A BI

for a list of the rou tines in this library.

XDR: External Data Representation

XDR is a method for the description and encoding of data . It is useful for transfer-

ring data between different computer architectures, where such characteristics as

internal byte-ordering m ay vary.

XDR uses a langu age to describe da ta formats. This langu age allows one to

describe intricate da ta formats in a concise man ner.

The XDR language assum es that bytes (or octets) are portable, where a byte is

defined to be 8 bits of data. A given hardw are device should encode the bytes

onto the various media in such a way that other hard ware d evices may decode the

bytes without loss of meaning.

Basic Block Size

The repr esentation of all items requ ires a mu ltiple of four bytes (or 32 bits) of da ta.

The bytes are num bered 0 through n-1. The bytes are read or written to some byte

stream such that byte m alw ays precedes byte m+1. If the n bytes needed to con-

tain the data are n ot a mu ltiple of four, then the n bytes are followed by enough (0

to 3) residu al zero bytes, r, to make the total byte count a m ultiple of 4.

The familiar graphic box notation has been used for illustration and comparison.

In most illustrations, each box (delimited by a p lus sign at the 4 corners and verti-

cal bars and d ashes) dep icts a byte. Ellipses (. . .) between boxes show zer o or

more ad ditional bytes where required.

A Block

+--------+--------+...+--------+--------+...+--------+

| byte 0 | byte 1 |...|byte n-1| 0 |...| 0 |

+--------+--------+...+--------+--------+...+--------+

|<-----------n bytes---------->|<------r bytes------>|

|<-----------n+r (where (n+r) mod 4 = 0)>----------->|




Page: 160



XDR Data Types

Each of the sections that follow d escribes a data type d efined in the XDR language,

show s how it is declared in th e language, and includes a graph ic illustra tion of its

encoding.

For each defined d ata type we show a general parad igm declaration. Note thatangle brackets (< an d >) denote variable length sequences of data and square

brackets ([ and ]) den ote fixed -length sequ ences of da ta. ‘‘n’’, ‘‘m’’ and ‘‘r’’ denote

integers. For the full langu age specification and m ore form al definitions of terms

such as ‘‘iden tifier’’ and ‘‘declaration ,’’ refer to ‘‘The XDR Langu age

Specification’’ , given in the Syst em V Interface Definition, Fourth Edition.

For some data types, more specific examples are included below.

Integer

An XDR signed integer is a 32-bit datu m that encodes an integer in the ran ge

[-2147483648,2147483647]. The integer is represented in tw o’s comp lemen t nota-

tion. The most and least significant bytes are 0 and 3, respectively. Integers are

declared as follows:

Integer

(MSB) (LSB)

+-------+-------+-------+-------+

|byte 0 |byte 1 |byte 2 |byte 3 |

+-------+-------+-------+-------+

<------------32 bits------------>

Unsigned Integer

An XDR un signed integer is a 32-bit datu m that encodes a nonn egative integer in

the range [0,4294967295]. It is represented by an unsigned binary num ber wh ose

most and least significant bytes are 0 and 3, respectively. An unsigned integer is

declared as follows:

Unsigned In teger

(MSB) (LSB)

+-------+-------+-------+-------+


+-------+-------+-------+-------+

<------------32 bits------------>




Page: 161



Enumeration

Enumerations have the same representation as signed integers. Enumerations are

han dy for describing subsets of the integers. Enum erated d ata is declared as fol-

lows:

enum { name-identifier = constant, . . . } identifier;

For example, the three colors red, yellow, and blu e could be described by an

enumerated type:

enum { RED = 2, YELLOW = 3, BLUE = 5 } colors;

It is an error to encode as an enu m an y other integer than those that have been

given assignments in the enu m declaration.

Boolean

Booleans are important enou gh and occur frequently enough to warran t their own

explicit type in the language. Booleans are declared as follows:

bool identifier;

This is equivalent to:

enum { FALSE = 0, TRUE = 1 } identifier;

Floating-point

XDR defin es the floa ting-point d ata typ e ‘‘float’’ (32 bits or 4 bytes). The encoding

used is the IEEE standard for normalized single-precision floating-point numbers.

The following th ree fields describe the single-precision floating-po int number:

S: The sign of the nu mber. Values 0 and 1 repr esent positive and

negative, respectively. One bit.

E: The exponen t of the nu mber, base 2. 8 bits are devoted to this

field. The expon ent is biased by 127.

F: The fractional par t of the nu mber’s man tissa, base 2. 23 bits are

devoted to th is field.

Therefore, the floating-point number is described by:

(-1)**S * 2**(E-Bias) * 1.F

It is declared as follows:




Page: 162



Sin gle-Precision Floating-Point

+-------+-------+-------+-------+


S| E | F |

+-------+-------+-------+-------+1|<- 8 ->|<-------23 bits------>|

<------------32 bits------------>

Just as the most an d least significant bytes of a num ber are 0 and 3, the most and

least significant bits of a single-precision floating- point nu mber ar e 0 and 31. The

beginning bit (and most sign ificant bit) offsets of S, E, and F are 0, 1, and 9, respec-

tively. Note tha t these num bers refer to the mathem atical positions of the bits,

and NOT to their actual physical locations (wh ich vary from med ium to medium ).

The IEEE specifications shou ld be consu lted concerning the encoding for signed

zero, signed infinity (overflow), and denorm alized nu mbers (underflow ). Accord-

ing to IEEE specifications, the ‘‘NaN’’ (not a nu mber) is system d ependen t and

should not be u sed externally.

Double-precision Floating-point

XDR defines the encod ing for the dou ble-precision floating- point data typ e ‘‘dou -

ble’’ (64 bits or 8 bytes). The encoding used is the IEEE stand ard for norm alized

dou ble-precision floating-point nu mber s. XDR encodes the following three fields,

which describe the double-precision floating-point number:

S: The sign of the nu mber. Values 0 and 1 repr esent positive and

negative, respectively. One bit.

E: The exponen t of the nu mber, base 2. 11 bits are devoted to this

field. The exponent is biased by 1023.

F: The fractional par t of the nu mber ’s man tissa, base 2. 52 bits are

devoted to th is field.

Therefore, the floating-point number is described by:

(-1)**S * 2**(E-Bias) * 1.F

It is declared as follows:




Page: 163



Double-Precision Floating-Point

+------+------+------+------+------+------+------+------+

|byte 0|byte 1|byte 2|byte 3|byte 4|byte 5|byte 6|byte 7|

S| E | F |

+------+------+------+------+------+------+------+------+1|<--11-->|<-----------------52 bits------------------->|

<-----------------------64 bits------------------------->

Just as the most and least significant bytes of a nu mber are 0 and 3, the most and

least significant bits of a doub le-pr ecision floating- point num ber are 0 and 63.

The beginning bit (and most sign ificant bit) offsets of S, E , and F are 0, 1, and 12,

respectively. No te that these nu mbers refer to the mathematical positions of the

bits, and NO T to their actual physical locations (wh ich vary from med ium to

medium).

The IEEE specifications shou ld be consu lted concerning the encoding for signed

zero, signed infinity (overflow), and denorm alized nu mbers (underflow ). Accord-

ing to IEEE specifications, the ‘‘NaN’’ (not a nu mber) is system d epend ent an d

should not be u sed externally.

Fixed-length Opaque Data

At times, fixed-length u ninterpreted d ata needs to be passed among m achines.

This data is called ‘‘opaque’’ and is declared as follows:

opaqu e identifier[n];

where the constan t n is the (static) nu mber of bytes necessary to contain the

opaque d ata. If n is not a mu ltiple of four, then the n bytes are followed by

enou gh (0 to 3) residual zero bytes, r, to make the total byte coun t of the opaque

object a mu ltiple of four.

Fixed-Length Opaque

0 1 ...

+--------+--------+...+--------+--------+...+--------+

| byte 0 | byte 1 |...|byte n-1| 0 |...| 0 |

+--------+--------+...+--------+--------+...+--------+

|<-----------n bytes---------->|<------r bytes------>|

|<-----------n+r (where (n+r) mod 4 = 0)------------>|

Variable-length Opaque Data

XDR also prov ides for variable-length (counted ) opaqu e data, defin ed as a

sequence of n (nu mbered 0 through n-1) arbitrary bytes to be the nu mber n

encoded as an unsigned integer (as described below), and followed by the n bytes

of the sequence.




Page: 164



Byte m of the sequen ce always pr ecedes byte m+1 of the sequence, and byte 0 of

the sequence always follows the sequence’s length (coun t). If n is not a mu ltiple of

four, the the n bytes are followed by enou gh (0 to 3) residu al zero bytes, r, to make

the total byte count a mu ltiple of four . Variable-length opaque data is declared in

the following way:

opaqu e identifier<m>;

or

opaqu e identifier<>;

The constant m d enotes an upp er bound of the nu mber of bytes that the sequence

may contain. If m is not specified, as in the second d eclaration, it is assum ed to be

(2**32) - 1, the maximum length. The constant m w ould norm ally be foun d in a

pro tocol specification. For examp le, a filing p rotocol may state that the m aximum

data transfer size is 8192 bytes, as follows:

opaqu e filedata<8192>;

This can be illustrated as follows:

Variable-Length Opaque

0 1 2 3 4 5 ...

+-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+

| length n |byte0|byte1|...| n-1 | 0 |...| 0 |

+-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+

|<-------4 bytes------->|<------n bytes------>|<---r bytes--->|

|<----n+r (where (n+r) mod 4 = 0)---->|

It is an error to encode a length greater than the m aximu m d escribed in the

specification.

String

XDR defines a string of n (num bered 0 through n-1) ASCII bytes to be the num bern encoded as an u nsigned integer (as described above), and followed by the n

bytes of the string. Byte m of the string always pr ecedes byte m+1 of the string,

and byte 0 of the string alw ays follows the string ’s length. If n is not a m ultiple of

four, then th e n bytes are followed by enou gh (0 to 3) residu al zero bytes, r, to

make the total byte coun t a mu ltiple of four. Coun ted byte strings are declared as

follows:

string object<m>;

or

string object<>;




Page: 165



The constant m d enotes an upp er bound of the nu mber of bytes that a string m ay

contain. If m is not specified, as in the second d eclaration, it is assum ed to be

(2**32) - 1, the m aximum length. The constant m w ould norm ally be foun d in a

pr otocol specification. For examp le, a filing p rotocol may state that a file name

can be no longer than 255 bytes, as follows:

string filename<255>;

Which can be illustrated as:

A String

0 1 2 3 4 5 ...

+-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+

| length n |byte0|byte1|...| n-1 | 0 |...| 0 |

+-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+

|<-------4 bytes------->|<------n bytes------>|<---r bytes--->|

|<----n+r (where (n+r) mod 4 = 0)---->|

It is an error to encode a length greater than the m aximu m d escribed in thespecification.

Fixed-length Array

Declarations for fixed-length arrays of hom ogeneou s elemen ts are in the following

form:

type-name identifier[n];

Fixed-length arrays of elements nu mbered 0 through n-1 are encoded by individu -

ally encoding th e elemen ts of the array in their natu ral order, 0 throu gh n-1. Each

element’s size is a mu ltiple of four bytes. Though all elements are of the same

type, the elements may have different sizes. For examp le, in a fixed-length arr ay

of strings, all elements are of ‘‘type string,’’ yet each element w ill vary in its

length.

Fixed-Length Array

+---+---+---+---+---+---+---+---+...+---+---+---+---+

| element 0 | element 1 |...| element n-1 |

+---+---+---+---+---+---+---+---+...+---+---+---+---+

|<--------------------n elements------------------->|




Page: 166



Variable-length Array

Counted arrays provid e the ability to encode variable-length arrays of hom ogene-

ous elements. The array is encoded as the element count n (an unsigned integer)

followed by the encod ing of each of the array ’s elements, starting with elemen t 0

and p rogressing throu gh element n- 1. The declaration for variable-length arrays

follows th is form :

type-name identifier<m>;

or

type-name identifier<>;

The constant m sp ecifies the maximu m acceptable element count of an arr ay; if m

is not specified, as in the second declaration, it is assumed to be (2**32) - 1.

Counted Array

0 1 2 3

+--+--+--+--+--+--+--+--+--+--+--+--+...+--+--+--+--+

| n | element 0 | element 1 |...|element n-1|+--+--+--+--+--+--+--+--+--+--+--+--+...+--+--+--+--+

|<-4 bytes->|<--------------n elements------------->|

It is an error to encode a value of n th at is greater than the maximum described in

the sp ecification.

Structure

Structures are d eclared as follows:

struct {

component-declaration-A;

component-declaration-B;...

} identifier;

The components of the structure are encoded in the ord er of their declaration in

the structu re. Each comp onent’s size is a mu ltiple of four bytes, though th e com-

pon ents may be d ifferent sizes.




Page: 167



Structure

+-------------+-------------+...

| component A | component B |...

+-------------+-------------+...

Discriminated Union

A d iscriminated un ion is a type composed of a discriminant followed by a type

selected from a set of prearran ged typ es accord ing to the value of the discrim-

inant. The typ e of discriminant is either ‘‘int,’’ ‘‘un signed int,’’ or an enu merated

typ e, such as ‘‘bool’’. The comp onen t types are called ‘‘arm s’’ of the union, and

are preceded by the value of the d iscriminant w hich imp lies their encoding.

Discriminated unions are declared as follows:

union switch (discriminant-declaration) {

case discriminant-value-A:

arm-declaration-A;case discriminant-value-B:

arm-declaration-B;

...

default: default-declaration;

} identifier;

Each ‘‘case’’ keyword is followed by a legal value of the d iscriminan t. The default

arm is optiona l. If it is not specified, then a valid encoding of the un ion cannot

take on unspecified discriminant values. The size of the imp lied arm is always a

multiple of four bytes.

The discriminated union is encoded as its discriminant followed by the encoding

of the imp lied arm .

Discriminated Union

0 1 2 3

+---+---+---+---+---+---+---+---+

| discriminant | implied arm |

+---+---+---+---+---+---+---+---+

|<---4 bytes--->|




Page: 168



Void

An XDR void is a 0-byte quantity. Voids are useful for describing operations that

take no data as inpu t or no data as outpu t. They are also useful in un ions, wh ere

some arms m ay contain d ata and others do not. The declaration is simply as fol-

lows:

void;

Voids are illustra ted a s follows:

++

++

--><-- 0 bytes

Constant

The data d eclaration for a constant follows this form :

const name-identifier = n;

‘‘const’’ is used to d efine a symbolic nam e for a constan t; it does not d eclare any

data. The symbolic constant may be u sed anyw here a regular constant may be

used . For examp le, the following d efines a symbolic constant DOZEN, equal to

12.

const DOZEN = 12;

Typedef

‘‘"typedef’’ does not declare any d ata either, but serves to d efine new identifiers

for declaring da ta. The syntax is:

typedef declaration;

The new type nam e is actually the variable nam e in the d eclaration p art of thetyped ef. For example, the following d efines a new type called ‘‘eggbox’’ using an

existing typ e called ‘‘egg’’:

typedef egg eggbox[DOZEN];

Variables declared u sing the new typ e name h ave the same type as the new type

name w ould h ave in the typedef, if it was considered a variable. For examp le, the

following two d eclarations a re equ ivalent in d eclaring the variable ‘‘fresheggs’’:

eggbox fresheggs;

egg fresheggs[DOZEN];




Page: 169



When a typedef involves a struct, enum, or union d efinition, there is another (pre-

ferred) syntax that may be used to d efine the same type. In general, a typedef of

the following form:

typedef <<struct, union, or enum definition>> identifier;

may be converted to the alternative form by r emov ing the ‘‘typed ef’’ par t andplacing the identifier after the ‘‘struct,’’ ‘‘union,’’ or ‘‘enum’’ keyword, instead of

at the end . For example, here are the two w ays to define the type ‘‘bool’’:

typedef enum { /* using typedef */

FALSE = 0,

TRUE = 1

} bool;

enum bool { /* preferred alternative */

FALSE = 0,

TRUE = 1

};

The reason this syntax is pr eferred is one does not have to w ait until the end of a

declaration to figure out the nam e of the new type.

Optional-data

Optional-data is one kind of union that occurs so frequently that w e give it a spe-

cial syntax of its own for declaring it. It is declared a s follows:

type-nam e *identifier;

This is equivalent to the following union:

union switch (bool opted) {

case TRUE:

type-name element;

case FALSE:

void;

} identifier;

It is also equivalent to the following var iable-length ar ray d eclaration, since the

boolean ‘‘opted ’’ can be interp reted a s the length of the array :

type-name identifier<1>;




Page: 170



Optional-data is not so interesting in itself, but it is very useful for describing

recursive data-structures such as linked -lists and trees. For examp le, the follow-

ing d efines a type ‘‘stringlist’’ that encodes lists of arbitrary length strings:

struct *stringlist {

string item<>;

stringlist next;

};

It could have been equivalently declared as the following u nion:

union stringlist switch (bool opted) {

case TRUE:

struct {

string item<>;

stringlist next;

} element;case FALSE:

void;

};

or as a variable-length arr ay:

struct stringlist<1> {

string item<>;

stringlist next;

};

Both of these d eclarations obscur e the intention of the stringlist type, so the

optiona l-da ta declaration is pr eferred over both of them . The optional-data type

also has a close correlation to how r ecursive data stru ctures are represen ted in

high-level langu ages such as Pascal or C by use of pointers. In fact, the syntax is

the same as that of the C language for pointers. E




Page: 171



Messaging Catalogues E

An ABI conforming imp lementation w ill includ e the gencat utility to convert the E

source of XPG3 conforming source message catalogues into a form un der stand - E

able by the run-time system. Applications that attempt to provide message catalo- E

gues in any other format are not ABI conforming .

RPC: Remote Procedure Call Protocol

This section specifies the protocol to be used in th e remote p rocedu re call package

implemented by rou tines in the libnsl library described in Chapter 6. The proto-

col is specified w ith the external da ta repr esentation (XDR) langu age pa rtly

described in the p receding section of the System V A BI .

Terminology

This section d iscusses servers, services, programs, pr ocedur es, clients, and ver-

sions. A server is a piece of software wh ere network services are implemen ted. A

netw ork service is a collection of one or more rem ote programs. A remote pr o-

gram imp lements one or more remote procedur es; the procedures, their parame-

ters, and resu lts are documen ted in the specific program ’s protocol specification

(see the rpcbind protocol, below, for an examp le). Netw ork clients are pieces of

software that initiate remote pr ocedure calls to services. A server may sup port

more than one version of a remote program in order to be forward compatible

with changing protocols.

Transports and Semantics

The RPC pro tocol is indep end ent of transp ort protocols. That is, RPC does not

care how a message is passed from one process to anoth er. The protocol dealsonly with specification and interpretation of messages.

It is important to p oint out that RPC does not try to imp lement any kind of relia-

bility and that the ap plication m ust be aw are of the type of transport p rotocol

un dern eath RPC. If it know s it is run ning on top of a reliable transpor t such as

TCP/ IP, then most of the work is already d one for it. On the other han d, if it is

run ning on top of an un reliable transport such as UDP/ IP, it must implement is

own retransmission and time-out p olicy as the RPC layer d oes not provide this

service.

Because of transp ort independ ence, the RPC protocol does not attach specific

seman tics to the remote procedu res or their execution . Seman tics can be inferred

from (but should be explicitly specified by) the underlying transport p rotocol. For

example, consider RPC running on top of an u nreliable transport such as UDP/ IP.




Page: 172



If an ap plication retransm its RPC messages after short time-outs, the on ly thing it

can infer if it receives no rep ly is that the procedure w as executed zero or m ore

times. If it does receive a reply, then it can infer that the p rocedure was executed

at least once.

A server may w ish to remember previously granted requests from a client and notregran t them in order to insu re some degree of execute-at-most-once seman tics. A

server can d o this by taking ad vantage of the transaction ID that is packaged w ith

every RPC request. The main u se of this transaction is by the client RPC layer in

matching rep lies to requests. How ever, a client app lication may choose to reuse

its pr evious transaction ID when retran smitting a request. The server app lication,

know ing this fact, may choose to remem ber this ID after granting a requ est and

not regran t requests w ith the same ID in order to achieve some degree of execute-

at-most-once seman tics. The server is not allowed to examine this ID in any other

way except as a test for equa lity.

On th e other han d, if using a reliable transport such as TCP/ IP, the app lication

can infer from a rep ly message that the p rocedu re was executed exactly once, but

if it receives no reply message, it cannot assume the rem ote procedu re was not

executed . No te that even if a connection-oriented p rotocol like TCP is used, an

app lication still needs time-outs and reconnection to hand le server crashes.

There are other possibilities for transp orts besides datag ram - or connection-

oriented p rotocols. For examp le, a request-reply p rotocol such as VMTP is

perhap s the most natu ral transport for RPC.

Binding and Rendezvous Independence

The act of bind ing a client to a service is NOT part of the remote p rocedu re call

specification. This important and necessary function is left up to some higher-

level software. (The software m ay use RPC itself—see the rpcbind protocol, below).

Implementors should think of the RPC protocol as the jum p-subroutine instruc-

tion ("JSR") of a netw ork; the load er (binder ) makes JSR useful, and the load er

itself uses JSR to accomp lish its task. Likewise, the netw ork m akes RPC useful,

using RPC to accomplish this task.

Authentication

The RPC protocol prov ides the fields necessary for a client to iden tify itself to a

service and vice-versa. Security and access control mechan isms can be built on top

of the message au thentication. Several different au thentication protocols can be

supp orted. A field in the RPC header indicates which protocol is being used.

More information on specific authentication protocols can be found in the Authen-

tication Protocols, below.




Page: 173



Programs and Procedures

The RPC call message has three u nsigned fields: remote p rogram n um ber, remote

program version number, and remote procedu re number. The three fields

un iquely identify the procedu re to be called. Program nu mbers are adm inistered

by some central authority. Once an imp lementor has a program num ber, he canimplement his remote p rogram; the first implementation w ould most likely have

the version nu mber of 1. Because most new pr otocols evolve into better, stable,

and matu re protocols, a version field of the call message iden tifies which version

of the protocol the caller is using. Version nu mbers make speaking old and new

protocols through the same server process possible.

The procedu re num ber identifies the procedu re to be called. These nu mbers are

documen ted in the specific prog ram ’s protocol specification. For examp le, a file

service’s pr otocol specification may state that its pr ocedure nu mber 5 is ‘‘read ’’

and procedur e nu mber 12 is ‘‘write’’.

Just as remote program protocols may change over several versions, the actual

RPC message protocol could also change. Therefore, the call message also has in it E

the RPC version nu mber, wh ich is equal to two for the version of RPC described Ehere.

The reply message to a request message has enough information to d istinguish the

following error conditions:

1 . The remote imp lementation of RPC does not speak the requested protocol E

version num ber. The lowest and highest supp orted RPC version num bers E

are returned.

2 . The remote prog ram is not available on the remote system.

3 . The remote program does not sup port the requested version num ber. The

lowest and highest sup ported remote program version nu mbers are

returned.

4 . The requested p rocedu re num ber does not exist. (This is usually a caller

side protocol or programm ing error.)

5 . The parameters to the remote procedu re app ear to be garbage from the

server’s point of view. (Again, this is usu ally caused by a disagreem ent

abou t the protocol between client and service.)

The remote imp lementation of RPC sup por ts protocol version 2. E




Page: 174



Authentication

Provisions for auth entication of caller to service and vice-versa are p rovided as a

par t of the RPC protocol. The call message has two authentication fields, the

credentials and verifier. The reply message has one auth entication field, the

respon se verifier. The RPC protocol specification defin es all three fields to be thefollowing opaqu e type:

enum auth _flavor {

AUTH _NULL = 0,

AUTH _SYS = 1,

AUTH _DES = 3

/* and more to be defined */

};

struct opaque _auth {

auth _flavor flavor;

opaque body<400>;

};

An y opaque _auth structure is an auth _flavor enum eration followed by bytes

wh ich are op aque to the RPC protocol implementation.

The interpretation an d semantics of the d ata contained within the authentication

fields is specified by ind ividu al, ind epend ent au thentication protocol

specifications. (See Authentication Protocols, below, for definitions of the various

authentication protocols.)

If auth entication param eters were rejected, the response m essage contains infor-

mation stating wh y they w ere rejected.

Program Number Assignment

Program nu mbers are given out in group s of 0x20000000 (decimal 536870912)

accord ing to the following chart:




Page: 175



_ __________________________________________________Program Numbers Description _ __________________________________________________

0 - 1fffffff Defined by a central authority

20000000 - 3fffffff Defined by user

40000000 - 5fffffff Transient

60000000 - 7fffffff Reserved

80000000 - 9fffffff Reserved

a0000000 - bfffffff Reserved

c0000000 - dfffffff Reserved

e0000000 - ffffffff Reserved _ __________________________________________________

The first group is a range of nu mbers adm inistered by a central authority and

shou ld be iden tical for all sites. The second range is for app lications peculiar to a

particular site. This range is intended primarily for debugging n ew p rograms.

When a site develops an app lication that m ight be of general interest, that app lica-

tion should be given an assigned n um ber in the first range. The third group is for

app lications that generate program num bers dynam ically. The final groups are

reserved for future use, and shou ld not be used.

Other Uses of the RPC Protocol

The intended u se of this protocol is for calling rem ote procedu res. That is, each

call message is matched w ith a response m essage. How ever, the protocol itself is a

message-passing p rotocol with wh ich other (non -RPC) protocols can be imple-

mented. Here are two examples:

Batching

Batching allows a client to send an ar bitrarily large sequence of call messages to a

server; batching typically uses reliable byte stream pr otocols (like TCP/ IP) for its

transp ort. In the case of batching, the client never w aits for a reply from the

server, and the server does not send rep lies to batch requests. A sequence of batchcalls is usually terminated by a legitimate RPC in ord er to flush the p ipeline (with

positive acknowledgement).

Broadcast RPC

In broad cast RPC-based p rotocols, the client send s a broad cast packet to the net-

work and w aits for nu merou s replies. Broad cast RPC uses un reliable, packet-

based pr otocols (like UDP/ IP) as its transports. Servers that supp ort broadcast

pr otocols only respon d w hen the request is successfully processed, and are silent

in the face of errors. Broad cast RPC uses the rpcbind service to achieve its

seman tics. See the rpcbind protocol, below, for more informa tion.




Page: 176



The RPC Message Protocol

This section d efines the RPC m essage protocol in the XDR data d escription

language. The message is defined in a top-down style.

enum msg _type {

CALL = 0,

REPLY = 1

};

/*

* A reply to a call message can take on two forms:

* The message was either accepted or rejected.

*/

enum reply _stat {

MSG _ACCEPTED = 0,

MSG _DENIED = 1

};

/*

* Given that a call message was accepted, the following is the

* status of an attempt to call a remote procedure.

*/

enum accept _stat {

SUCCESS = 0, /* RPC executed su ccessfully */

PROG _UNAVAIL = 1, /* remote hasn’t exported program */

PROG _MISMATCH = 2, /* remote can’t su pport version # */

PROC _UNAVAIL = 3, /* program can’t support procedure */

GARBAGE _ARGS = 4 /* procedure can’t decode params */

};

/*

* Reasons why a call message was rejected:

*/

enum reject _stat {

RPC _MISMATCH = 0, /* RPC version number != 2*/

AUTH _ERROR = 1 /* remote can’t authenticate caller */

};

/*

* Why authentication failed:

*/

enum auth _stat {

AUTH _BADCRED = 1, /* bad credentials */

AUTH _REJECTEDCRED = 2, /* client must begin new session */

AUTH _BADVERF = 3, /* bad verifier */

AUTH _REJECTEDVERF = 4, /* verifier expired or replayed */

AUTH _TOOWEAK = 5 /* rejected for security reasons */

};

(continued on next page )




Page: 177



/*

* Body of a reply to an RPC request:

* The call message was either accepted or rejected.

*/

union reply _body switch (reply _stat stat) {

case MSG _ACCEPTED:

accepted _reply areply;

case MSG _DENIED:

rejected _reply rreply;

} reply;

/*

* Reply t o an RPC request that was accepted by the server:

* there could be an error even though the request was accepted.

* The first field is an aut hentication verifier that the server

* generates in order to validate itself to the caller. It is

* followed by a union whose discriminant is an enum

* accept _stat. TheSUCCESS arm of the union is protocol

* specific. The PROG _UNAVAIL , PROC _UNAVAIL , and GARBAGE _ARGP

* arms of the union are void. The PROG _MISMATCH arm specifies

* the lowest and highest version num bers of the remote program

* supported by the server.

*/

struct accepted _reply {

opaque _auth verf;

union switch (accept _stat stat) {

case SUCCESS:

opaque results[0];

/* procedure-specific result s start here */

case PROG _MISMATCH:

struct {

unsigned int low;

unsigned int high;

} mismatch _info;

default:

/*

* Void. Cases include PROG _UNAVAIL, PROC _UNAVAIL ,

* and GARBAGE _ARGS

.*/

void;

} reply _data;

};





Page: 179



/*

* Reply to an RPC request t hat was rejected by t he server:

* The request can be rejected for two reasons: either the

* server is not run ning a compatible version of t he RPC

* protocol (RPC _MISMATCH), or the server refuses to

* authenticate the caller (AUTH _ERROR). In case of an RPC

* version mismatch, the server returns the lowest and highest

* supported RPC version numbers. In case of refused

* authent ication, failure status is retu rned.

*/

union rejected _reply switch (reject _stat stat) {

case RPC _MISMATCH:

struct {

unsigned int low;

unsigned int high;

} mismatch _info;

case AUTH _ERROR:

auth _stat stat;

};

Authentication Protocols

As previously stated, authentication p arameters are opaque, but op en-ended to

the rest o f the RPC pr otocol. This section d efines som e ‘‘flavors’’ of auth entication

wh ich are already implemented. Oth er sites are free to invent new authentication

types, with the same rules of flavor num ber assignmen t as there is for p rogram

number assignment.

Null Authentication

Often calls mu st be made w here the caller does not know wh o he is or the server

does not care who the caller is. In this case, the flavor value (the discriminant of

the opaque _auth’s un ion) of the RPC message’s creden tials, verifier, and respon se

verifier is AUTH _NULL. The bytes of the opaqu e _auth’s body are und efined. It isrecomm ended that the opaque length be zero.

Basic Authentication for UNIX Systems

The callers of a remote p rocedu re may w ish to iden tify them selves as they are

identified on a UN IX system. The value of the creden tial’s discriminant of an RPC

call message is AUTH _SYS. The bytes of the credential’s opaqu e body encode the following structure:




Page: 180



struct authsys _parms { u _long aup _time; char *aup _machname; uid _t aup _uid;

gid _t aup _gid; u _int aup _len; gid _t *aup _gids;

};

The aup _machname is the nam e of the caller’s machine (like ‘‘krypton’’). The

aup _uid is the caller’s effective user ID. The aup _gid is the caller’s effective

group ID. The aup _gids is a coun ted arr ay of groups wh ich contain the caller as a

member. The verifier accomp anying the credentials should be of AUTH _NULL

(defined above).

The value of the discriminant of the response verifier received in the rep ly mes-

sage from the server may be AUTH _NULL.

DES Authentication

Basic authentication for UNIX systems su ffers from tw o ma jor p roblems:

1 . The nam ing is oriented for UN IX systems.

2 . There is no verifier, so credentials can easily be faked .

DES authentication attempts to fix these two problems.

Naming

The first problem is hand led by addr essing the caller by a simple string of charac-

ters instead of by an op erating system sp ecific integer. This string of characters is

know n as the ‘‘netname’’ or netw ork nam e of the caller. The server is not allowed

to interpr et the contents of the caller’s nam e in any other way except to identifythe caller. Thus, netnam es shou ld be unique for every caller in the naming

domain.

It is up to each operating system’s imp lementation of DES auth entication to gen -

erate netnames for its users that insure this un iqueness when they call up on

remote servers. Operating systems already know how to distinguish u sers local to

their systems. It is usually a simp le matter to extend th is mechan ism to the net-

work. For examp le, a user w ith a user ID of 515 might be assigned the following

netname: ‘‘un ix.515@sun .com’’. This netnam e contains th ree items th at serve to

insure it is un ique. Going backward s, there is only one naming d omain called

‘‘sun .com’’ in the internet. Within this dom ain, there is only one user w ith user ID

515. How ever, there may be another user on an other operating system w ithin the

same nam ing domain th at, by coincidence, happ ens to have the same user ID. To




Page: 181



insure that these two u sers can be d istinguished w e add the operating system

nam e. So one user is ‘‘un ix.515@sun .com’’ and the oth er could be

‘‘vm s.515@su n.com ’’.

The first field is actually a naming m ethod rather than an operating system nam e.

It just happens that today there is almost a one-to-one correspondence betweennaming m ethods and op erating systems. If the world could agree on a naming

standard , the first field could be the name of that stand ard, instead of an operating

system nam e.

DES Authentication Verifiers

Unlike auth entication for UN IX systems, DES auth entication does have a verifier

so the server can v alidate the client’s credential (and v ice-versa). The contents of

this verifier is prim arily an encrypted tim estamp . The server can decryp t this

timestamp , and if it is close to what the real time is, then th e client mu st have

encryp ted it correctly. The only way th e client could encrypt it correctly is to

know the ‘‘conversation key’’ of the RPC session. And if the client knows th e

conversation key, then it m ust be the real client.

The conversation key is a DES key which the client genera tes and notifies the

server of in its first RPC call. The conversation key is encrypted using a p ub lic key

scheme in this first transaction. The particular pu blic key schem e used in DES

au thentication is Diffie-Hellman with 192-bit keys. The details of this encryption

method are described later.

The client and th e server need the same notion of the current time in ord er for all

of this to wor k. If netw ork time synchronization cannot be guaran teed, then client

can synchronize with the server before beginning the conversation.

The way a server d etermines if a client timestamp is valid is somewh at compli-

cated. For any other transaction but the first, the server just checks for two things:

1 . The timestamp is greater than the one p reviously seen from the same client.

2 . The timestamp h as not expired.

A timestam p is expired if the server’s time is later than the su m of the client’s

timestamp plus what is know n as the client’s "window ". The ‘‘wind ow’’ is a

nu mber the client passes (encryp ted) to the server in its first transaction. It can be

thou ght of as a lifetime for the cred ential.

This explains everything bu t the first transaction. In the first transaction, the

server checks only that the timestamp has not expired . If this was all that w as

don e though, then it w ould be qu ite easy for the client to send ran dom data in

place of the timestamp with a fairly good chance of succeeding. As an add ed

check, the client send s an encrypted item in the first transaction know n as the

‘‘wind ow verifier’’ which m ust be equ al to the w indow minus 1, or the server will

reject the credential.




Page: 182



The client too mu st check the verifier retu rned from the server to be su re it is legi-

timate. The server sends back to the client the encrypted tim estamp it received

from the client, minu s one second . If the client gets anything d ifferent than this, it

w ill reject it.

Nicknames and Clock SynchronizationAfter the first transaction, the server’s DES auth entication su bsystem retu rns in its

verifier to th e client an integer ‘‘nickname’’ which the client may use in its further

transactions instead of passing its netname, encrypted DES key and wind ow every

time. The nickname is most likely an index into a table on the server wh ich stores

for each client its netname, decrypted DES key and w indow .

Though they originally were syn chronized , the client’s and server’s clocks can get

out of sync again. When th is hap pen s the client RPC subsystem m ost likely will

get back RPC _AUTHERROR at w hich p oint it should resynchronize.

A client m ay still get the RPC _AUTHERROR error even thou gh it is synchronized

with the server. The reason is that the server’s nicknam e table is a limited size,

and it may flush entries whenever it wants. A client should resend its original

credential in this case and th e server will give it a new n icknam e. If a server

crashes, the entire nicknam e table gets flushed , and a ll clients will have to resend

their original credentials.

DES Authentication Protocol (in XDR language)

/*

* There are two kinds of credentials: one in which the client uses

* its full network name, and one in which it uses its "nickname"

* (just an un signed integer) given to it by the server. The

* client must use its fullname in its first transaction with the

* server, in which the server will return to the client its

* nickname. The client m ay use its nickname in all further

* transactions with t he server. There is no requirement t o use the

* nickname, but it is wise to u se it for performance reasons.

*/

enum authdes _namekind {

ADN _FULLNAME = 0,

ADN _NICKNAME = 1

};

/*

* A 64-bit block of encrypted DES data

*/

typedef opaque des _block[8];





Page: 183



/*

* Maximum length of a network user’s name

*/

const MAXNETNAMELEN = 255;

/*

* A fullname contains t he network name of the client, an encrypted

* conversation key and the window. The window is actually a

* lifetime for the credential. If the time indicated in t he

* verifier timestamp plus the window has past, then the server

* should expire the request and not grant it. To insure that

* requests are not replayed, the server should insist t hat

* timestamps are greater than the previous one seen, un less it is

* the first transaction. In the first t ransaction, the server

* checks instead that the window verifier is one less than the

* window.

*/

struct authdes _fullname {

string name<MAXNETNAMELEN>; /* name of client */

des _block key; /* PK encrypted conversation key */

unsigned int window; /* encrypted window */

};

/*

* A credential is either a fullname or a nickname

*/

union authdes _cred switch (authdes _namekind adc _namekind) {

case ADN _FULLNAME:

authdes _fullname adc _fullname;

case ADN _NICKNAME:

unsigned int adc _nickname;

};

/*

* A timestamp encodes the time since midnight, January 1, 1970.

*/

struct timestamp {

unsigned int seconds; /* seconds */

unsigned int useconds; /* and microseconds */

};

/*

* Verifier: client variety

* The window verifier is only u sed in the first transaction. In

* conjunction with a fullname credential, these items are packed

* into the following structure before being encrypt ed:

*

*struct {

* adv _timestamp; -- one DES block

* adv _fullname.window; -- one half DES block





Page: 184



* adv _winverf; -- one half DES block

*}

* This structure is encrypted using CBC mode encryption with an

* input vector of zero. A ll other encryptions of timestamps use

* ECB mode encryption.

*/

struct authdes _verf _clnt {

timestamp adv _timestamp; /* encrypted timestamp */

unsigned int adv _winverf; /* encrypted window verifier */

};

/*

* Verifier: server variety

* The server return s (encrypted) t he same timestamp the client

* gave it min us one second. It also tells the client it s nickname

* to be used in future transactions (unencrypted).

*/

struct authdes _verf _svr {

timestamp adv _timeverf; /* encrypted verifier */

unsigned int adv _nickname; /* new n ickname for client */

};

Diffie-Hellman Encryption

In this schem e, there are two constants, BASE an d MODULUS. The par ticular values

chosen for these for the DES authen tication p rotocol are:

const BASE = 3;

const MODULUS =

"d4a0ba0250b6fd2ec626e7efd637df76c716e22d0944b88b";

The way this scheme w orks is best explained by an example. Sup pose there are

two person s ‘‘A’’ and ‘‘B’’ wh o w ant to send encrypted messages to each oth er.

So, A and B both generate ‘‘secret’’ keys at ran dom w hich they d o not reveal toanyon e. Let these keys be represented as SK(A) and SK(B). They also pu blish in a

pu blic directory their ‘‘pu blic’’ keys. These keys are comp uted as follows:

PK(A) = ( BASE ** SK(A) ) mod MODULUS

PK(B) = ( BASE ** SK(B) ) mod MODULUS

The ‘‘**’’ notation is used here to rep resent exponentiation. Now , both A and B

can arrive a t the ‘‘common ’’ key betw een them, rep resented here as CK(A, B),

without revealing their secret keys.

A comp utes:

CK(A, B) = ( PK(B) ** SK(A)) mod MODULUS




Page: 185



while B computes:

CK(A, B) = ( PK(A) ** SK(B)) mod MODULUS

These two can be shown to be equivalent:

(PK(B) ** SK(A)) mod MODULUS = (PK(A) ** SK(B)) mod MODULUSWe drop the ‘‘mod MODULUS’’ pa rts and assum e mod ulo arithm etic to simplify

things:

PK(B) ** SK(A) = PK(A) ** SK(B)

Then, rep lace PK(B) by w hat B compu ted earlier and likewise for PK(A).

((BASE ** SK(B)) ** SK(A) = (BASE ** SK(A)) ** SK(B)

wh ich leads to:

BASE ** (SK(A) * SK(B)) = BASE ** (SK(A) * SK(B))

This comm on key CK(A, B) is not used t o encrypt the timestam ps used in the p ro-

tocol. Rather, it is used only to encrypt a conversation key w hich is then used to

encryp t the timestam ps. The reason for doing th is is to use the common key as lit-

tle as possible, for fear that it could be broken . Breaking the conversation key is a

far less serious offense, since conversations are relatively short-lived.

The conversation key is encryp ted u sing 56-bit DES keys, yet the comm on key is

192 bits. To redu ce the num ber of bits, 56 bits are selected from the comm on key

as follows. The midd le-most 8-bytes are selected from the comm on key, and then

parity is add ed to the lower ord er bit of each byte, produ cing a 56-bit key w ith 8

bits of parity.

Record Marking Standard

When RPC messages are passed on top of a byte stream p rotocol (like TCP/ IP), it

is necessary, or at least desirable, to delimit one m essage from anoth er in ord er todetect and p ossibly recover from u ser protocol errors. This is called record m ark-

ing (RM). One RPC message fits into one RM record .

A record is composed of one or more record fragments. A record fragment is a

four-byte head er followed by 0 to (2**31) - 1 bytes of fragmen t data. The bytes

encode an unsigned binary nu mber; as with XDR integers, the byte ord er is from

highest to lowest. The nu mber encodes two values—a boolean wh ich indicates

whether th e fragm ent is the last fragment of the record (bit value 1 implies the

fragmen t is the last fragm ent) and a 31-bit unsigned binary value wh ich is the

length in bytes of the fragm ent’s data. The boolean value is the highest-order bit

of the header; the length is the 31 low-ord er bits. (Note that this record

specification is NOT in XDR stand ard form!)




Page: 186



rpcbind Mechanism

An rpcbind mechanism maps RPC program an d version num bers to universal

add resses, thus making d ynamic bind ing of remote program s possible. This

mechanism should ru n at a w ell-known ad dress, and other program s register their

dyn amically allocated netw ork add resses with it. It then makes those add ressespu blically available. Universal addresses are defined by the ad dressing authority

of the given transport. They are NULL-terminated str ings.

rpcbind also aids in broad cast RPC. There is no fixed relationship betw een the

addr esses which a given RPC pr ogram w ill have on different machines, so there’s

no way to directly broadcast to all of these programs. The rpcbind mechanism,

how ever, has a well-known add ress. So, to broadcast to a given program , the

client actually sends its message to the rpcbind process on the machine it wishes

to reach. rpcbind picks up the broad cast and calls the local service specified by

the client. When rpcbind gets a rep ly from the local service, it pa sses it on to the

client.

rpcbind Protocol Specification (in RPC Language)

/*

* rpcbind procedures

*/

program RPCBPROG {

version RPCBVERS {

void

RPCBPROC _NULL(void) = 0;

bool

RPCBPROC _SET(rpcb) = 1;

bool

RPCBPROC _UNSET(rpcb) = 2;

string

RPCBPROC _GETADDR(rpcb) = 3;

rpcblist

RPCBPROC _DUMP(void) = 4;

rpcb _rmtcallres

RPCBPROC _CALLIT(rpcb _rmtcallargs) = 5;

unsigned int

RPCBPROC _GETTIME(void) = 6;

} = 3;

} = 100000;




Page: 187



rpcbind Operation

The rpcbind mechan ism is contacted by way of an assigned add ress specific to

the transport w hich is used . In case of IP, for examp le, it is port nu mber 111. Each

transport has such an assigned w ell known add ress. The following is a descrip-

tion of each of the procedu res supp orted by rpcbind:

RPCBPROC _NULL:

This procedure d oes no work. By convention, procedure zero of any pro-

tocol takes no p arameters and returns no results.

RPCBPROC _SET:

When a p rogram first becomes available on a machine, it registers itself

with the rpcbind program ru nning on the same machine. The program

passes its program n um ber, version nu mber, network identifier and the

universal address on w hich it awaits service requests. The procedure

returns a boolean response w hose value is TRUE if the p rocedure success-

fully established the m app ing and FALSE otherwise. The procedu re

refuses to establish a map ping if one already exists for the tuple. Note

that neither network identifier nor un iversal addr ess can be NULL, and

that netw ork identifier should be valid on the machine making th e call.

RPCBPROC _UNSET:

When a program becomes un available, it should u nregister itself with the

rpcbind program on the same machine. The parameters and results have

mean ings identical to those of RPCBPROC _SET. The map ping of the pro-

gram nu mber, version nu mber and network identifier tuple with univer-

sal addr ess is deleted . If netw ork identifier is NULL, all map pings

specified by the tup le (program number, version n umber, *) and the

correspond ing un iversal add resses are d eleted.

RPCBPROC _GETADDR:

Given a p rogram nu mber, version nu mber and network identifier, thisprocedure return s the universal add ress on which the program is awaiting

call requests.

RPCBPROC _DUMP:

This procedure enum erates all entries in rpcbind’s database. The pro-

cedu re takes no p arameters and returns a list of program, version, netid,

and u niversal add resses.

RPCBPROC _CALLIT:

This procedure allows a caller to call anoth er remote p rocedu re on the

same machine without kn owing the rem ote procedu re’s universal

add ress. It is intended for supp orting broadcasts to arbitrary remote pro-

grams via rpcbind’s w ell-known add ress.




Page: 188



The parameters and the argum ent pointer are the program n um ber, ver-

sion nu mber, procedu re num ber, and p arameters of the remote pro-

cedure. Note:

1 . This procedur e only sends a respon se if the procedu re was suc-

cessfully executed and is silent (no respon se) otherwise.2 . rpcbind can comm un icates with remote programs on ly by

using connectionless transports.

The procedure returns th e remote program’s universal add ress, and the

results of the remote p rocedu re.

RPCBPROC _GETTIME:

This procedure returns the local time on its own machine.

rpcbind can also sup por ts version 2 of the rpcbind (portmapper) program proto- E

col; version 3 should be used .




Page: 189



8 SYSTEM COMMANDS

Commands for Application Programs 8-1

Table of Contents i


386:adm.book:sum

Page: 190



Commands for Application Programs

Program s running on ABI-conforming system are capable of creating new

processes and executing p rograms pr ovided by th e system. They can also execute

a shell in a new p rocess, and then u se that shell to interpret a script that causes

many system p rograms to be executed.

The system comman ds listed below mu st be available to applications executing on

an ABI-conforming system. They includ e command s from the X/Open CAE X

Specification, Issue 4.2 and the System V Interface Definition, Fourth Edition, Basic and

Advanced Utilities Extensions (see Conformance Rule in chap ter 1).

The following commands are available to application programs running on ABI-

conforming systems. All the comman ds mu st be accessible through th e default

PATH environm ent variable prov ided by the system (see, section 2.5.3 of the X

Comman ds an d Utilities volume of the X/Open CA E Specification, Issue 4.2 or the

envvar(BA _ENV) manu al page in the Syst em V Interface Definition, Fourth Edition,for more information on execution environment variables).

Figure 8-1: Commands required in an ABI Run-time Environment

cat false pg# test

cd find pr touch

chgrp fmtmsg# priocntl tr

chmod gettxt pwd true

chown grep rm tty

cmp id rmdir umask

cp kill sed uname

cpio# line# sh uucp

date ln sleep uulogdd logname sort uustat

df lp stty uux

echo ls su vi

ed mkdir tail wait

ex mv tee who

expr passwd compress uncompress

make ar basename dirname

gencat sum# wc

# Comm and is DEPRECATED X




Page: 191



The following new command s, now required by the X/Open CA E Specification, X

Issue 4.2, are available to app lication pr ogram s runn ing on ABI-conforming sys- X

tems. All the command s mu st be accessible throu gh the defau lt PATH environ- X

ment variable provided by the system. X

Figure 8-2: XPG4.2 Commands required in an ABI Run-time Environment X

alias egrep man split X

asa env mesg strings X

at expand mkfifo tabs X

awk fc more talk X

batch fg newgrp tar# X

bc fgrep nice time X

bg file nl tput X

c89 fold nohup tsort X

cal getconf od type X

calendar# getopts pack# ulimit X

cksum hash paste unalias X

col# head patch unexpand Xcomm iconv pathchk uniq X

command jobs pax unpack# X

crontab join pcat# uudecode X

csplit locale printf uuencode X

cut localedef ps write X

diff logger read xargs X

dircmp# mailx renice zcat X

du mail# spell# X

# Command is DEPRECATED

NOTE

XSH4.2 conforming commands are accessed by setting the PATH variable Xequal to the value of the _CS _PATH variable as defined by XSH4.2 If an Ximplementation offers full System V Application Binary Interface, Fourth Edition Xcompatibility, the default command set including the shell in the system will be XSystem V Application Binary Interface, Fourth Edition compatible. Applications Xthat have strict compatibility requirements for their command usage, shouldconsider only relying on the default command set.

The following commands are available to application programs run-

ning on ABI-conforming systems that implement a graphical window-

ing terminal interface and therefore provide the Motif interface. M

8-2 SYSTEM COMMANDS



Page: 192



Figure 8-3: Commands required in an ABI Run-time Environment for Motif * M

uil mwm M

*Function is new to the Fourth Edition of the ABI.




Page: 193



9 EXECUTION ENVIRONMENT

Application Environment 9-1


Root subtree 9-3

The /etc subtree 9-4

The /opt subtree 9-5

The /usr subtree 9-5

The /var subtree 9-6

Table of Contents i


386:adm.book:sum

Page: 194



Application Environment

This section specifies the execution environm ent informa tion available to app lica-

tion programs running on ABI -conforming comp uters. It also specifies the pro-

gram s’ interface to that inform ation.

The execution environment contains certain information that is provided by the

opera ting system and is available to executing app lication programs. Generally

speaking, this includes system-wide env ironment information and per-process

information that is meaningfu l and accessible only to the single process to which it

app lies. This environmen t informa tion and the utilities used to retrieve it are

specified in detail in the X/Open CA E Specification, Issue 4.2 and the System V Inter- X

face Definition, Fourth Edition (see the Conformance Rule in chap ter 1).

The environment information available to app lication program s on an ABI -

conforming system includes the following:

System identification

Application programs may obtain system identification information

through the uname function or th e system command uname.

Date and time

The current calendar date and time are available to application programs

through the date system command and the time function.

Numerical Limits

This refers to the m aximu m an d minimum values of operating system vari-

ables and C language limits that app lication p rograms require. Most imp or-

tant values are accessible through the sysconf an d pathconf functions

defined in the X/Open CA E Specification, Issue 4.2 and the System V Interface X Definition, Fourth Edition and in the POSIX P1003.1 Portable Operating System X

Specification (see the Conform ance Rule in chap ter 1) . These interfaces are

the correct method for application programs to retrieve numerical values

related to the configuration of their host system. Guaranteed m inimum

values for th ese parameters ar e specified in the ‘‘Data Definition’’ section in

Chapter 6 of the ABI . Other system param eters are accessible throu gh the

getrlimit function.

Application Environment 9-1



Page: 195



Per-process environment information

When an app lication p rogram first begins execution an environment is

mad e available to it. The X/Open CA E Specification, Issue 4.2 and the System X

V Interface Definition, Fourth Edition (see the Conform ance Rule in Chapter 1)

pages for envvar, exec, and system contain detailed d escriptions of thisinformation.

The X/Open CA E Specification, Issue 4.2 and the System V Interface Definition, Fourth X

Edition (see the Conforman ce Rule in Chapter 1) are the d efinitive reference for

information abou t the execution en vironm ent of processes; all of this information

applies to ABI -conforming systems. The specific references given above w ill lead

an interested reader to all app ropriate information, but are n ot exhaustive in

themselves.

9-2 EXECUTION ENVIRONMENT



Page: 196



/ The root directory of the file system.

/dev The top d irectory of the dev ices subtree containing block and

character device files. All termina l and term inal-related

dev ice files mu st be in the /dev directory or in subdirectories

of /dev. The following files are requ ired to be presen t in the E/dev directory.

Figure 9-1: Required Devices in an ABI Run-time Environment _ ___________________________________/dev/tty /dev/null /dev/lpX E _ ___________________________________

Where X may be any integer value. N ote that further devices E

specifically required for networking supp ort are defined in E

Chap ter 12. The following sub-d irectories of /dev are

required to be p resent.

/dev/rmt/dev/mt

The nam es of other files presen t in /dev and naming conven-

tions for sub-d irectories of /dev are pr ocessor-specific.

/etc The top directory of the / etc subtree.

/opt The top d irectory of the / opt subtree.

/usr The top d irectory of the / usr subtree.

/var The top d irectory of the / var subtree.

The /dev, /usr, and /tmp directories are for the use of the system. Applications

shou ld never create files in any of these directories, thou gh they contain su bd irec-

tories that m ay be u sed by app lications, as described below.

The /etc subtree

The directory /etc of the / file system is the poin t of access to the /etc subtree.

This directory contains machine-specific configu ration files.

The following d escribes the structu re of the /etc subtree:




Page: 198



/etc The top d irectory of the /etc subtree. E

/etc/opt/ pkg EThis directory contains machine-specific configur ation files E

provided by app lication p ackages.

The /opt subtree

The directory /opt of the / file system is the p oint of access to the /opt subtree.

This directory subtree contains files installed by ad d -on app lication packages.

The following d escribes the structu re of the /opt subtree:

/opt The top d irectory of the /opt subtree. E

/opt/ pkg/bin EExecutable files pr ovided by app lication packages and E

invoked d irectly by u sers.

/opt/ pkg Where pkg is the abbreviated name of an ad d-on software

package, contains all the static files installed on the system as

part of that p ackage.

The /usr subtree

The directory /usr of the / file system is the p oint of access to the /usr subtree.

The following d escribes the structu re of the /usr subtree:

/usr The top d irectory in the / usr subtree.

/usr/bin Utility programs and command s for the u se of all app lications

and users.

/usr/share The architecture-independent sharable files.

/usr/share/lib Architecture-ind ependen t databases. M

/usr/lib/X11 MThe directory wh ere X11 Window System libraries reside. M

/usr/lib/X11/locale M

The directory wh ere X11 Window System localization pack- M

ages are installed. M

/usr/lib/X11/app-defaults M

The directory wh ere X11 Window System defau lt app lication M

resour ce files are installed.




Page: 199



App lication p rograms may execute comman ds in the /usr/bin directory.

The /var subtree

The directory /var of the / file system is the poin t of access to the /var subtree.

The /var subtr ee contains all files that vary in size or presence du ring norm al sys-

tem op erations, including logging, accounting an d temporary files created by the

system and app lications.

The following comp onen ts of the /var subtree are important for ap plication pro-

grams:

/var/opt/ pkg EThe top level directory u sed by ap plication packages.

/var/tmp Directory for temp orary files created by applications.

App lications should always use /var/tmp for creation of temp orary files. E




Page: 200



10 WINDOWING AND TERMINALINTERFACES

The System V Window System 10-1

X Window System Overview 10-2


Summary of Requirements 10-5

Table of Contents i


386:adm.book:sum

Page: 201



The System V Window System

NOTE This chapter, ‘‘Windowing and Terminal Interfaces’’ , describes the optionalABI extension for the System V Window System.

The System V window system is a graph ical window system, and is used as an

interface for high-resolution bitmapp ed display devices. The window system

allows mu ltiple cooperating app lications to ap pear on a display screen simultane-

ously. A server process arbitrates a shared d isplay, a keyboard, and a pointing

dev ice, and perform s I/ O on behalf of one or more client app lications. Client

app lications may execute in the local processor’s memor y space, or may run on a

remote processor and commun icate with the server through a network connec-

tion.

The System V window system su pp orts concurrent, overlapp ing wind ows, andwind ows can be created within other window s. The system supp orts text, two-

dimensional graphics, and imaging.

The System V wind ow system is comp letely netw ork-transp arent, in that a client

program can be running on an y machine in a netw ork and the client and server

program s need not be executing on machines sharing a common architecture. E

When the client and server reside on different machines, messages are transm itted E

over the netw ork. When the client and server reside on the same m achine, mes-

sages are transm itted u sing a local inter-process commu nication (IPC) mechan ism.

Applications for the System V wind ow system m ay be wr itten to either the X11

Window System interface, the X11 Toolkit Intrinsics, the X11 Non rectangu lar Win- M

dow Shap e Extension, or Motif. M

The X11 interface contains man da tory pa rts of the System V Wind ow System. All

implementations that includ e a window system extension mu st support

the X11 inter face, the X Toolkit Intrin sics inter face, the X11 Nonr ectangular Win- M

dow Shap e Extension, and Motif. The X11 interface has base and optional com- M

ponents.

The System V Window System 10-1



Page: 202



X Window System Overview

A client ap plication comm un icates with the X capabilities of the System V wind ow

system server using the X11 protocol. The X11 pro tocol specifies exchange format,

ru les for data exchange, and m essage semantics, bu t is policy-free and does not

impose any specific app earance on the interface. The look and feel of a par ticular

interface is defined by the w indow manager an d d ifferent toolkits that define a

higher-level progr am interface to the X capabilities.

The X Version 11 protocol defines the format, syntax, common types, errors codes,

keyboard keycodes, pointers, predefined atoms, connection setup, requests, con-

nection close, and events. A detailed description of these can be foun d in the X

Window System Protocol, Version 11 Specification (Massachu setts Institute of Tech-

nology, 1991).

10-2 WINDOWING AND TERMINAL INTERFACES



Page: 203



System V Window System Components

The System V Wind ow System includ es the following compon ents. Some com-

ponents of the wind ow system are base components of the ABI and mu st be

presen t, and others are optional comp onents. Because of this mixture, each

component’s statu s has been explicitly mar ked in the list below, together with th e

component’s description.

libX

NOTE

The libX library is a base ABI component and must bepresent on an ABI-conforming system which has a win-dow system extension.

The X library, libX, generates the X11 protocol and buffers

traffic between each client app lication and th e server. A full

specification of the X library and its conten ts can be found in

Xlib - C Language Interface, X Window System, X Version 11, G Release 5, (Massachu setts Institu te of Technology, 1991). The

ABI will track upw ard -comp atible futu re releases of the X

library.

X Toolkit Int rinsics

NOTE

The libXt library is a base ABI component and must Gbe present on an ABI-conforming system which has awindow system extension.

The X Toolkit Intrinsics library libXt provides a framework

for building X-based toolkits. A full specification of the X

Toolkit Intrinsics can be found in X Toolkit Int rinsics - C

Language X Int erface, X W indow System, X V ersion 11, Release 5, G

(Massachusetts Institute of Technology, 1991).

X11 Nonrectangular Window Shape Extension




Page: 204



NOTE

The libXext library is a base ABI component and Mmust be present on an ABI-conforming system whichhas a window system extension.

The X11 Nonrectangu lar Window Shape Extension library MVersion 1.0, libXext, pr ovides sup por t for irregularly shap ed M

wind ows un der X11. A full specification of the X11 Non rec- M

tangular Window Shape Extension can be found in X11 Non- M

rectangular W indow Shape Extension Version 1.0, X Version 11, M

Release 5, (Massachu setts Institu te of Technology, 1991). M

Motif M

NOTE

The libXm and libMrm libraries are base ABI com-ponents and mu st be present on an ABI-conformingsystem which has a wind ow system extension.

The Motif libraries, libXm an d libMrm provide supp ort for M

wind owing app lications. A full specification of the Motif Mlibraries can be found in the Motif Programmer’s Reference Revi- M

sion 1.2, (Open Software Found ation,1992).

The following p rogram s are not requ ired to be present on an ABI-conforming sys-

tem. How ever, the protocols that these program s use to commu nicate are con-

sidered part of the ABI and m ust be present in an environment wh ich supp orts

window systems. Hence all ABI-conforming systems w hich offer these services

mu st provide them as follows.

server The server controls the user’s d isplay. As such, a server is usu ally

available for each type of display that can be connected to a system. It

man ages device depen den cies, enabling client applications to be

device-ind ependen t, although some client ap plications m ay need to be

aw are of the resolution, aspect ratio, or depth of the display dev icebeing used . Servers include protocol interpretation facilities for X and

PostScript extensions. All ABI-conforming wind ow servers wh ich sup -

por t X mu st supp ort the entire X pr otocol referenced above. (The

server side of X protocol comm un icates with libX). M

window manager

The window manager p rogram allows a user to manipulate (for exam-

ple, move and resize) window s. All client applications that use the win-

dowing system use the facilities of the window manager. Well-behaved E

clients must follow the ICCCM. All ABI-conforming window man agers

wh ich supp ort X mu st supp ort the entire X wind ow manager protocol. M

10-4 WINDOWING AND TERMINAL INTERFACES



Page: 205



Summary of Requirements

The ‘‘Windowing an d Terminal Interfaces’’ section o f the System V A BI has a lay-

ered set of requ irements for conforming systems. Those requ irements are sum-

marized here.

The presence of a wind owing system is optional on an ABI-conforming sys-

tem.

If a w indow ing system is present on a conforming system, libX, libXt, G

libext, libXm, and libMrmmu st be provided . M




Page: 206



11 DEVELOPMENT ENVIRONMENTSFOR AN ABI SYSTEM

Development Environments 11-1

Commands 11-1

Software Packaging Tools 11-3

Static Archives 11-4

Table of Contents i


386:adm.book:sum

Page: 207



Development Environments

NOTE THE FACILITIES AND INTERFACES DESCRIBED IN THIS SECTION AREOPTIONAL COMPONENTS OF THE System V Application Binary Interface.

Any system may be used to provide a d evelopmen t environment for ABI con-

forming app lications. This chapter describes the command s, options, libraries,

and p ath mechan isms necessary to prod uce an ABI conforming app lication. This

development environm ent need n ot be hosted on an ABI conforming implementa-

tion.

Commands

The following comm ands, d efined in th e X/Open CA E Specification, Issue 4.2 and X

the SD _CMD section of the System V Interface Definition, Fourth Edition (see the X

Conformance Rule of Chap ter 1) are a par t of an ABI developmen t environm ent.

All comm and s defined here are mand atory in ABI Developm ent Environments,

except that the command as need n ot be present w hen ABI conformant code is

generated directly by the compiler.

ABI Development Comman ds _ __________________________as# cc# ld

m4 lex yacc

c89† X

# Comm and is DEPRECATED X

†As defined in the Comm and s and Utilities volum e of the X/Open CAE Specification, Issue X

4.2.

Each comman d shall accept the following required op tions and provide the fun c-

tionality required for each op tion listed, in the X/Open CA E Specification, Issue 4.2 X

and the System V Interface Definition, Fourth Edition (see the Conformance Rule in X

chapter 1).




Page: 208



as

SVID Fourth Ed ition Options to AS _ _______________________________o m

The as command if present shall produce outpu t compliant to chapters 4 and 5 of

this document, and chapters 4 and 5 of the appropriate Processor-specific Supple-

ment .

cc

SVID Fourth Edition Op tions to CC ________________________________B c d D

G I K l M

L o O U

Y

The cc command shall generate outpu t compliant to Chap ter 4 and 5 of this docu-

ment and Chapter 4 and 5 of the approp riate Processor-specific Supplement .

ld

SVID Fourth Ed ition Options to ld _ ______________________________a B d e

G h l o

r s u L

Y z

The comman d ld shall generate outpu t compliant to Chapters 4 and 5 of this

docum ent and Chap ters 4 and 5 of the app ropriate Processor-specific Supplement .

lex

SVID Fourth Ed ition Options to lex _ _______________________________c t v n

m4

SVID Fourth Ed ition Options to m4 _ ______________________________s D U

11-2 DEVELOPMENT ENVIRONMENTS FOR AN ABI SYSTEM



Page: 209



yacc

SVID Fourth Ed ition Options to yacc _ _________________________________v d l t

As there may be m ultiple development environm ents hosted on a system, dif-

ferent values for PATH m ay be requ ired to access each d evelopment environment,

but all required com man ds sha ll be accessible by at least one value of PATH. The

processor sup plemen t for each architecture sha ll state how th e value of PATH is to

be used to find the location of a development environm ent for that architecture

when it is not the na tive developm ent environmen t. If the system is itself ABI con-

forming an d hosts a development environment for its run-time system, the

developmen t environm ent for the run -time system shall be accessible using the

system default value for PATH.

To enable the System V Application Binary Interface, Edition 4.1 environment and X

functionality, app lications mu st use the cc compiler dr iver. This dr iver will have X

an imp lementation-specific sequen ce of -D directives, includ e files or libraries to X

enable access to System V Application Binary Interface, Edition 4.1 features. As a X

result the executable created will have the _ _xpg4 flag set to a value app ropriate Xto the base API the application w ishes to conform to.

NOTE

All .o’s should be compiled such that they either don’t assume any specific Xshell (or other syntactic feature), or they presume the same shell (or other Xsyntactic feature) across all .o’s. Information is contained in linked execut-ables, not in individual .o’s.

Software Packaging Tools

A developm ent environ men t for ABI app lications shall include each of the follow-

ing comm ands as defined in the AS _CMD section of SVID Fourth Edition.

pkgproto pkgtrans pkgmk

The pkgtrans command shall generate outpu t compliant with Chapter 2 of this

document.




Page: 210



Figure 11-2: Required libcurses Functions M

addch dupwin insdelln mvgetstr M

addchnstr echo insertln mvgetwch M

addchstr echochar insnstr mvgetwstr M

addnstr echowchar insnwstr mvinch M

addnwstr endwin insstr mvinchnstr M

addstr erase instr mvinchstr M

addwch erasechar inswch mvinnstr M

addwchnstr filter inswstr mvinnwstr M

addwchstr flash intrflush mvinsch M

addwstr flushinp inwch mvinsnstr M

attroff getbegyx inwchnstr mvinsnwstr M

attron getch inwchstr mvinsstr M

attrset getmaxyx inwstr mvinstr M

baudrate getnwstr is _linetouched mvinswch M

beep getparyx is _wintouched mvinswstr M

bkgd getstr isendwin mvinwch Mbkgdset getsyx keyname mvinwchnstr M

border getwch keypad mvinwchstr M

box getwin killchar mvinwstr M

can _change _color getwstr leaveok mvprintw M

cbreak getyx longname mvscanw M

clear halfdelay meta mvwaddch M

clearok has _colors move mvwaddchnstr M

clrtobot has _ic mvaddch mvwaddchstr M

clrtoeol has _il mvaddchnstr mvwaddnstr M

color _content hline mvaddchstr mvwaddnwstr M

copywin idcok mvaddnstr mvwaddstr M

curs _set idlok mvaddnwstr mvwaddwch M

def _prog _mode immedok mvaddstr mvwaddwchnstr Mdef _shell _mode inch mvaddwch mvwaddwchstr M

del _curterm inchnstr mvaddwchnstr mvwaddwstr M

delay _output inchstr mvaddwchstr mvwdelch M

delch init _color mvaddwstr mvwgetch M

deleteln init _pair mvcur mvwgetnwstr M

delscreen initscr mvdelch mvwgetstr M

delwin innstr mvderwin mvwgetwch M

derwin innwstr mvgetch mvwgetwstr M

doupdate insch mvgetnwstr mvwin M




Page: 212



Figure 11-2: Required libcurses Functions (continued ) M

mvwinch putp standout waddwch M

mvwinchnstr putwin start _color waddwchnstr M

mvwinchstr qiflush subpad waddwchstr M

mvwinnstr raw subwin waddwstr M

mvwinnwstr redrawwin syncok wattroff M

mvwinsch refresh termattrs wattron M

mvwinsnstr reset _prog _mode termname wattrset M

mvwinsnwstr reset _shell _mode tgetent wbkgd M

mvwinsstr resetty tgetflag wbkgdset M

mvwinstr restartterm tgetnum wborder M

mvwinswch ripoffline tgetstr wclear M

mvwinswstr savetty tgoto wclrtobot M

mvwinwch scanw tigetflag wclrtoeol M

mvwinwchnstr scr _dump tigetnum wcursyncup M

mvwinwchstr scr _init tigetstr wdelch M

mvwinwstr scr _restore timeout wdeleteln Mmvwprintw scr _set touchline wechochar M

mvwscanw scrl touchwin wechowchar M

napms scroll tparm werase M

newpad scrollok tputs wgetch M

newterm set _curterm tputs wgetnstr M

newwin set _term typeahead wgetnwstr M

nl setscrreg unctrl wgetstr M

nocbreak setsyx ungetch wgetwch M

nodelay setterm ungetwch wgetwstr M

noecho setupterm untouchwin whline M

nonl slk _attroff use _env winch M

noqiflush slk _attron vidattr winchnstr M

noraw slk _attrset vidputs winchstr Mnotimeout slk _clear vline winnstr M

overlay slk _init vwprintw winnwstr M

overwrite slk _label vwscanw winsch M

pair _content slk _noutrefresh waddch winsdelln M

pechochar slk _refresh waddchnstr winsertln M

pechowchar slk _restore waddchstr winsnstr M

pnoutrefresh slk _set waddnstr winsnwstr M

prefresh slk _touch waddnwstr winsstr M

printw standend waddstr winstr M

11-6 DEVELOPMENT ENVIRONMENTS FOR AN ABI SYSTEM



Page: 213



Figure 11-2: Required libcurses Functions (continued ) M

winswch wmove wscanw wsyncdown M

winswstr wnoutrefresh wscrl wsyncup M

winwch wprintw wsetscrreg wtimeout M

winwchnstr wredrawln wstandend wtouchln M

winwchstr wrefresh wstandout wvline M

winwstr M




Page: 214



t _rcv 12-12

t _rcvconnect 12-12

t _rcvudata 12-12

t _rcvuderr 12-12

t _snd 12-12

t _snddis 12-13t _sndrel 12-13

t _sndudata 12-13

Data Structures 12-13



386:adm.book:sum

Page: 216



Networking

NOTE This chapter is new to the System V Application Binary Interface, Third Edition .

ABI-conforming systems m ay sup port som e level of networking, ranging from

peer-to-peer to loopback networks. This section describes the networ k transport

level services needed to supp ort the Internet and ISO transport p rotocols. In add i-

tion, it defines required su pp ort for basic process to process comm un ication over a

network.

Networking 12-1



Page: 217



Required STREAMS Devices and Modules

The following d evice dr ivers must exist on an ABI-conforming system. Their

requ ired functionality shall be that specified in the System V Interface Definition,

Fourth Edition and the DDN Protocol Handbook, DARPA Internet Protocols.

Figure 12-1: Required STREAMS Devices _ _____________________________________________________________________________/dev/ticlts /dev/ticots /dev/ticotsord transport loopback supp ort

/dev/tcp /dev/udp internet support

/dev/ptmx /dev/pts/digits pseudo terminal support _ _____________________________________________________________________________

Where digits are decimal numbers.

The following required STREAMS modu les shall be present on conforming sys-

tems and th eir fun ctionality shall be that defin ed in section BA _DEV of the System

V Interface Definit ion, Fourth Edition.

Figure 12-2: Required STREAMS Modules _ ___________________________________________________ldterm ptem pckt pseudo terminal support

tirdwr timod transport level supp ort

connld pipemod IPC supp ort _ ___________________________________________________

Binary interface sup port for these mod ules and drivers are defined in the follow-

ing sections.

12-2 NETWORKING



Page: 218



Required Interprocess Communication Support

Pseudo Terminal Support

There shall be an app ropriate entry in the /dev/pts directory for each slave-side

pseu do-terminal available on the imp lementation. Conform ing systems shall pro-

vide a minimu m of 16 pseud o-terminals. The default initial state of a pseudo-

terminal, as reported by tcgetattr, shall be the same as the defau lt initial state of

a termina l as specified in termio(BA _DEV).

NOTE

The default baud rate as specified by termio(BA _DEV) is 300 baud. As thismay be inappropriate for pseudo terminals, there are exceptions.

STREAM Based Pipe Support

Functionality for interprocess commu nication by w ay of STREAMS-based pipes

shall be sup por ted by ABI-conforming systems. STREAMS mod ules connld an d

pipemod mu st be present in supp ort of this.

Required Interprocess Communication Support 12-3



Page: 219



Required Transport Layer Support

A transp ort layer app lication may access transpo rt services throu gh the ISO or

Internet framew orks. This docu men t supp orts transpor t access via the XTI inter-

face as it makes u se of the timod mod ule. The requ ired fun ctionality for these

mod ules is defined in the BA _DEV section of the System V Interface Definition, X

Fourth Edition . The defin ition of XTI is described in the Netw orking Services X

volume of the X/Open CA E Specification, Issue 4.

In order to imp rove standard s conformance and take ad vantage of the latest tech-

nology in XTI interfaces, the TLI inter faces hav e been DEPRECATED. Ap plica-

tions wh ich m ake use of TLI should m igrate to XTI as a replacement. TLI is a sub-

set of XTI except w here n oted.

To achieve binary interop erability, an ABI-conforming system m ust consistently

define variables and d ata structures. The next few d isplays contain m nemonics

requ ired on ABI-conforming system s. Their associated values are specified in theprocessor specific ABI.

Figure 12-3: TLI-XTI Error Codes _ _____________________________________________________________TACCES TBADQLEN* TNODATA TPROTO*

TADDRBUSY* TBADSEQ TNODIS TPROVMISMATCH*

TBADADDR TBUFOVFLW TNOREL TQFULL*

TBADDATA TFLOW TNOSTRUCTYPE* TRESADDR*

TBADF TINDOUT* TNOTSUPPORT TRESQLEN*

TBADFLAG TLOOK TNOUDERR TSTATECHNG

TBADNAME* TNOADDR TOUTSTATE TSYSERR

TBADOPT _ _____________________________________________________________

*Function is n ew to System V ABI Edition 4.1. X

Figure 12-4: t _look Events _ ____________________________________________________T _LISTEN T _EXDATA T _UDERR T _CONNECT

T _DISCONNECT T _ORDREL T _DATA T _ERROR

T _EVENTS

T _GODATA T _GOEXDATA M _ ____________________________________________________

12-4 NETWORKING



Page: 220



Figure 12-5: XTI Flag Definitions _ ___________________________________________________________________T _MORE T _NEGOTIATE T _DEFAULT T _EXPEDITED

T _CHECK T _SUCCESS T _FAILURE

T _CURRENT T _NOTSUPPORT T _PARTSUCCESS T _READONLY X

_ ___________________________________________________________________

Figure 12-6: XTI Service Types _ ___________________________________T _COTS T _COTS _ORD T _CLTS _ ___________________________________

The following are required structure types an d bit fields u sed w hen d ynamically

allocating XTI structu res via th e function t _alloc call: X

Figure 12-7: Flags to be used with t _alloc _ ____________________________________T _BIND T _OPTMGMT T _CALL

T _DIS T _UNITDATA T _UDERROR

T _INFO T _ADDR T _OPT

T _UDATA T _ALL _ ____________________________________

Figure 12-8: XTI Application States _ ________________________________________________T _UNINIT T _UNBND T _IDLE T _OUTCON

T _INCON T _DATAXFER T _OUTREL T _INRELT _FAKE T _NOSTATES _ ________________________________________________

Required Transport Layer Support 12-5



Page: 221



Figure 12-9: XTI values for t _info flags member _____________

T _SENDZERO _____________

12-6 NETWORKING



Page: 222



Optional Internet Transport Support

A tcp imp lementation conforming to RFC 793 (as revised by by RFC 1122) shall

supp ort a device driver implementing the T _COTS _ORD service type. A udp imple-

men tation conforming to RFC 768 shall supp ort a device driver imp lementing the

T _CLTS service type. These services shall be available to the TLI / XTI functions

and the p rovided fun ctionality shall be consistent with TCP (RFC 793) and UDP

(RFC 768).

Address Format

The XTI netbuf structure is used to pass TCP/ IP add resses. The addr.buf com-

ponent should p oint to a struct sockaddr _in. When used by XTI requests, the

sin _zero field of this structure shall be zero and th e sin _family field shall con-

tain AF _INET.

Programming Interfaces

A conforming TCP/ IP implementation shall implement the following transp ort

pr ovider-specific fun ctionality in ad dition to th at requ ired by RFC 793 and 791 (as

revised by RFC 1122 and RFC 1349).

t _accept

Und er TLI no options shall be supp orted. The return ed udata length shall be X

zero.

t _bind

The INADDR _ANY add ress may be used. If INADDR _ANY is sup plied as the add ress,

then the loopback or a local address will be used.

t _connect

No data shall be sent with the connection. The sin _addr field of the struct

sockaddr _in pointed to by sndcall->addr.buf may contain a valid TCP/ IP

add ress. If rcvcall is not NULL, then th e buffer iden tified by rcvcall-

>addr.buf shall be filled in w ith a sockaddr _in structure.

12-8 NETWORKING



Page: 224



t _getinfo

The following default values shall be return ed from the d evices associated with

the TCP/ IP transport provider.

Values Returned by /dev/tcp

_ ______________________________addr varies X

options varies X

tsdu 0 (byte stream )

etsdu –1

connect –2 (not supported )

discon –2 (not supported )

servtype T _COTS _ORD

flags T _SENDZERO _ ______________________________

Values Returned by /dev/udp _ ______________________________addr varies X

options varies Xtsdu varies X

etsdu –2 (not supported )

connect –2 (not supported )

discon –2 (not supported )

servtype T _CLTS

flags T _SENDZERO _ ______________________________

t _listen

The result udata variable shall have zero length. Und er TLI the result opt vari- X

able shall have zero length. The buffer identified by call->addr.buf shall

receive a struct sockaddr _in that identifies the host originating the connection.

t _open

The returned transport characteristics shall be the same as those returned by

t _getinfo.




Page: 225



t _optmgmt

TLI

Und er TLI the following op tions may be accessible throu gh t _optmgmt: X

Figure 12-10: TCP Options _ _________________TCP _NODELAY _ _________________

Figure 12-11: IP Options _ __________________________________________IPOPT _EOL End o f options list

IPOPT _NOP No op eration

IPOPT _LSRR Loose source and record route

IPOPT _SSRR Strict source and record route _ __________________________________________

Options are specified in an op tions buffer with th e opthdr data stru cture format.

An op tions bu ffer contains one or more op tions, with each followed by 0 or more

values. The len field of opthdr specifies the length of the option valu e in bytes.

This length mu st be a mu ltiple of sizeof(long)

Op tions may be man ipu lated at the TCP level and th e IP level via the TLI

t _optmgmt call. To manipu late options at the TCP level,IPPROTO _TCP is specified

to t _optmgmt. For the IP level, IPPROTO _IP should be specified for t _optmgmt.

The header <netinet/tcp.h> contains the d efinitions for TCP level options,

while the IP level options are d efined in <netinet/ip.h>.

All TCP level options are 4 bytes long. A boolean option is either set or reset.Any n on-zero value w ill assert (set) the option w hile only zero will clear the

option.

The IP options consist of a string of IPOPT _* values. These options w ill be set in

every outgoing d atagram . Op tions whose function is not explicitly specified

above are copied directly into the outp ut. See IP and RFC 1122 for details.

TCP Level Options If the TCP _NODELAY option is set, a conforming system shall not

delay send ing data in ord er to coalesce small packets. When the option is reset, a

system m ay defer send ing data in an effort to coalesce small packets to conserve

network bandwidth.

12-10 NETWORKING



Page: 226



IP Level Options

IPOPT _LSRR The IPOPT _LSRR option enables the loose source and record rou te

option as specified in RFC 1122.

IPOPT _SSRR The IPOPT _SSRR option enables the strict source and record route

option as specified in RFC 1122.

IPOPT _NOP The IPOPT _NOP does nothing. Since the length of the IP options

mu st be a mu ltiple of 4, this option is useful as a pad .

IPOPT _EOL This option identifies the end of an IP option sequen ce.

XTI

The following information is relevant un der XTI. The following options may be X

accessible th rough t _optmgmt: X

Figure 12-12: TCP Options X _ _______________________________________ X

TCP Level INET _TCP XTCP Level Options TCP _NODELAY X

TCP _MAXSEG X

TCP _KEEPALIVE X _ _______________________________________

Figure 12-13: UDP Options X _ ________________________________________UDP Level INET _UDP X

UDP Level Options UDP _CHECKSUM X _ ________________________________________




Page: 227



Figure 12-14: IP Options X _ _______________________________________IP Level INET _IP X

UDP Level Options IP _OPTIONS X

IP

_TTL X

IP _TOS X

IP _REUSEADDR X

IP _DONTROUTE X

IP _BROADCAST X _ _______________________________________

t _rcv

TCP/ IP urgent data shall be returned as expedited d ata with the semantics

described in t _rcv for exped ited data.

t _rcvconnect

The result udata variable shall have zero length . Und er TLI, the result opt vari- X

able shall have zero length.

t _rcvudata

If opt is non NULL and there were IP or UDP options sent with the datagram , the X

IP or UDP options should be return ed in opt. Und er TLI if opt is NULL and IP X

options were sent, they shou ld be silently discarded . Und er TLI, UDP will not X

send options.

t _rcvuderr

Und er TLI the returned length of the opt variable shall be zero. X

t _snd

If T _EXPEDITED is set in the flags argum ent, TCP will send the d ata as urgent data.

The TCP urgent d ata pointer will point to the first byte of data in the n ext data

sent by t _snd.

12-12 NETWORKING



Page: 228



t _snddis

Data shall not be sent with the d isconnect request.

t _sndrel

The T _COTS _ORD service of the transpor t provid er (TCP) shall sup port th is fun c-

tion.

t _sndudata

Und er TLI, for /dev/udp, the opt field may contain IPPROTO _IP options. The X

UDP protocol shall sup port sending zero length d ata.

Data Structures

To support interoperability between networked machines, an ABI-conforming

system supp orting the Internet family protocols must sup port the following d atastructures.

There mu st exist a sockaddr _in da ta structu re containing at least the following

elements. Und er TLI there mu st exist a opthdr data structu re containing at least X

the following elements.

Figure 12-15: Data Structures

struct sockaddr _in {

short sin _family;

u _short sin _port;

struct in _addr sin _addr;

char sin _zero[8];};

struct opthdr {

long level;

long name;

long len;

};




Page: 229



IN Index

Index IN-1

Table of Contents i


File: Cindex386:adm.book:sum

Page: 230



Index

2’s comp lement 4: 8

Aa64l 6: 9

ABI

generic 1: 1, 4, 8

pr ocessor specific 1: 1, 4, 8

ABI conformance 1: 4–5, 8, 3: 2, 4: 15,

5: 4, 6, 10, 15, 18, 6: 2, 5, 11, 14, 7: 1,

22, 8: 1, 10: 5, 11: 1, 4

ABI Conformance 12: 4

abort 6: 6

abs 6: 6

absolute symbols 4: 11

accept 6: 21

accepted _reply 7: 29

accept _stat 7: 27

access 6: 8

access control mechan isms 7: 23

accoun ting files 9: 6

acct 6: 8

addch 6: 25, 11: 7

addchnstr 6: 25, 11: 7

addchstr 6: 25, 11: 7

addnstr 6: 25, 11: 7

addnwstr 6: 25, 11: 7

addstr 6: 25, 11: 7

add _wch 6: 25

addwch 11: 7

add _wchnstr 6: 25

addwchnstr 11: 7

add _wchstr 6: 25

addwchstr 11: 7

addwstr 6: 25, 11: 7

ADN _FULLNAME 7: 33–34

ADN _NICKNAME 7: 33–34

AF _INET 12: 8

aio _cancel 6: 16

aio _error 6: 16

aio _read 6: 16

aio _return 6: 16

aio _suspend 6: 16

aio _write 6: 16

alarm 6: 8

alignment , section 4: 13

_altzone 6: 12

altzone 6: 12

ANSI C 3: 1, 6: 1, 10, 13, 46

app lication environment 9: 1

applicationShellClassRec 6: 37

applicationShellWidgetClass

6: 37

archive file 4: 24, 5: 19, 7: 2, 11: 4

archive h eader 7: 2

string table 7: 2

archive formats, other 7: 6

archive head er, see archive file 7: 2

archive symbol table 7: 2, 4–5

archive word encoding 7: 4

ARFMAG 7: 3

ar.h 7: 2

ar.hdr 7: 2

as 11: 1ASCII 2: 5, 3: 2, 7: 2

asctime 6: 6

asctime _r 6: 8

assembler 4: 1, 11: 1

symbol names 4: 22

_ _assert 6: 9

asynchronous input/ output 6: 15

asynchronous I/ O 6: 15

atexit 6: 6

atexit(BA _OS) 5: 26

Index IN-1


File: index386:adm.book:sum

Page: 231



atof 6: 6

atoi 6: 6

atol 6: 6

attr _get 6: 25

attr _off 6: 25

attroff 6: 25, 11: 7

attr _on 6: 25

attron 6: 25, 11: 7

attr _set 6: 25

attrset 6: 25, 11: 7

AUTH _BADCRED 7: 27

AUTH _BADVERF 7: 27

authdes _cred 7: 34

authdes _fullname 7: 34

authdes _getucred 6: 20

authdes _namekind 7: 33

authdes _seccreate 6: 20

authdes _verf 7: 35

authdes _verf _svr 7: 35

authentication protocol 7: 23, 25

AUTH _ERROR 7: 27, 30

auth _flavor 7: 25

authnone _create 6: 20

AUTH _NULL 7: 30–31

AUTH _REJECTEDCRED 7: 27

AUTH _REJECTEDVERF 7: 27

auth _stat 7: 27

AUTH _SYS 7: 30

authsys _create 6: 20

authsys _create _default 6: 20

auth _sysparms 7: 31AUTH _TOOWEAK 7: 27

Bbarrier _destroy 6: 15

barrier _init 6: 15

barrier _wait 6: 15

BASE 7: 35

base address 5: 15

definition 5: 5

BASEDIR 2: 9

basename 6: 9

basic system serv ice 6: 5

baudrate 6: 25, 11: 7

bcmp 6: 9

bcopy 6: 9

beep 6: 25, 11: 7

bind 6: 21

bit _attributes 6: 25

bit-field 3: 1

bkgd 6: 25, 11: 7

bkgdset 6: 25, 11: 7

bkgrnd 6: 25

bkgrndset 6: 25

boolcodes 6: 25

boolfnames 6: 25

boolnames 6: 25

border 6: 25, 11: 7

border _set 6: 25

box 6: 25, 11: 7

box _set 6: 25

brk 6: 9

broadcast p acket 7: 26

broadcast RPC 7: 37

bsd _signal 6: 9

bsearch 6: 6

byte order 4: 8

bzero 6: 9

CC language

ABI reference language 3: 1

ANSI 1: 2, 3: 1, 6: 3

assembly nam es 4: 22

calling sequ ence 3: 4

library (see library)

C library 6: 5

CALL 7: 27–28

call _body 7: 28

calling sequ ence 3: 1, 4

IN-2 Index



Page: 232



signals 1: 6

system trap s 1: 6

calloc 6: 6

can _change _color 6: 25, 11: 7

catclose 6: 8

catgets 6: 8

catopen 6: 8

cbreak 6: 25, 11: 7

cc 11: 1

cfgetispeed 6: 8

cfgetospeed 6: 8

cfsetispeed 6: 8

cfsetospeed 6: 8

character sets 3: 2, 7: 2

chdir 6: 8

chgat 6: 25

chmod 6: 8

chown 6: 8

chroot 6: 8

_cleanup 6: 9

clear 6: 25, 11: 7

clearerr 6: 6

clearok 6: 25, 11: 7

clnt _create 6: 20

clnt _dg _create 6: 20

clnt _pcreateerror 6: 20

clnt _perrno 6: 20

clnt _perror 6: 20

clnt _raw _create 6: 20

clnt _spcreateerror 6: 20

clnt _sperrno 6: 20clnt _sperror 6: 20

clnt _tli _create 6: 20

clnt _tp _create 6: 20

clnt _vc _create 6: 20

clock 6: 6

close 6: 8

close 6: 21

closedir 6: 8

closelog 6: 9

clrtobot 6: 25, 11: 7

clrtoeol 6: 25, 11: 7

code generation 3: 6

code sequences 3: 6

color _content 6: 25, 11: 7

colorConvertArgs 6: 37

common symbols 4: 11

compositeClassRec 6: 37

compositeWidgetClass 6: 37

compver 2: 3, 11

cond _broadcast 6: 15

cond _destroy 6: 15

cond _init 6: 15

cond _signal 6: 15

cond _timedwait 6: 15

cond _wait 6: 15

confstr 6: 8

connect 6: 21

connld 12: 2

constraintClassRec 6: 37

constraintWidgetClass 6: 37

conversation key 7: 32

copyright 2: 3, 10

copywin 6: 25, 11: 7

core file 4: 5

coreWidgetClass 6: 37

cpio 2: 1, 4–6, 7: 6

creat 6: 8

ctermid 6: 8

ctime 6: 6

ctime _r 6: 8

_ _ctype 6: 12

cur _bools 6: 25cur _nums 6: 25

curscr 6: 25

curs _errno 6: 25

curs _parm _err 6: 25

curs _set 6: 25, 11: 7

cur _strs 6: 25

cur _term 6: 25

cuserid 6: 8

Index IN-3



Page: 233



DDARPA 12: 2

da ta object sizes 6: 47

data representation 4: 3, 8

date 9: 1date and time 9: 1

_daylight 6: 12

daylight 6: 12

dbm _clearerr 6: 9

dbm _close 6: 9

dbm _delete 6: 9

dbm _error 6: 9

dbm _fetch 6: 9

dbm _firstkey 6: 9

dbm _nextkey 6: 9

dbm _open 6: 9

dbm _store 6: 9

dd 2: 1DDN Protocol Hand book, DARPA

Internet Protocols 12: 2

def _prog _mode 6: 25, 11: 7

def _shell _mode 6: 25, 11: 7

delay _output 6: 25, 11: 7

delch 6: 25, 11: 7

del _curterm 6: 25, 11: 7

deleteln 6: 25, 11: 7

delscreen 6: 25, 11: 7

delwin 6: 25, 11: 7

depend 2: 3, 11

derwin 6: 25, 11: 7

DES auth entication protocol 7: 33

DES key 7: 32

des _block 7: 34

/dev 9: 4

Developm ent Environment 11: 1, 3

device drivers 12: 2

device nodes 12: 2

/dev/lpX 9: 4

/dev/null 9: 4

/dev/ptmx 12: 2

/dev/pts 12: 2

/dev/tcp 12: 2

/dev/ticlts 12: 2

/dev/ticots 12: 2

/dev/ticotsord 12: 2

/dev/tty 9: 4

/dev/udp 12: 2

Diffie-Hellman 7: 32

difftime 6: 6

dirname 6: 9

div 6: 6

dlclose 6: 17

dlerror 6: 17

dlopen 6: 17

dlsym 6: 17

doupdate 6: 25, 11: 7

dup 6: 8

dup2 6: 8

dupwin 6: 25, 11: 7

_DYNAMIC 5: 14

see also dynam ic linking 5: 14

dyn amic binding 7: 37

see also rpcbind protocol 7: 37

dynam ic library (see shared object

file)

dyn amic linker 4: 1, 5: 13


see also link editor 5: 13

see also shared object file 5: 13

dyn amic linking 1: 5, 5: 12, 6: 2, 11

base address 5: 5

_DYNAMIC 5: 14environment 5: 14, 20

hash function 5: 21

initialization function 5: 17, 22

lazy binding 5: 14

LD _BIND _NOW 5: 14

LD _LIBRARY _PATH 5: 20

relocation 5: 17

see also dynam ic linker 5: 12

see also hash table 5: 17

see also procedure linkage table

5: 16

IN-4 Index



Page: 234



string table 5: 17

symbol resolution 5: 19

symbol table 4: 14, 18, 5: 17

termination function 5: 17, 22

dynamic linking library 6: 17

Eecho 6: 25, 11: 7

echochar 6: 25, 11: 7

echo _wchar 6: 25

echowchar 11: 7

ecvt 6: 9

ELF 4: 1

encrypted timestamp 7: 32

endgrent 6: 9

endhostent 6: 21

endnetconfig 6: 20endnetent 6: 21

endnetpath 6: 20

endprotoent 6: 21

endpwent 6: 9

endservent 6: 21

endutxent 6: 9

endwin 6: 25, 11: 7

ENOSYS 6: 13, 19

entry p oint (see process, entry point)

_environ 6: 12

environ 6: 13

environment 5: 14, 20

envvar 8: 1, 9: 2

erase 6: 25, 11: 7

erasechar 6: 25, 11: 7

erasewchar 6: 25

_ _ _errno 6: 9

_ _errno 6: 10

_ _errno 6: 12

errno 6: 12–13, 19

/etc 9: 3–4

/etc subtree 9: 4

/etc/mnttab 7: 1

/etc/opt 2: 15, 9: 3

/etc/opt/ pkg 9: 5

/etc/passwd 7: 1

example 6: 45

exec(BA _OS) 4: 1, 5: 12–14, 20, 6: 13,

9: 2

execl 6: 8

execle 6: 8

execlp 6: 8

executab le file 4: 1

execv 6: 8

execve 6: 8

execvp 6: 8

exit 5: 26, 6: 4

_exit 6: 6

exit 6: 6

External Data Representation 7: 10

Ffattach 6: 8

fchdir 6: 8

fchmod 6: 8

fchown 6: 8

fclose 6: 6

fcntl 6: 8

fcntl 6: 21

fcvt 6: 9

fdetach 6: 8

fdopen 6: 8

feof 6: 6

ferror 6: 6

fflush 6: 6

ffs 6: 9

fgetc 6: 6

fgetpos 6: 6

fgetpos 6: 21

fgets 6: 6

fgetwc 6: 6

fgetws 6: 6

_ _filbuf 6: 9

Index IN-5



Page: 235



file

archive (see archive file)

object (see object file)

file form ats 7: 1

file system structure and contents 9: 3

fileno 6: 8

filter 6: 25, 11: 7

flash 6: 25, 11: 7

flockfile 6: 8

_ _flsbuf 6: 9

flushinp 6: 25, 11: 7

fnmatch 6: 8

fopen 6: 6

fork 6: 8

fork1 6: 8

forkall 6: 8

formats

archive file 7: 2

object file 4: 1

formats and protocols for networking

7: 10

FORTRAN 4: 11

fpathconf 6: 8

fprintf 6: 6

fputc 6: 6

fputs 6: 6

fputwc 6: 6

fputws 6: 6

fread 6: 6

free 6: 6

freenetconfigent 6: 20freopen 6: 6

frexp 6: 6

fscanf 6: 6

fseek 6: 6

fsetpos 6: 6

fsetpos 6: 21

fstat 6: 11

fstatvfs 6: 8

fsync 6: 8

ftell 6: 6

ftell 6: 21

ftime 6: 9

ftok 6: 8

ftruncate 6: 9

ftrylockfile 6: 8

ftw 6: 9

ftw(BA _LIB) 6: 10

function linkage (see calling

sequence)

funlockfile 6: 8

fwprintf 6: 6

fwrite 6: 6

fwscanf 6: 6

GGARBAGE _ARGS 7: 27, 29

gcvt 6: 9

GeometryCallback 6: 32getbegyx 6: 25, 11: 7

getbkgd 6: 25

getbkgrnd 6: 25

getc 6: 6

getcchar 6: 25

getch 6: 25, 11: 7

getchar 6: 6

getchar _unlocked 6: 8

getcontext 6: 8

getc _unlocked 6: 8

getcwd 6: 8

getdate 6: 8

_getdate _err 6: 12

getdate _err 6: 12

getdtablesize 6: 9

getegid 6: 8

getenv 6: 6

geteuid 6: 8

getgid 6: 8

getgrent 6: 9

getgrgid 6: 8

getgrnam 6: 8

getgroups 6: 8

IN-6 Index



Page: 236



gethostbyaddr 6: 21

gethostbyname 6: 21

gethostent 6: 21

gethostid 6: 9

gethostname 6: 21

getitimer 6: 9

getksym 6: 8

getlogin 6: 8

getlogin _r 6: 8

getmaxyx 6: 25, 11: 7

getmsg 6: 8

getnetbyaddr 6: 21

getnetbyname 6: 21

getnetconfig 6: 20

getnetconfigent 6: 20

getnetent 6: 21

getnetname 6: 20

getnetpath 6: 20

getnstr 6: 25

getn _wstr 6: 25

getnwstr 11: 7

getopt 6: 8

getpagesize 6: 9

getparyx 6: 25, 11: 7

getpass 6: 8

getpass _r 6: 8

getpeername 6: 21

getpgid 6: 8

getpgrp 6: 8

getpid 6: 8

getpmsg 6: 8getppid 6: 8

getpriority 6: 9

getprotobyname 6: 21

getprotobynumber 6: 21

getprotoent 6: 21

getpublickey 6: 20

getpwent 6: 9

getpwnam 6: 8

getpwuid 6: 8

getrlimit 2: 8

getrlimit 6: 8

getrlimit 9: 1

getrusage 6: 9

gets 6: 6

getsecretkey 6: 20

getservbyname 6: 21

getservbyport 6: 21

getservent 6: 21

getsid 6: 8

getsockname 6: 21

getsockopt 6: 21

getstr 6: 25, 11: 7

getsubopt 6: 8

getsyx 11: 7

gettimeofday 6: 9

gettxt 6: 8

getuid 6: 8

getutxent 6: 9

getutxid 6: 9

getutxline 6: 9

getw 6: 8

getwc 6: 6

get _wch 6: 25

getwch 11: 7

getwchar 6: 6

getwd 6: 9

getwin 6: 25, 11: 7

get _wstr 6: 25

getwstr 11: 7

getyx 6: 25, 11: 7

glob 6: 8

global data symbols 6: 11, 32global offset table 4: 19, 5: 13, 21

globfree 6: 8

gmtime 6: 6

gmtime _r 6: 8

grantpt 6: 8

Hhalfdelay 6: 25, 11: 7

has _colors 6: 25, 11: 7

Index IN-7



Page: 237



hash function 5: 21

hash table 4: 16, 19, 5: 13, 17, 21

has _ic 6: 25, 11: 7

has _il 6: 25, 11: 7

hcreate 6: 8

hdestroy 6: 8

header files 6: 46

hline 6: 25, 11: 7

hline _set 6: 25

host2netname 6: 20

hsearch 6: 8

htonl 6: 21

htons 6: 21

Iiconv 6: 8

iconv _close 6: 8iconv _open 6: 8

idcok 6: 25, 11: 7

idlok 6: 25, 11: 7

IEEE POSIX P1003.1 (see POSIX)

ilogb 6: 9

immedok 6: 25, 11: 7

implementation of libc routines 6: 13

INADDR _ANY 12: 8

inch 6: 25, 11: 7

inchnstr 6: 25, 11: 7

inchstr 6: 25, 11: 7

index 6: 9

inet _addr 6: 21

inet _lnaof 6: 21

inet _makeaddr 6: 21

inet _netof 6: 21

inet _network 6: 21

inet _ntoa 6: 21

init 2: 8

init _color 6: 25, 11: 7

initgroups 6: 8

init _pair 6: 25, 11: 7

initscr 6: 25, 11: 7

initstate 6: 9

innstr 6: 25, 11: 7

innwstr 6: 25, 11: 7

insch 6: 25, 11: 7

insdelln 6: 25, 11: 7

insertln 6: 25, 11: 7

insnstr 6: 25, 11: 7

ins _nwstr 6: 25

insnwstr 11: 7

insque 6: 9

insstr 6: 25, 11: 7

install 2: 3, 6

installation and removal scripts

class scripts 2: 12

exit codes 2: 13

postinstall 2: 12

postremove 2: 12

preinstall 2: 12

preremove 2: 12

request 2: 11

installation media

file form ats 2: 1

format 2: 1

software structure 2: 1

installf 2: 12, 16

instr 6: 25, 11: 7

ins _wch 6: 25

inswch 11: 7

ins _wstr 6: 25

inswstr 11: 7

Internet 12: 2, 4interpreter, see program interpreter

5: 12

intrflush 6: 25, 11: 7

in _wch 6: 25

inwch 11: 7

in _wchnstr 6: 25

inwchnstr 11: 7

in _wchstr 6: 25

inwchstr 11: 7

inwstr 6: 25, 11: 7

_ _iob 6: 12

IN-8 Index



Page: 238



libMrm 6: 2–3, 38, 10: 5

see also library 6: 1

libMrm contents 6: 45

libnsl 6: 1–3, 18, 7: 10


libnsl contents 6: 18–20

library

dynam ic (see shared object file)

see also archive file 7: 2

see also libc 6: 1

see also libdl 6: 1

see also libMrm 6: 1

see also libnsl 6: 1

see also libthread 6: 1

see also libX 6: 1

see also libXext 6: 1

see also libXm 6: 1

see also libXt 6: 1

shared (see shared object file)

libsocket 6: 1

libsocket contents 6: 21

libthread 6: 1–3

libthread 6: 15

libthread, see also library 6: 1

libthread contents 6: 15

libX 6: 1–3, 26, 32, 10: 3, 5


libX contents 6: 26

libXext 6: 2–3, 33


libXext contents 6: 33libXm 6: 2–3, 38, 10: 5


libXm contents 6: 38, 44

libXt 6: 1, 3, 34, 10: 5


libXt contents 6: 34, 37

link 6: 8

link editor 4: 1, 24–25, 5: 13, 17, 20, 7: 2,

11: 1

see also dynamic linker 5: 13

linkage, function (see calling

sequence)

lio _listio 6: 16

listen 6: 21

loc1 6: 9

localeconv 6: 6

localeconv(BA _LIB) 6: 12

localtime 6: 6

localtime _r 6: 8

lockf 6: 8

locs 6: 9

log1p 6: 9

logb 6: 8

logging files 9: 6

longjmp 6: 6

_longjmp 6: 9

longname 6: 25, 11: 7

loopback 12: 2

lsearch 6: 8

lseek 6: 8

lseek 6: 21

lstat 6: 11

Mm4 11: 1

magic num ber 4: 5, 7

main 4: 19

makecontext 6: 8

malloc 6: 6

math library 1: 4

MAXNETNAMELEN 7: 34

mblen 6: 6

mbrlen 6: 6

mbrtowc 6: 6

mbsinit 6: 6

mbsrtowcs 6: 6

mbstowcs 6: 6

mbtowc 6: 6

media, format 2: 4

memccpy 6: 8

memchr 6: 6

memcmp 6: 6

IN-10 Index



Page: 240



memcntl 6: 8

memcntl 6: 13

memcpy 6: 6

memmove 6: 6

memory management 5: 6

memset 6: 6

message catalogues 7: 22

meta 6: 25, 11: 7

mkdir 6: 8

mkfifo 6: 8

mknod 6: 11

mkstemp 6: 9

mktemp 6: 8

mktime 6: 6

mlock 6: 8

mmap 6: 8

mmap(KE _OS) 5: 12

mnttab file 7: 1

modadm 6: 8

modf 6: 6

modload 6: 8

modpath 6: 8

modstat 6: 8

moduload 6: 8

MODULUS 7: 35

monitor 6: 8

Motif 10: 4

interface 10: 1

Motif Library 6: 38

mount 6: 8

Mouse _status 6: 25move 6: 25, 11: 7

mprotect 6: 8

MrmCloseHierarchy 6: 45

MrmFetchBitmapLiteral 6: 45

MrmFetchColorLiteral 6: 45

MrmFetchIconLiteral 6: 45

MrmFetchLiteral 6: 45

MrmFetchSetValues 6: 45

MrmFetchWidget 6: 45

MrmFetchWidgetOverride 6: 45

MrmInitialize 6: 45

MrmOpenHierarchy 6: 45

MrmOpenHierarchyPerDisplay 6: 45

MrmRegisterClass 6: 45

MrmRegisterNames 6: 45

MrmRegisterNamesInHierarchy

6: 45

MSG _ACCEPTED 7: 27, 29

msgctl 6: 8

MSG _DENIED 7: 27, 29

msgget 6: 8

msgrcv 6: 8

msgsnd 6: 8

msg _type 7: 27

msync 6: 8

multibyte characters 3: 2

mu ltithreaded app lications 6: 15

multithreading interfaces 6: 15

munlock 6: 8

munmap 6: 8

mutex _destroy 6: 15

mutex _init 6: 15

mutex _lock 6: 15

mutex _trylock 6: 15

mutex _unlock 6: 15

mvaddch 6: 25, 11: 7

mvaddchnstr 6: 25, 11: 7

mvaddchstr 6: 25, 11: 7

mvaddnstr 6: 25, 11: 7

mvaddnwstr 6: 25, 11: 7

mvaddstr 6: 25, 11: 7

mvadd _wch 6: 25mvaddwch 11: 7

mvadd _wchnstr 6: 25

mvaddwchnstr 11: 7

mvadd _wchstr 6: 25

mvaddwchstr 11: 7

mvaddwstr 6: 25, 11: 7

mvchgat 6: 25

mvcur 6: 25, 11: 7

mvdelch 6: 25, 11: 7

mvderwin 6: 25, 11: 7

mvgetch 6: 25, 11: 7

Index IN-11



Page: 241



mvgetnstr 6: 25

mvgetn _wstr 6: 25

mvgetnwstr 11: 7

mvgetstr 6: 25, 11: 7

mvget _wch 6: 25

mvgetwch 11: 7

mvget _wstr 6: 25

mvgetwstr 11: 7

mvhline 6: 25

mvhline _set 6: 25

mvinch 6: 25, 11: 7

mvinchnstr 6: 25, 11: 7

mvinchstr 6: 25, 11: 7

mvinnstr 6: 25, 11: 7

mvinnwstr 6: 25, 11: 7

mvinsch 6: 25, 11: 7

mvinsnstr 6: 25, 11: 7

mvins _nwstr 6: 25

mvinsnwstr 11: 7

mvinsstr 6: 25, 11: 7

mvinstr 6: 25, 11: 7

mvins _wch 6: 25

mvinswch 11: 7

mvins _wstr 6: 25

mvinswstr 11: 7

mvin _wch 6: 25

mvinwch 11: 7

mvin _wchnstr 6: 25

mvinwchnstr 11: 7

mvin _wchstr 6: 25

mvinwchstr 11: 7mvinwstr 6: 25, 11: 7

mvprintw 6: 25, 11: 7

mvscanw 6: 25, 11: 7

mvvline 6: 25

mvvline _set 6: 25

mvwaddch 6: 25, 11: 7

mvwaddchnstr 6: 25, 11: 7

mvwaddchstr 6: 25, 11: 7

mvwaddnstr 6: 25, 11: 7

mvwaddnwstr 6: 25, 11: 7

mvwaddstr 6: 25, 11: 7

mvwadd _wch 6: 25

mvwaddwch 11: 7

mvwadd _wchnstr 6: 25

mvwaddwchnstr 11: 7

mvwadd _wchstr 6: 25

mvwaddwchstr 11: 7

mvwaddwstr 6: 25, 11: 7

mvwchgat 6: 25

mvwdelch 6: 25, 11: 7

mvwgetch 6: 25, 11: 7

mvwgetnstr 6: 25

mvwgetn _wstr 6: 25

mvwgetnwstr 11: 7

mvwgetstr 6: 25, 11: 7

mvwget _wch 6: 25

mvwgetwch 11: 7

mvwget _wstr 6: 25

mvwgetwstr 11: 7

mvwhline 6: 25

mvwhline _set 6: 25

mvwin 6: 25, 11: 7

mvwinch 6: 25, 11: 7

mvwinchnstr 6: 25, 11: 7

mvwinchstr 6: 25, 11: 7

mvwinnstr 6: 25, 11: 7

mvwinnwstr 6: 25, 11: 7

mvwinsch 6: 25, 11: 7

mvwinsnstr 6: 25, 11: 7

mvwins _nwstr 6: 25

mvwinsnwstr 11: 7

mvwinsstr 6: 25, 11: 7mvwinstr 6: 25, 11: 7

mvwins _wch 6: 25

mvwinswch 11: 7

mvwins _wstr 6: 25

mvwinswstr 11: 7

mvwin _wch 6: 25

mvwinwch 11: 7

mvwin _wchnstr 6: 25

mvwinwchnstr 11: 7

mvwin _wchstr 6: 25

mvwinwchstr 11: 7

IN-12 Index



Page: 242



mvwinwstr 6: 25, 11: 7

mvwprintw 6: 25, 11: 7

mvwscanw 6: 25, 11: 7

mvwvline 6: 25

mvwvline _set 6: 25

Nnapms 6: 25, 11: 7

nc _perror 6: 20

nc _sperror 6: 20

_nderror 6: 20

netdir _free 6: 20

netdir _getbyaddr 6: 20

netdir _getbyname 6: 20

netdir _options 6: 20

netdir _perror 6: 20

netdir _sperror 6: 20netname 7: 31, 33

netname2host 6: 20

netname2user 6: 20

network clients 7: 22

network name 7: 31

network service 7: 22

netw ork services library 6: 18

network time synchronization 7: 32

networking 12: 1

networks

loopback 12: 1

peer-to-peer 12: 1

newpad 6: 25, 11: 7

newterm 6: 25, 11: 7

newwin 6: 25, 11: 7

nextafter 6: 8

nftw 6: 8

nice 6: 8

nl 6: 25, 11: 7

nl _langinfo 6: 8

no 6: 25

nocbreak 6: 25, 11: 7

nodelay 6: 25, 11: 7

noecho 6: 25, 11: 7

nonl 6: 25, 11: 7

noqiflush 6: 25, 11: 7

noraw 6: 25, 11: 7

notimeout 6: 25, 11: 7

ntohl 6: 21

ntohs 6: 21

numcodes 6: 25

_numeric 6: 12

nu merical limits 9: 1

numfnames 6: 25

numnames 6: 25

Oobject file 4: 1

archive file 4: 24, 7: 2

data representation 4: 3data types 4: 3

ELF head er 4: 2, 4

extensions 4: 6

format 4: 1

hash table 5: 13, 17, 21

program header 4: 2, 5: 2

program loading 5: 2

relocation 4: 16, 27, 5: 17

section 4: 2, 10

section alignment 4: 13

section attribu tes 4: 15

section header 4: 2, 10

section names 4: 20

section typ es 4: 13

see also archive file 4: 1


see also executable file 4: 1

see also relocatable file 4: 1

see also shared object file 4: 1

segment 5: 1–2

shared object file 5: 13

special sections 4: 17

string table 4: 16, 21–22

Index IN-13



Page: 243



symbol table 4: 16, 22

type 4: 5

version 4: 6

objectClass 6: 37

objectClassRec 6: 37

opaque _auth 7: 25, 30

open 6: 8

opendir 6: 8

openlog 6: 9

/opt 2: 15, 9: 3–5

/opt subtree 9: 5

optarg 6: 12

opterr 6: 12

optind 6: 12

optopt 6: 12

/opt/ pkg/bin 9: 5

outchcount 6: 25

overlay 6: 25, 11: 7

overrideShellClassRec 6: 37

overrideShellWidgetClass 6: 37

overwrite 6: 25, 11: 7

Ppackage installation 9: 3

packages 2: 2–16

pair _content 6: 25, 11: 7

password file 7: 1

PATH 8: 1, 11: 3

pathconf 6: 8

pathconf 9: 1

pause 6: 8

pckt 12: 2

pclose 6: 8

pechochar 6: 25, 11: 7

pecho _wchar 6: 25

pechowchar 11: 7

perm issions, process segments (see

segment permissions)

per-process environment information

9: 2

perror 6: 6

pipe 6: 8

pipemod 12: 2

pkgadd 2: 7–8, 16

pkgask 2: 8, 16

pkgchk 2: 16

pkginfo 2: 3, 5–9, 11–12, 16

pkgmap 2: 3, 8–10, 12

pkgmk 11: 3

pkgparam 2: 16

pkgproto 11: 3

pkgrm 2: 7, 16

pkgtrans 11: 3

pnoutrefresh 6: 25, 11: 7

poll 6: 8

pool 6: 21

popen 6: 8

position-ind epend ent code 5: 13

POSIX 1: 2, 6: 1, 10, 15, 46, 7: 6, 9: 1

POSIX 1003.1c 6: 15

POSIX 1003.4a 6: 15

PostScript 10: 4

pread 6: 8

PreeditCaretCallback 6: 32

PreeditDoneCallback 6: 32

PreeditDrawCallback 6: 32

PreeditStartCallback 6: 32

prefresh 6: 25, 11: 7

printf 6: 6

printw 6: 25, 11: 7

priocntl 6: 8priocntllist 6: 8

procedure linkage table 4: 19, 25, 5: 13,

16–17, 19, 21

process

entry point 4: 6, 19, 5: 22

image 4: 1, 5: 1–2

virtual add ressing 5: 2

processor-specific 5: 13

processor-specific information 3: 1,

3–6, 4: 5–6, 8–10, 15–16, 20, 24–25,

27–28, 5: 1, 4, 6–7, 11, 13, 19, 21, 6: 11,

47, 9: 4, 11: 2–4

IN-14 Index



Page: 244



PROC _UNAVAIL 7: 27, 29

profil 6: 8

PROG _MISMATCH 7: 27, 29

program header 5: 2

program interpreter 4: 19, 5: 12–13

program loading 5: 1, 11

programming language, ABI refer-

ence 3: 1

PROG _UNAVAIL 7: 27, 29

pro tocol version 2 7: 24

pseudo terminal 12: 2

ptem 12: 2

ptrace 6: 8

ptsname 6: 8

putc 6: 6

putc(BA _LIB) 6: 9

putchar 6: 6

putchar _unlocked 6: 8

putc _unlocked 6: 8

putenv 6: 8

putmsg 6: 8

putp 6: 25, 11: 7

putpmsg 6: 8

puts 6: 6

pututxline 6: 9

putw 6: 8

putwc 6: 6

putwchar 6: 6

putwin 6: 25, 11: 7

pwrite 6: 8

Qqiflush 6: 25, 11: 7

qsort 6: 6

Rraise 6: 6

rand 6: 6

random 6: 9

rand _r 6: 8

raw 6: 25, 11: 7

read 6: 8

read 6: 21

readdir 6: 8

readdir _r 6: 8

readlink 6: 8

readv 6: 8

realloc 6: 6

realpath 6: 9

re _comp 6: 9

rectObjClass 6: 37

rectObjClassRec 6: 37

recv 6: 21

recvfrom 6: 21

recvmsg 6: 21

redrawwin 6: 25, 11: 7

re _exec 6: 9

refresh 6: 25, 11: 7

regcmp 6: 9

regcomp 6: 8

regerror 6: 8

regex 6: 9

regexec 6: 8

regexp 6: 9

regfree 6: 8

rejected _reply 7: 30

reject _stat 7: 27

reliable byte stream protocols 7: 26

reloc 2: 3, 6

relocatable file 4: 1relocation , see object file 4: 27

remove 6: 6

removef 2: 12, 16

remque 6: 9

rename 6: 6

REPLY 7: 27–28

reply _body 7: 29

reply _stat 7: 27

requ ired sizes for some d ata objects

6: 46

requirements, summ ary 10: 5

Index IN-15



Page: 245



reset _prog _mode 6: 25, 11: 7

reset _shell _mode 6: 25, 11: 7

resetty 6: 25, 11: 7

restartterm 6: 25, 11: 7

rewind 6: 6

rewinddir 6: 8

rindex 6: 9

rint 6: 9

ripoffline 6: 25, 11: 7

rmdir 6: 8

rmutex _destroy 6: 15

rmutex _init 6: 15

rmutex _lock 6: 15

rmutex _trylock 6: 15

rmutex _unlock 6: 15

root 2: 3, 6

root subtree 9: 3

RPC

authentication 7: 23, 25

authentication protocols 7: 30

basic authen tication for UN IX Sys-

tems 7: 30

batching 7: 26

binding and rendezvous indepen-

dence 7: 23

broadcast 7: 26

DES authen tication 7: 31

DES auth entication verifiers 7: 32

DES nicknam es and clock synchroni-

zation 7: 33

message protocol 7: 27naming 7: 31

null authentication 7: 30

program number assignment 7: 25

programs and procedures 7: 24

record marking stand ard 7: 36

transports and semantics 7: 22

uses of the RPC protocol 7: 26

RPC _AUTHERROR 7: 33

rpcb _getaddr 6: 20

rpcb _getmaps 6: 20

rpcb _gettime 6: 20

rpcbind 7: 22, 26, 37–38

mechanism 7: 37

operation 7: 38

protocol 7: 23

pr otocol specification 7: 37

RPCBPROC _CALLIT 7: 37–38

RPCBPROC _DUMP 7: 37–38

RPCBPROC _GETADDR 7: 37–38

RPCBPROC _GETTIME 7: 37, 39

RPCBPROC _NULL 7: 37

RPCBPROC _SET 7: 37–38

RPCBPROC _UNSET 7: 37–38

RPCBPROG 7: 37

rpcb _rmtcall 6: 20

rp c _broadcast 6: 20

rp c _broadcast _exp 6: 20

rpcb _set 6: 20

rpcb _unset 6: 20

RPCBVERS 7: 37

rp c _call 6: 20

rpc _createerr 6: 20

RPC _MISMATCH 7: 27, 30

rpc _msg 7: 28

rp c _reg 6: 20

rwlock _destroy 6: 15

rwlock _init 6: 15

rw _rdlock 6: 15

rw _tryrdlock 6: 15

rw _trywrlock 6: 15

rw _unlock 6: 15

rw _wrlock 6: 15

SSARMAG 7: 2

savetty 6: 25, 11: 7

sbrk 6: 9

scalb 6: 8

scanf 6: 6

scanw 6: 25, 11: 7

scr _dump 6: 25, 11: 7

IN-16 Index



Page: 246



screenConvertArg 6: 37

scr _init 6: 25, 11: 7

scripts 2: 3

scrl 6: 25, 11: 7

scroll 6: 25, 11: 7

scrollok 6: 25, 11: 7

scr _restore 6: 25, 11: 7

scr _set 6: 25, 11: 7

SD _CMD 11: 1

security control mechanisms 7: 23

sed 2: 13

seekdir 6: 8

segment

dynamic 5: 12, 14

object file 5: 1–2

process 5: 1, 12–13, 19

program header 5: 2

segment p ermissions 5: 5

select 6: 9, 21

sema _destroy 6: 15

sema _init 6: 15

sema _post 6: 15

sema _trywait 6: 15

sema _wait 6: 15

semctl 6: 8

semget 6: 8

semop 6: 8

send 6: 21

sendmsg 6: 21

sendto 6: 21

server 7: 22, 10: 4setbuf 6: 6

setcat 6: 8

setcchar 6: 25

setcontext 6: 8

set _curterm 6: 25, 11: 7

setgid 6: 8

setgrent 6: 9

setgroups 6: 8

sethostent 6: 21

setitimer 6: 9

setjmp 6: 6

_setjmp 6: 9

setlabel 6: 8

setlocale 6: 6

setlocale(BA _OS) 6: 12

setlogmask 6: 9

setnetconfig 6: 20

setnetent 6: 21

setnetpath 6: 20

setpgid 6: 8

setpgrp 6: 8

setpriority 6: 9

setprotoent 6: 21

setpwent 6: 9

setregid 6: 9

setreuid 6: 9

setrlimit 6: 8

setscrreg 6: 25, 11: 7

setservent 6: 21

setsid 6: 8

setsockopt 6: 21

setstate 6: 9

setsyx 11: 7

set _term 6: 25, 11: 7

setterm 11: 7

setuid 6: 8

setupterm 6: 25, 11: 7

set-user ID p rograms 5: 21

setutxent 6: 9

setvbuf 6: 6

sh 2: 11

shared library (see shared object file)shared library names 6: 3

shared object file 4: 1, 6: 1

functions 4: 25


see also object file 5: 13

shell scripts 4: 1

shellClassRec 6: 37

shellWidgetClass 6: 37

shmat 6: 8

shmctl 6: 8

shmdt 6: 8

Index IN-17



Page: 247



shmget 6: 8

shutdown 6: 21

sigaction 6: 8

sigaddset 6: 8

sigaltstack 6: 8

sigdelset 6: 8

sigemptyset 6: 8

sigfillset 6: 8

sighold 6: 8

sigignore 6: 8

siginterrupt 6: 9

sigismember 6: 8

siglongjmp 6: 8

signal 6: 6

signgam 6: 9

sigpause 6: 8

sigpending 6: 8

sigprocmask 6: 8

sigrelse 6: 8

sigsend 6: 8

sigsendset 6: 8

sigset 6: 8

sigsetjmp 6: 8

sigstack 6: 9

sigsuspend 6: 8

sigwait 6: 8

sin 6: 2

sleep 6: 8

slk _attr _off 6: 25

slk _attroff 6: 25, 11: 7

slk _attr _on 6: 25slk _attron 6: 25, 11: 7

slk _attr _set 6: 25

slk _attrset 6: 25, 11: 7

slk _clear 6: 25, 11: 7

slk _init 6: 25, 11: 7

slk _label 6: 25, 11: 7

slk _noutrefresh 6: 25, 11: 7

slk _refresh 6: 25, 11: 7

slk _restore 6: 25, 11: 7

slk _set 6: 25, 11: 7

slk _touch 6: 25, 11: 7

slk _wset 6: 25

snprintf 6: 8

socket 6: 21

socketpair 6: 21

software structure 2: 2–16

SP 6: 25

space 2: 3, 10

sprintf 6: 6

srand 6: 6

srandom 6: 9

sscanf 6: 6

standend 6: 25, 11: 7

standout 6: 25, 11: 7

start _color 6: 25, 11: 7

stat 2: 10, 6: 11, 7: 3

StatusDoneCallback 6: 32

StatusDrawCallback 6: 32

StatusStartCallback 6: 32

statvfs 6: 8

stdscr 6: 25

stime 6: 8

strcasecmp 6: 9

strcat 6: 6

strchr 6: 6

strcmp 6: 6

strcodes 6: 25

strcoll 6: 6

strcpy 6: 6

strcspn 6: 6

strdup 6: 8

STREAMS-based pipe 12: 3strerror 6: 6

strfmon 6: 8

strfnames 6: 25

strftime 6: 6

string table

see archive file 7: 2

see object file 4: 21

strlen 6: 6

strlist 6: 8

strnames 6: 25

strncasecmp 6: 9

IN-18 Index



Page: 248



strncat 6: 6

strncmp 6: 6

strncpy 6: 6

strpbrk 6: 6

strptime 6: 8

strrchr 6: 6

strspn 6: 6

strstr 6: 6

strtod 6: 6

strtof 6: 8

strtok 6: 6

strtok _r 6: 8

strtol 6: 6

strtold 6: 8

strtoul 6: 6

strxfrm 6: 6

subpad 6: 25, 11: 7

subwin 6: 25, 11: 7

SUCCESS 7: 27, 29

sum 2: 10

svc _create 6: 20

svc _dg _create 6: 20

svcerr _auth 6: 20

svcerr _decode 6: 20

svcerr _noproc 6: 20

svcerr _noprog 6: 20

svcerr _progvers 6: 20

svcerr _systemerr 6: 20

svcerr _weakauth 6: 20

svc _fd _create 6: 20

svc _fdset 6: 20svc _getreq _common 6: 20

svc _getreq _poll 6: 20

svc _getreqset 6: 20

svc _raw _create 6: 20

svc _reg 6: 20

svc _ru n 6: 20

svc _sendreply 6: 20

svc _tli _create 6: 20

svc _tp _create 6: 20

svc _unreg 6: 20

svc _vc _create 6: 20

SVID 11: 1, 3–4, 12: 2

swab 6: 8

swapcontext 6: 8

swprintf 6: 6

swscanf 6: 6

symbol names, C and assembly 4: 22

symbol table, see object file 4: 22

symbols

absolute 4: 11

binding 4: 23

common 4: 11

see also hash table 4: 19

shared object file fun ctions 4: 25

type 4: 24

undefined 4: 10

value 4: 24, 26

symlink 6: 8

sync 6: 8

syncok 6: 25, 11: 7

sysconf 6: 8

sysconf 9: 1

syslog 6: 9

system 6: 6

system 9: 2

system calls 6: 5

extensions 6: 14

_$vendor.company 6: 14

system data interfaces 6: 46

system iden tification 9: 1

TTABSIZE 6: 25

t _accept 6: 18

t _accept 12: 8

T _ACCEPT1 12: 5

T _ACCEPT2 12: 5

T _ACCEPT3 12: 5

TACCES 12: 4

T _ADDR 12: 5

taddr2uaddr 6: 20

Index IN-19



Page: 249



TADDRBUSY 12: 4

T _ALL 12: 5

t _alloc 6: 18

TBADADDR 12: 4

TBADDATA 12: 4

TBADF 12: 4

TBADFLAG 12: 4

TBADNAME 12: 4

TBADOPT 12: 4

TBADQLEN 12: 4

TBADSEQ 12: 4

t _bind 6: 18

T _BIND 12: 5

t _bind 12: 8

TBUFOVFLW 12: 4

T _CALL 12: 5

tcdrain 6: 8

tcflow 6: 8

tcflush 6: 8

tcgetattr 6: 8

tcgetpgrp 6: 8

tcgetsid 6: 8

T _CHECK 12: 4

t _close 6: 18

T _CLOSE 12: 5

T _CLTS 12: 4, 8

t _connect 6: 18

T _CONNECT 12: 4

t _connect 12: 8

T _CONNECT1 12: 5

T _CONNECT2 12: 5T _COTS 12: 4

T _COTS _ORD 12: 4, 8

TCP/ IP 7: 22, 26, 36

tcsendbreak 6: 8

tcsetattr 6: 8

tcsetpgrp 6: 8

T _DATA 12: 4

T _DATAXFER 12: 5

T _DEFAULT 12: 4

tdelete 6: 8

T _DIS 12: 5

T _DISCONNECT 12: 4

tell 6: 8

telldir 6: 8

tempnam 6: 8

temporary files 9: 6

termattrs 6: 25, 11: 7

term _errno 6: 25

terminfo(TI _ENV) 7: 7

termname 6: 25, 11: 7

term _parm _err 6: 25

t _errno 6: 20

t _error 6: 18

T _ERROR 12: 4

T _EVENTS 12: 4

T _EXDATA 12: 4

T _EXPEDITED 12: 4

T _FAILURE 12: 4

T _FAKE 12: 5

tfind 6: 8

TFLOW 12: 4

t _free 6: 18

tgetent 6: 25, 11: 7

tgetflag 6: 25, 11: 7

t _getinfo 6: 18

t _getinfo 12: 9

tgetnum 6: 25, 11: 7

t _getstate 6: 18

tgetstr 6: 25, 11: 7

tgoto 6: 25, 11: 7

thr _continue 6: 15

thr _create 6: 15Threads Library 6: 15

_ _thr _errno 6: 9–10

_ _thr _errno 6: 12

thr _exit 6: 15

thr _getconcurrency 6: 15

thr _getprio 6: 15

thr _get _rr _interval 6: 15

thr _getscheduler 6: 15

thr _getspecific 6: 15

thr _join 6: 15

thr _keycreate 6: 15

IN-20 Index



Page: 250



thr _keydelete 6: 15

thr _kill 6: 15

thr _minstack 6: 15

thr _self 6: 15

thr _setconcurrency 6: 15

thr _setprio 6: 15

thr _setscheduler 6: 15

thr _setspecific 6: 15

thr _sigsetmask 6: 15

thr _suspend 6: 15

thr _yield 6: 15

T _IDLE 12: 5

tigetflag 6: 25, 11: 7

tigetnum 6: 25, 11: 7

tigetstr 6: 25, 11: 7

time 6: 8

time 7: 3, 9: 1

timeout 6: 25, 11: 7

times 6: 8

timestamp 7: 34

_timezone 6: 12

timezone 6: 12

timod 12: 2, 4

T _INCON 12: 5

TINDOUT 12: 4

T _INFO 12: 5

T _INREL 12: 5

tirdwr 12: 2, 4

t _listen 6: 18

T _LISTEN 12: 4

t _listen 12: 9T _LISTN 12: 5

t _look 6: 18

TLOOK 12: 4

T _MORE 12: 4

tmpfile 6: 6

tmpnam 6: 6

T _NEGOTIATE 12: 4

TNOADDR 12: 4

TNODATA 12: 4

TNODIS 12: 4

TNOREL 12: 4

T _NOSTATES 12: 5

TNOSTRUCTYPE 12: 4

TNOTSUPPORT 12: 4

TNOUDERR 12: 4

toascii 6: 8

tolower 6: 6

_tolower 6: 9

t _open 6: 18

T _OPEN 12: 5

t _open 12: 9

topLevelShellClassRec 6: 37

topLevelShellWidgetClass 6: 37

T _OPT 12: 5

t _optmgmt 6: 18

T _OPTMGMT 12: 5

t _optmgmt 12: 10

T _ORDREL 12: 4

touchline 6: 25, 11: 7

touchwin 6: 25, 11: 7

toupper 6: 6

_toupper 6: 9

T _OUTCON 12: 5

T _OUTREL 12: 5

TOUTSTATE 12: 4

towlower 6: 6

towupper 6: 6

tparm 6: 25, 11: 7

T _PASSCON 12: 5

TPROTO 12: 4

TPROVMISMATCH 12: 4

tputs 6: 25, 11: 7TQFULL 12: 4

transientShellClassRec 6: 37

transientShellWidgetClass 6: 37

transport 12: 2

t _rcv 6: 18

T _RCV 12: 5

t _rcv 12: 12

t _rcvconnect 6: 18

T _RCVCONNECT 12: 5

t _rcvconnect 12: 12

t _rcvdis 6: 18

Index IN-21



Page: 251



T _RCVDIS1 12: 5

T _RCVDIS2 12: 5

T _RCVDIS3 12: 5

t _rcvrel 6: 18

T _RCVREL 12: 5

t _rcvudata 6: 18

T _RCVUDATA 12: 5

t _rcvudata 12: 12

t _rcvuderr 6: 18

T _RCVUDERR 12: 5

t _rcvuderr 12: 12

truncate 6: 9

_ _trwctype 6: 9

tsearch 6: 8

t _snd 6: 18

T _SND 12: 5

t _snd 12: 12

t _snddis 6: 18

t _snddis 12: 13

T _SNDDIS1 12: 5

T _SNDDIS2 12: 5

t _sndrel 6: 18

T _SNDREL 12: 5

t _sndrel 12: 13

t _sndudata 6: 18

T _SNDUDATA 12: 5

t _sndudata 12: 13

TSTATECHNG 12: 4

T _SUCCESS 12: 4

t _sync 6: 18

TSYSERR 12: 4ttyname 6: 8

ttyname _r 6: 8

ttyslot 6: 9

ttytype 6: 25

T _UDATA 12: 5

T _UDERR 12: 4

T _UDERROR 12: 5

t _unbind 6: 18

T _UNBIND 12: 5

T _UNBND 12: 5

T _UNINIT 12: 5

T _UNITDATA 12: 5

twalk 6: 8

typeahead 6: 25, 11: 7

_tzname 6: 12

tzname 6: 12

tzset 6: 8

tzset(BA _LIB) 6: 12

Uuaddr2taddr 6: 20

ualarm 6: 9

UDP/ IP 7: 22, 26

_ _ctype 6: 12

ulimit 6: 8

_ _iob 6: 12

_ _trwctype(wint _t wc, wctype _t

charclass) 6: 10umask 6: 8

umount 6: 8

uname 6: 11, 9: 1

unctrl 6: 25, 11: 7

undefined behavior 1: 8, 4: 13, 5: 10,

6: 14

und efined symbols 4: 10

ungetc 6: 6

ungetch 6: 25, 11: 7

ungetwc 6: 6

unget _wch 6: 25

ungetwch 11: 7

unlink 6: 8

unlockpt 6: 8

unspecified property 4: 2, 5, 10–11,

15–16, 18–19, 24–25, 5: 2, 4, 6, 9, 18–19,

6: 5, 11

untouchwin 6: 25, 11: 7

use _env 6: 25, 11: 7

user2netname 6: 20

usleep 6: 9

/usr 9: 3–5

/usr subtree 9: 5

IN-22 Index



Page: 252



wclear 6: 25, 11: 7

wclrtobot 6: 25, 11: 7

wclrtoeol 6: 25, 11: 7

wcolor _set 6: 25

wcrtomb 6: 6

wcscat 6: 6

wcschr 6: 6

wcscmp 6: 6

wcscoll 6: 6

wcscpy 6: 6

wcscspn 6: 6

wcsftime 6: 6

wcslen 6: 6

wcsncat 6: 6

wcsncmp 6: 6

wcsncpy 6: 6

wcspbrk 6: 6

wcsrchr 6: 6

wcsrtombs 6: 6

wcsspn 6: 6

wcsstr 6: 6

wcstod 6: 6

wcstof 6: 8

wcstok 6: 6

wcstol 6: 6

wcstold 6: 8

wcstombs 6: 6

wcstoul 6: 6

wcswcs 6: 9

wcswidth 6: 8

wcsxfrm 6: 6wctob 6: 6

wctomb 6: 6

wctype 6: 6

wcursyncup 6: 25, 11: 7

wcwidth 6: 8

wdelch 6: 25, 11: 7

wdeleteln 6: 25, 11: 7

wechochar 6: 25, 11: 7

wecho _wchar 6: 25

wechowchar 11: 7

werase 6: 25, 11: 7

wgetbkgrnd 6: 25

wgetch 6: 25, 11: 7

wgetnstr 6: 25, 11: 7

wgetn _wstr 6: 25

wgetnwstr 11: 7

wgetstr 6: 25, 11: 7

wget _wch 6: 25

wgetwch 11: 7

wget _wstr 6: 25

wgetwstr 11: 7

whline 6: 25, 11: 7

whline _set 6: 25

widgetClass 6: 37

widgetClassRec 6: 37

winch 6: 25, 11: 7

winchnstr 6: 25, 11: 7

winchstr 6: 25, 11: 7

window manager 10: 4

window system 10: 1

components 10: 3

winnstr 6: 25, 11: 7

winnwstr 6: 25, 11: 7

winsch 6: 25, 11: 7

winsdelln 6: 25, 11: 7

winsertln 6: 25, 11: 7

winsnstr 6: 25, 11: 7

wins _nwstr 6: 25

winsnwstr 11: 7

winsstr 6: 25, 11: 7

winstr 6: 25, 11: 7

wins _wch 6: 25winswch 11: 7

wins _wstr 6: 25

winswstr 11: 7

win _wch 6: 25

winwch 11: 7

win _wchnstr 6: 25

winwchnstr 11: 7

win _wchstr 6: 25

winwchstr 11: 7

winwstr 6: 25, 11: 7

wmove 6: 25, 11: 7

IN-24 Index



Page: 254



wmShellClassRec 6: 37

wmShellWidgetClass 6: 37

wnoutrefresh 6: 25, 11: 7

wordexp 6: 8

wordfree 6: 8

wprintf 6: 6

wprintw 6: 25, 11: 7

wredrawln 6: 25, 11: 7

wrefresh 6: 25, 11: 7

write 6: 8

write 6: 21

writev 6: 8

wscanf 6: 6

wscanw 6: 25, 11: 7

wscrl 6: 25, 11: 7

wsetscrreg 6: 25, 11: 7

wstandend 6: 25, 11: 7

wstandout 6: 25, 11: 7

wsyncdown 6: 25, 11: 7

wsyncup 6: 25, 11: 7

wtimeout 6: 25, 11: 7

wtouchln 6: 25, 11: 7

wunctrl 6: 25

wvline 6: 25, 11: 7

wvline _set 6: 25

XX Toolkit Int rinsics 6: 1, 34

X toolkit int rinsics 10: 3

X Toolkit Intrin sics Library 6: 34

X Window System 1: 2, 6: 1, 26

X Window System Library 1: 5, 6: 26

X11 Nonrectangular Wind ow Shape

Extension 10: 3

interface 10: 1

X11 Nonrectangular Wind ow Shape

Extension Library 6: 33

X11 protocol 10: 2

X11 Toolkit Intrin sics, interface 10: 1

X11 Window System 9: 5

interface 10: 1

overview 10: 2

XActivateScreenSaver 6: 31

XAddExtension 6: 31

XAddHost 6: 31

XAddHosts 6: 31

XAddPixel 6: 31

XAddToExtensionList 6: 31

XAddToSaveSet 6: 31

XAllocClassHint 6: 31

XAllocColor 6: 31

XAllocColorCells 6: 31

XAllocColorPlanes 6: 31

XAllocIconSize 6: 31

XAllocNamedColor 6: 31

XAllocSizeHints 6: 31

XAllocStandardColormap 6: 31

XAllocWMHints 6: 31

XAllowEvents 6: 31

XAllPlanes 6: 31

XAutoRepeatOff 6: 31

XAutoRepeatOn 6: 31

XBaseFontNameListOfFontSet 6: 31

XBell 6: 31

XBitmapBitOrder 6: 31

XBitmapPad 6: 31

XBitmapUnit 6: 31

XBlackPixel 6: 31

XBlackPixelOfScreen 6: 31

XCellsOfScreen 6: 31

XChangeActivePointerGrab 6: 31XChangeGC 6: 31

XChangeKeyboardControl 6: 31

XChangeKeyboardMapping 6: 31

XChangePointerControl 6: 31

XChangeProperty 6: 31

XChangeSaveSet 6: 31

XChangeWindowAttributes 6: 31

XCheckIfEvent 6: 31

XCheckMaskEvent 6: 31

XCheckTypedEvent 6: 31

XCheckTypedWindowEvent 6: 31

Index IN-25



Page: 255



XCheckWindowEvent 6: 31

XCirculateSubwindows 6: 31

XCirculateSubwindowsDown 6: 31

XCirculateSubwindowsUp 6: 31

XClearArea 6: 31

XClearWindow 6: 31

XClipBox 6: 31

XCloseDisplay 6: 31

XCloseIM 6: 31

XcmsAddColorSpace 6: 31

XcmsAddFunctionSet 6: 31

XcmsAllocColor 6: 31

XcmsAllocNamedColor 6: 31

XcmsCCCofColormap 6: 31

XcmsCIELabClipab 6: 31

XcmsCIELabClipL 6: 31

XcmsCIELabClipLab 6: 31

XcmsCIELabColorSpace 6: 32

XcmsCIELabQueryMaxC 6: 31

XcmsCIELabQueryMaxL 6: 31

XcmsCIELabQueryMaxLC 6: 31

XcmsCIELabQueryMinL 6: 31

XcmsCIELabToCIEXYZ 6: 31

XcmsCIELabWhiteShiftColors 6: 31

XcmsCIELuvClipL 6: 31

XcmsCIELuvClipLuv 6: 31

XcmsCIELuvClipuv 6: 31

XcmsCIELuvColorSpace 6: 32

XcmsCIELuvQueryMaxC 6: 31

XcmsCIELuvQueryMaxL 6: 31

XcmsCIELuvQueryMaxLC 6: 31XcmsCIELuvQueryMinL 6: 31

XcmsCIELuvToCIEuvY 6: 31

XcmsCIELuvWhiteShiftColors 6: 31

XcmsCIEuvYColorSpace 6: 32

XcmsCIEuvYToCIELuv 6: 31

XcmsCIEuvYToCIEXYZ 6: 31

XcmsCIEuvYToTekHVC 6: 31

XcmsCIExyYColorSpace 6: 32

XcmsCIExyYToCIEXYZ 6: 31

XcmsCIEXYZColorSpace 6: 32

XcmsCIEXYZToCIELab 6: 31

XcmsCIEXYZToCIEuvY 6: 31

XcmsCIEXYZToCIExyY 6: 31

XcmsCIEXYZToRGBi 6: 31

XcmsClientWhitePointOfCCC 6: 31

XcmsConvertColors 6: 31

XcmsCreateCCC 6: 31

XcmsDefaultCCC 6: 31

XcmsDisplayOfCCC 6: 31

XcmsFormatOfPrefix 6: 31

XcmsFreeCCC 6: 31

XcmsLinearRGBFunctionSet 6: 32

XcmsLookupColor 6: 31

XcmsPrefixOfFormat 6: 31

XcmsQueryBlack 6: 31

XcmsQueryBlue 6: 31

XcmsQueryColor 6: 31

XcmsQueryColors 6: 31

XcmsQueryGreen 6: 31

XcmsQueryRed 6: 31

XcmsQueryWhite 6: 31

XcmsRGBColorSpace 6: 32

XcmsRGBiColorSpace 6: 32

XcmsRGBiToCIEXYZ 6: 31

XcmsRGBiToRGB 6: 31

XcmsRGBToRGBi 6: 31

XcmsScreenNumberOfCCC 6: 31

XcmsScreenWhitePointOfCCC 6: 31

XcmsSetCompressionProc 6: 31

XcmsSetWhiteAdjustProc 6: 31

XcmsSetWhitePoint 6: 31

XcmsStoreColor 6: 31XcmsStoreColors 6: 31

XcmsTekHVCCColorSpace 6: 32

XcmsTekHVCClipC 6: 31

XcmsTekHVCClipV 6: 31

XcmsTekHVCClipVC 6: 31

XcmsTekHVCQueryMaxC 6: 31

XcmsTekHVCQueryMaxV 6: 31

XcmsTekHVCQueryMaxVC 6: 31

XcmsTekHVCQueryMaxVSamples

6: 31

XcmsTekHVCQueryMinV 6: 31

IN-26 Index



Page: 256



XcmsTekHVCToCIEuvY 6: 31

XcmsTekHVCWhiteShiftColors 6: 31

XcmsUNDEFINEDColorSpace 6: 32

XcmsVisualOfCCC 6: 31

XConfigureWindow 6: 31

XConnectionNumber 6: 31

XContextDependentDrawing 6: 31

XConvertSelection 6: 31

XCopyArea 6: 31

XCopyColormapAndFree 6: 31

XCopyGC 6: 31

XCopyPlane 6: 31

XCreateBitmapFromData 6: 31

XCreateColormap 6: 31

XCreateFontCursor 6: 31

XCreateFontSet 6: 31

XCreateGC 6: 31

XCreateGlyphCursor 6: 31

XCreateIC 6: 31

XCreateImage 6: 31

XCreatePixmap 6: 31

XCreatePixmapCursor 6: 31

XCreatePixmapFromBitmapData

6: 31

XCreateRegion 6: 31

XCreateSimpleWindow 6: 31

XCreateWindow 6: 31

XDefaultColormap 6: 31

XDefaultColormapOfScreen 6: 31

XDefaultDepth 6: 31

XDefaultDepthOfScreen 6: 31XDefaultGC 6: 31

XDefaultGCOfScreen 6: 31

XDefaultRootWindow 6: 31

XDefaultScreen 6: 31

XDefaultScreenOfDisplay 6: 31

XDefaultString 6: 31

XDefaultVisual 6: 31

XDefaultVisualOfScreen 6: 31

XDefineCursor 6: 31

XDeleteContext 6: 31

XDeleteModifiermapEntry 6: 31

XDeleteProperty 6: 31

XDestroyIC 6: 31

XDestroyImage 6: 31

XDestroyRegion 6: 31

XDestroySubwindows 6: 31

XDestroyWindow 6: 31

XDisableAccessControl 6: 31

XDisplayCells 6: 31

XDisplayHeight 6: 31

XDisplayHeightMM 6: 31

XDisplayKeycodes 6: 31

XDisplayMotionBufferSize 6: 31

XDisplayName 6: 31

XDisplayOfIM 6: 31

XDisplayOfScreen 6: 31

XDisplayPlanes 6: 31

XDisplayString 6: 31

XDisplayWidth 6: 31

XDisplayWidthMM 6: 31

XDoesBackingStore 6: 31

XDoesSaveUnders 6: 31

XDR

array, fixed length 7: 16

array, variable length 7: 17

basic block size 7: 10

block size 7: 10

boolean 7: 12

constant 7: 19

data, optional 7: 20

data types 7: 11

discriminated u nion 7: 18double-precision floating-point

integer 7: 13

enumeration 7: 12

fixed-length array 7: 16

fixed-length opaque d ata 7: 14

floating-point integer 7: 12

integer 7: 11

integer, dou ble-precision floating

point 7: 13

integer, floating point 7: 12

integers 7: 36

Index IN-27



Page: 257



opaqu e data, fixed length 7: 14

opaqu e d ata, variable length 7: 14

optional data 7: 20

protocol specification 7: 10

string 7: 15

structure 7: 17

typedef 7: 19

union discriminated 7: 18

unsigned integer 7: 11

variable-length array 7: 17

variable-length opaqu e d ata 7: 14

void 7: 19

xdr _accepted _reply 6: 20

xdr _array 6: 20

xdr _authsys _parms 6: 20

XDrawArc 6: 31

XDrawArcs 6: 31

XDrawImageString 6: 31

XDrawImageString16 6: 31

XDrawLine 6: 31

XDrawLines 6: 31

XDrawPoint 6: 31

XDrawPoints 6: 31

XDrawRectangle 6: 31

XDrawRectangles 6: 31

XDrawSegments 6: 31

XDrawString 6: 31

XDrawString16 6: 31

XDrawText 6: 31

XDrawText16 6: 31

xdr _bool 6: 20xdr _bytes 6: 20

xdr _callhdr 6: 20

xdr _callmsg 6: 20

xdr _char 6: 20

xdr _double 6: 20

xdr _enum 6: 20

xdr _float 6: 20

xdr _free 6: 20

xdr _int 6: 20

xdr _long 6: 20

xdrmem _create 6: 20

xdr _opaque 6: 20

xdr _opaque _auth 6: 20

xdr _pointer 6: 20

xdrrec _create 6: 20

xdrrec _endofrecord 6: 20

xdrrec _eof 6: 20

xdrrec _skiprecord 6: 20

xdr _reference 6: 20

xdr _rejected _reply 6: 20

xdr _replymsg 6: 20

xdr _short 6: 20

xdrstdio _create 6: 20

xdr _string 6: 20

xdr _u _char 6: 20

xdr _u _int * 6: 20

xdr _u _long 6: 20

xdr _union 6: 20

xdr _u _short 6: 20

xdr _vector 6: 20

xdr _void 6: 20

xdr _wrapstring 6: 20

XEmptyRegion 6: 31

XEnableAccessControl 6: 31

XEqualRegion 6: 31

XEventMaskOfScreen 6: 31

XEventsQueued 6: 31

XExtentsOfFontSet 6: 31

XFetchBuffer 6: 31

XFetchBytes 6: 31

XFetchName 6: 31

XFillArc 6: 31XFillArcs 6: 31

XFillPolygon 6: 31

XFillRectangle 6: 31

XFillRectangles 6: 31

XFilterEvent 6: 31

XFindContext 6: 31

XFindOnExtensionList 6: 31

XFlush 6: 31

XFlushGC 6: 31

XFontsOfFontSet 6: 31

XForceScreenSaver 6: 31

IN-28 Index



Page: 258



XFree 6: 31

XFreeColormap 6: 31

XFreeColors 6: 31

XFreeCursor 6: 31

XFreeExtensionList 6: 31

XFreeFont 6: 31

XFreeFontInfo 6: 31

XFreeFontNames 6: 31

XFreeFontPath 6: 31

XFreeFontSet 6: 31

XFreeGC 6: 31

XFreeModifiermap 6: 31

XFreePixmap 6: 31

XFreeStringList 6: 31

_xftw 6: 9–10

XGContextFromGC 6: 31

XGeometry 6: 31

XGetAtomName 6: 31

XGetClassHint 6: 31

XGetCommand 6: 31

XGetDefault 6: 31

XGetErrorDatabaseText 6: 31

XGetErrorText 6: 31

XGetFontPath 6: 31

XGetFontProperty 6: 31

XGetGCValues 6: 31

XGetGeometry 6: 31

XGetIconName 6: 31

XGetIconSizes 6: 31

XGetICValues 6: 31

XGetImage 6: 31XGetIMValues 6: 31

XGetInputFocus 6: 31

XGetKeyboardControl 6: 31

XGetKeyboardMapping 6: 31

XGetModifierMapping 6: 31

XGetMotionEvents 6: 31

XGetNormalHints 6: 31

XGetPixel 6: 31

XGetPointerControl 6: 31

XGetPointerMapping 6: 31

XGetRGBColormaps 6: 31

XGetScreenSaver 6: 31

XGetSelectionOwner 6: 31

XGetSizeHints 6: 31

XGetStandardColormap 6: 31

XGetSubImage 6: 31

XGetTextProperty 6: 31

XGetTransientForHint 6: 31

XGetVisualInfo 6: 31

XGetWindowAttributes 6: 31

XGetWindowProperty 6: 31

XGetWMClientMachine 6: 31

XGetWMColormapWindows 6: 31

XGetWMHints 6: 31

XGetWMIconName 6: 31

XGetWMName 6: 31

XGetWMNormalHints 6: 31

XGetWMProtocols 6: 31

XGetWMSizeHints 6: 31

XGrabButton 6: 31

XGrabKey 6: 31

XGrabKeyboard 6: 31

XGrabPointer 6: 31

XGrabServer 6: 31

XHeightMMOfScreen 6: 31

XHeightOfScreen 6: 31

XIconifyWindow 6: 31

XIfEvent 6: 31

XImageByteOrder 6: 31

XIMOfIC 6: 31

XInitExtension 6: 31

XInsertModifiermapEntry 6: 31XInstallColormap 6: 31

XInternAtom 6: 31

XIntersectRegion 6: 31

XKeycodeToKeysym 6: 31

XKeysymToKeycode 6: 31

XKeysymToString 6: 31

XKillClient 6: 31

XLastKnownRequestProcessed 6: 31

XListDepths 6: 31

XListExtensions 6: 31

XListFonts 6: 31

Index IN-29



Page: 259



XListFontsWithInfo 6: 31

XListHosts 6: 31

XListInstalledColormaps 6: 31

XListPixmapFormats 6: 31

XListProperties 6: 31

XLoadFont 6: 31

XLoadQueryFont 6: 31

XLocaleOfFontSet 6: 31

XLocaleOfIM 6: 31

XLookupColor 6: 31

XLookupKeysym 6: 31

XLookupString 6: 31

XLowerWindow 6: 31

XmActivateProtocol 6: 43

XmAddProtocolCallback 6: 43

XmAddProtocols 6: 43

XmAddTabGroup 6: 43

XMapRaised 6: 31

XMapSubwindows 6: 31

XMapWindow 6: 31

xmArrowButtonClassRec 6: 45

xmArrowButtonGadgetClass 6: 45

xmArrowButtonGadgetClassRec

6: 45

xmArrowButtonWidgetClass 6: 45

XMaskEvent 6: 31

XMatchVisualInfo 6: 31

XMaxCmapsOfScreen 6: 31

XMaxRequestSize 6: 31

XmbDrawImageString 6: 31

XmbDrawString 6: 31XmbDrawText 6: 31

XmbLookupString 6: 31

XmbResetIC 6: 31

XmbSetWMProperties 6: 31

XmbTextEscapement 6: 31

XmbTextExtents 6: 31

XmbTextListToTextProperty 6: 31

XmbTextPerCharExtents 6: 31

XmbTextPropertyToTextList 6: 31

xmBulletinBoardClassRec 6: 45

xmBulletinBoardWidgetClass 6: 45

xmCascadeButtonClassRec 6: 45

xmCascadeButtonGadgetClass 6: 45

xmCascadeButtonGadgetClassRec

6: 45

XmCascadeButtonGadgetHighlight

6: 43

xmCascadeBut-

tonGCacheObjClassRec 6: 45

XmCascadeButtonHighlight 6: 43

xmCascadeButtonWidgetClass 6: 45

XmChangeColor 6: 43

XmClipboardCancelCopy 6: 43

XmClipboardCopy 6: 43

XmClipboardCopyByName 6: 43

XmClipboardEndCopy 6: 43

XmClipboardEndRetrieve 6: 43

XmClipboardInquireCount 6: 43

XmClipboardInquireFormat 6: 43

XmClipboardInquireLength 6: 43

XmClipboardInquirePendingItems

6: 43

XmClipboardLock 6: 43

XmClipboardRegisterFormat 6: 43

XmClipboardRetrieve 6: 43

XmClipboardStartCopy 6: 43

XmClipboardStartRetrieve 6: 43

XmClipboardUndoCopy 6: 43

XmClipboardUnlock 6: 43

XmClipboardWithdrawFormat 6: 43

XmCommandAppendValue 6: 43

xmCommandClassRec 6: 45XmCommandError 6: 43

XmCommandGetChild 6: 43

XmCommandSetValue 6: 43

xmCommandWidgetClass 6: 45

XmConvertUnits 6: 43

XmCreateArrowButton 6: 43

XmCreateArrowButtonGadget 6: 43

XmCreateBulletinBoard 6: 43

XmCreateBulletinBoardDialog 6: 43

XmCreateCascadeButton 6: 43

XmCreateCascadeButtonGadget 6: 43

IN-30 Index



Page: 260



XmCreateCommand 6: 43

XmCreateDialogShell 6: 43

XmCreateDragIcon 6: 43

XmCreateDrawingArea 6: 43

XmCreateDrawnButton 6: 43

XmCreateErrorDialog 6: 43

XmCreateFileSelectionBox 6: 43

XmCreateFileSelectionDialog 6: 43

XmCreateForm 6: 43

XmCreateFormDialog 6: 43

XmCreateFrame 6: 43

XmCreateInformationDialog 6: 43

XmCreateLabel 6: 43

XmCreateLabelGadget 6: 43

XmCreateList 6: 43

XmCreateMainWindow 6: 43

XmCreateMenuBar 6: 43

XmCreateMenuShell 6: 43

XmCreateMessageBox 6: 43

XmCreateMessageDialog 6: 43

XmCreateOptionMenu 6: 43

XmCreatePanedWindow 6: 43

XmCreatePopupMenu 6: 43

XmCreatePromptDialog 6: 43

XmCreatePulldownMenu 6: 43

XmCreatePushButton 6: 43

XmCreatePushButtonGadget 6: 43

XmCreateQuestionDialog 6: 43

XmCreateRadioBox 6: 43

XmCreateRowColumn 6: 43

XmCreateScale 6: 43XmCreateScrollBar 6: 43

XmCreateScrolledList 6: 43

XmCreateScrolledText 6: 43

XmCreateScrolledWindow 6: 43

XmCreateSelectionBox 6: 43

XmCreateSelectionDialog 6: 43

XmCreateSeparator 6: 43

XmCreateSeparatorGadget 6: 43

XmCreateSimpleCheckBox 6: 43

XmCreateSimpleMenuBar 6: 43

XmCreateSimpleOptionMenu 6: 43

XmCreateSimplePopupMenu 6: 43

XmCreateSimplePulldownMenu 6: 43

XmCreateSimpleRadioBox 6: 43

XmCreateTemplateDialog 6: 43

XmCreateText 6: 43

XmCreateTextField 6: 43

XmCreateToggleButton 6: 43

XmCreateToggleButtonGadget 6: 43

XmCreateWarningDialog 6: 43

XmCreateWorkArea 6: 43

XmCreateWorkingDialog 6: 43

XmCvtCTToXmString 6: 43

XmCvtStringToUnitType 6: 43

XmCvtXmStringToCT 6: 43

XmDeactivateProtocol 6: 43

xmDesktopClass 6: 45

xmDesktopClassRec 6: 45

XmDestroyPixmap 6: 43

xmDialogShellClassRec 6: 45

xmDialogShellExtClassRec 6: 45

xmDialogShellExtObjectClass

6: 45

xmDialogShellWidgetClass 6: 45

xmDisplayClass 6: 45

xmDisplayClassRec 6: 45

XmDragCancel 6: 43

xmDragContextClass 6: 45

xmDragContextClassRec 6: 45

xmDragIconClassRec 6: 45

xmDragIconObjectClass 6: 45

xmDragOverShellClassRec 6: 45xmDragOverShellWidgetClass 6: 45

XmDragStart 6: 43

xmDrawingAreaClassRec 6: 45

xmDrawingAreaWidgetClass 6: 45

xmDrawnButtonClassRec 6: 45

xmDrawnButtonWidgetClass 6: 45

XmDropSiteConfigureStackingOrder

6: 43

XmDropSiteEndUpdate 6: 43

xmDropSiteManagerClassRec 6: 45

xmDropSiteManagerObjectClass

6: 45

Index IN-31



Page: 261



XmDropSiteQueryStackingOrder

6: 43

XmDropSiteRegister 6: 43

XmDropSiteRetrieve 6: 43

XmDropSiteStartUpdate 6: 43

XmDropSiteUnregister 6: 43

XmDropSiteUpdate 6: 43

XmDropTransferAdd 6: 43

xmDropTransferClassRec 6: 45

xmDropTransferObjectClass 6: 45

XmDropTransferStart 6: 43

xmExtClassRec 6: 45

xmExtObjectClass 6: 45

xmFileSelectionBoxClassRec 6: 45

XmFileSelectionBoxGetChild 6: 43

xmFileSelectionBoxWidgetClass

6: 45

XmFileSelectionDoSearch 6: 43

XmFontListAdd 6: 43

XmFontListAppendEntry 6: 43

XmFontListCopy 6: 43

XmFontListCreate 6: 43

XmFontListEntryCreate 6: 43

XmFontListEntryFree 6: 43

XmFontListEntryGetFont 6: 43

XmFontListEntryGetTag 6: 43

XmFontListEntryLoad 6: 43

XmFontListFree 6: 43

XmFontListFreeFontContext 6: 43

XmFontListGetNextFont 6: 43

XmFontListInitFontContext 6: 43XmFontListNextEntry 6: 43

XmFontListRemoveEntry 6: 43

xmFormClassRec 6: 45

xmFormWidgetClass 6: 45

xmFrameClassRec 6: 45

xmFrameWidgetClass 6: 45

xmGadgetClass 6: 45

xmGadgetClassRec 6: 45

XmGetAtomName 6: 43

XmGetColorCalculation 6: 43

XmGetColors 6: 43

XmGetDestination 6: 43

XmGetDragContext 6: 43

XmGetFocusWidget 6: 43

XmGetMenuCursor 6: 43

XmGetPixmap 6: 43

XmGetPixmapByDepth 6: 43

XmGetPostedFromWidget 6: 43

XmGetSecondaryResourceData 6: 43

XmGetTabGroup 6: 43

XmGetTearOffControl 6: 43

XmGetVisibility 6: 43

XmGetXmDisplay 6: 43

XmGetXmScreen 6: 43

XMinCmapsOfScreen 6: 31

XmInstallImage 6: 43

XmInternAtom 6: 43

XmIsMotifWMRunning 6: 43

XmIsTraversable 6: 43

xmLabelClassRec 6: 45

xmLabelGadgetClass 6: 45

xmLabelGadgetClassRec 6: 45

xmLabelGCacheObjClassRec 6: 45

xmLabelWidgetClass 6: 45

XmListAddItem 6: 43

XmListAddItems 6: 43

XmListAddItemsUnselected 6: 43

XmListAddItemUnselected 6: 43

xmListClassRec 6: 45

XmListDeleteAllItems 6: 43

XmListDeleteItem 6: 43

XmListDeleteItems 6: 43XmListDeleteItemsPos 6: 43

XmListDeletePos 6: 43

XmListDeletePositions 6: 43

XmListDeselectAllItems 6: 43

XmListDeselectItem 6: 43

XmListDeselectPos 6: 43

XmListGetKbdItemPos 6: 43

XmListGetMatchPos 6: 43

XmListGetSelectedPos 6: 43

XmListItemExists 6: 43

XmListItemPos 6: 43

IN-32 Index



Page: 262



XmListPosSelected 6: 43

XmListPosToBounds 6: 43

XmListReplaceItems 6: 43

XmListReplaceItemsPos 6: 43

XmListReplaceItemsPosUnselected

6: 43

XmListReplaceItemsUnselected 6: 43

XmListReplacePositions 6: 43

XmListSelectItem 6: 43

XmListSelectPos 6: 43

XmListSetAddMode 6: 43

XmListSetBottomItem 6: 43

XmListSetBottomPos 6: 43

XmListSetHorizPos 6: 43

XmListSetItem 6: 43

XmListSetKbdItemPos 6: 43

XmListSetPos 6: 43

XmListUpdateSelectedList 6: 43

xmListWidgetClass 6: 45

XmListYToPos 6: 43

xmMainWindowClassRec 6: 45

XmMainWindowSep1 6: 43



XmMainWindowSetAreas 6: 43

xmMainWindowWidgetClass 6: 45

xmManagerClassRec 6: 45

xmManagerWidgetClass 6: 45

XmMapSegmentEncoding 6: 43

XmMenuPosition 6: 43

xmMenuShellClassRec 6: 45xmMenuShellWidgetClass 6: 45

xmMessageBoxClassRec 6: 45

XmMessageBoxGetChild 6: 43

xmMessageBoxWidgetClass 6: 45

XmOptionButtonGadget 6: 43

XmOptionLabelGadget 6: 43

XMoveResizeWindow 6: 31

XMoveWindow 6: 31

xmPanedWindowClassRec 6: 45

xmPanedWindowWidgetClass 6: 45

xmPrimitiveClassRec 6: 45

xmPrimitiveWidgetClass 6: 45

XmProcessTraversal 6: 43

xmProtocolClassRec 6: 45

xmProtocolObjectClass 6: 45

xmPushButtonClassRec 6: 45

xmPushButtonGadgetClass 6: 45

xmPushButtonGadgetClassRec 6: 45

xmPushButtonGCacheObjClassRec

6: 45

xmPushButtonWidgetClass 6: 45

XmQmotif 6: 45

XmRegisterSegmentEncoding 6: 43

XmRemoveProtocolCallback 6: 43

XmRemoveProtocols 6: 43

XmRemoveTabGroup 6: 43

XmRepTypeAddReverse 6: 43

XmRepTypeGetId 6: 43

XmRepTypeGetNameList 6: 43

XmRepTypeGetRecord 6: 43

XmRepTypeGetRegistered 6: 43

XmRepTypeInstallTearOffModelCon-

verter 6: 43

XmRepTypeRegister 6: 43

XmRepTypeValidValue 6: 43

XmResolveAllPartOffsets 6: 43

XmResolvePartOffsets 6: 43

xmRowColumnClassRec 6: 45

xmRowColumnWidgetClass 6: 45

xmSashClassRec 6: 45

xmSashWidgetClass 6: 45

xmScaleClassRec 6: 45XmScaleGetValue 6: 43

XmScaleSetValue 6: 43

xmScaleWidgetClass 6: 45

xmScreenClass 6: 45

xmScreenClassRec 6: 45

xmScrollBarClassRec 6: 45

XmScrollBarGetValues 6: 43

XmScrollBarSetValues 6: 43

xmScrollBarWidgetClass 6: 45

xmScrolledWindowClassRec 6: 45

XmScrolledWindowSetAreas 6: 43

Index IN-33



Page: 263



xmScrolledWindowWidgetClass

6: 45

XmScrollVisible 6: 43

xmSelectionBoxClassRec 6: 45

XmSelectionBoxGetChild 6: 43

xmSelectionBoxWidgetClass 6: 45

xmSeparatorClassRec 6: 45

xmSeparatorGadgetClass 6: 45

xmSeparatorGadgetClassRec 6: 45

xmSeparatorGCacheObjClassRec

6: 45

xmSeparatorWidgetClass 6: 45

XmSetColorCalculation 6: 43

XmSetFontUnit 6: 43

XmSetFontUnits 6: 43

XmSetMenuCursor 6: 43

XmSetProtocolHooks 6: 43

xmShellExtClassRec 6: 45

xmShellExtObjectClass 6: 45

XmStringBaseline 6: 43

XmStringByteCompare 6: 43

XmStringCompare 6: 43

XmStringConcat 6: 43

XmStringCopy 6: 43

XmStringCreate 6: 43

XmStringCreateLocalized 6: 43

XmStringCreateLtoR 6: 43

XmStringCreateSimple 6: 43

XmStringDirectionCreate 6: 43

XmStringDraw 6: 43

XmStringDrawImage 6: 43XmStringDrawUnderline 6: 43

XmStringEmpty 6: 43

XmStringExtent 6: 43

XmStringFree 6: 43

XmStringFreeContext 6: 43

XmStringGetLtoR 6: 43

XmStringGetNextComponent 6: 43

XmStringGetNextSegment 6: 43

XmStringHasSubstring 6: 43

XmStringHeight 6: 43

XmStringInitContext 6: 43

XmStringLength 6: 43

XmStringLineCount 6: 43

XmStringNConcat 6: 43

XmStringNCopy 6: 43

XmStringPeekNextComponent 6: 43

XmStringSegmentCreate 6: 43

XmStringSeparatorCreate 6: 43

XmStringWidth 6: 43

XmTargetsAreCompatible 6: 43

xmTearOffButtonClassRec 6: 45

xmTearOffButtonWidgetClass 6: 45

xmTextClassRec 6: 45

XmTextClearSelection 6: 43

XmTextCopy 6: 43

XmTextCut 6: 43

XmTextDisableRedisplay 6: 43

XmTextEnableRedisplay 6: 43

xmTextFieldClassRec 6: 45

XmTextFieldClearSelection 6: 43

XmTextFieldCopy 6: 43

XmTextFieldCut 6: 43

XmTextFieldGetBaseline 6: 43

XmTextFieldGetEditable 6: 43

XmTextFieldGetInsertionPosition

6: 43

XmTextFieldGetLastPosition 6: 43

XmTextFieldGetMaxLength 6: 43

XmTextFieldGetSelection 6: 43

XmTextFieldGetSelectionPosition

6: 43

XmTextFieldGetSelectionWcs 6: 43XmTextFieldGetString 6: 43

XmTextFieldGetStringWcs 6: 43

XmTextFieldGetSubstring 6: 43

XmTextFieldGetSubstringWcs 6: 43

XmTextFieldInsert 6: 43

XmTextFieldInsertWcs 6: 43

XmTextFieldPaste 6: 43

XmTextFieldPosToXY 6: 43

XmTextFieldRemove 6: 43

XmTextFieldReplace 6: 43

XmTextFieldReplaceWcs 6: 43

IN-34 Index



Page: 264



XmTextFieldSetAddMode 6: 43

XmTextFieldSetEditable 6: 43

XmTextFieldSetHighlight 6: 43

XmTextFieldSetInsertionPosition

6: 43

XmTextFieldSetMaxLength 6: 43

XmTextFieldSetSelection 6: 43

XmTextFieldSetString 6: 43

XmTextFieldSetStringWcs 6: 43

XmTextFieldShowPosition 6: 43

xmTextFieldWidgetClass 6: 45

XmTextFieldXYToPos 6: 43

XmTextFindString 6: 43

XmTextFindStringWcs 6: 43

XmTextGetBaseLine 6: 43

XmTextGetBaseline 6: 43

XmTextGetEditable 6: 43

XmTextGetInsertionPosition 6: 43

XmTextGetLastPosition 6: 43

XmTextGetMaxLength 6: 43

XmTextGetSelection 6: 43

XmTextGetSelectionPosition 6: 43

XmTextGetSelectionWcs 6: 43

XmTextGetSource 6: 43

XmTextGetString 6: 43

XmTextGetStringWcs 6: 43

XmTextGetSubstring 6: 43

XmTextGetSubstringWcs 6: 43

XmTextGetTopCharacter 6: 43

XmTextInsert 6: 43

XmTextInsertWcs 6: 43XmTextPaste 6: 43

XmTextPosToXY 6: 43

XmTextRemove 6: 43

XmTextReplace 6: 43

XmTextReplaceWcs 6: 43

XmTextScroll 6: 43

XmTextSetAddMode 6: 43

XmTextSetEditable 6: 43

XmTextSetHighlight 6: 43

XmTextSetInsertionPosition 6: 43

XmTextSetMaxLength 6: 43

XmTextSetSelection 6: 43

XmTextSetSource 6: 43

XmTextSetString 6: 43

XmTextSetStringWcs 6: 43

XmTextSetTopCharacter 6: 43

XmTextShowPosition 6: 43

xmTextWidgetClass 6: 45

XmTextXYToPos 6: 43

xmToggleButtonClassRec 6: 45

xmToggleButtonGadgetClass 6: 45

xmToggleButtonGadgetClassRec

6: 45

XmToggleButtonGadgetGetState

6: 43

XmToggleButtonGadgetSetState 6: 43

xmToggleBut-

tonGCacheObjClassRec 6: 45

XmToggleButtonGetState 6: 43

XmToggleButtonSetState 6: 43

xmToggleButtonWidgetClass 6: 45

XmTrackingEvent 6: 43

XmTrackingLocate 6: 43

XmTranslateKey 6: 43

XmUninstallImage 6: 43

XmUpdateDisplay 6: 43

xmUseVersion 6: 45

XmVaCreateSimpleCheckBox 6: 43

XmVaCreateSimpleMenuBar 6: 43

XmVaCreateSimpleOptionMenu 6: 43

XmVaCreateSimplePopupMenu 6: 43

XmVaCreateSimplePulldownMenu6: 43

XmVaCreateSimpleRadioBox 6: 43

xmVendorShellExtClassRec 6: 45

xmVendorShellExtObjectClass

6: 45

XmWidgetGetBaselines 6: 43

XmWidgetGetDisplayRect 6: 43

xmWorldClass 6: 45

xmWorldClassRec 6: 45

XNewModifiermap 6: 31

XNextEvent 6: 31

Index IN-35



Page: 265



XNextRequest 6: 31

XNoOp 6: 31

XOffsetRegion 6: 31

X/ Open Comm on App lication

Environm ent Specification, Issue

4.2 1: 1

X/ Open Comm on App lication

Environm ent Specification (CAE),

Issue 4.2 1: 2

X/ Open Portability Guide 7: 22

XOpenDisplay 6: 31

XOpenIM 6: 31

XParseColor 6: 31

XParseGeometry 6: 31

XPeekEvent 6: 31

XPeekIfEvent 6: 31

XPending 6: 31

Xpermalloc 6: 31

XPG3 7: 22

_ _xpg4 6: 12

XPlanesOfScreen 6: 31

XPointInRegion 6: 31

XPolygonRegion 6: 31

XProtocolRevision 6: 31

XProtocolVersion 6: 31

xprt _register 6: 20

xprt _unregister 6: 20

XPutBackEvent 6: 31

XPutImage 6: 31

XPutPixel 6: 31

XQLength 6: 31XQueryBestCursor 6: 31

XQueryBestSize 6: 31

XQueryBestStipple 6: 31

XQueryBestTile 6: 31

XQueryColor 6: 31

XQueryColors 6: 31

XQueryExtension 6: 31

XQueryFont 6: 31

XQueryKeymap 6: 31

XQueryPointer 6: 31

XQueryTextExtents 6: 31

XQueryTextExtents16 6: 31

XQueryTree 6: 31

XRaiseWindow 6: 31

XReadBitmapFile 6: 31

XRebindKeysym 6: 31

XRecolorCursor 6: 31

XReconfigureWMWindow 6: 31

XRectInRegion 6: 31

XRefreshKeyboardMapping 6: 31

XRemoveFromSaveSet 6: 31

XRemoveHost 6: 31

XRemoveHosts 6: 31

XReparentWindow 6: 31

XResetScreenSaver 6: 31

XResizeWindow 6: 31

XResourceManagerString 6: 31

XRestackWindows 6: 31

XrmCombineDatabase 6: 31

XrmCombineFileDatabase 6: 31

XrmDestroyDatabase 6: 31

XrmEnumerateDatabase 6: 31

XrmGetDatabase 6: 31

XrmGetFileDatabase 6: 31

XrmGetResource 6: 31

XrmGetStringDatabase 6: 31

XrmInitialize 6: 31

XrmLocaleOfDatabase 6: 31

XrmMergeDatabases 6: 31

XrmParseCommand 6: 31

XrmPermStringToQuark 6: 31

XrmPutFileDatabase 6: 31XrmPutLineResource 6: 31

XrmPutResource 6: 31

XrmPutStringResource 6: 31

XrmQGetResource 6: 31

XrmQGetSearchList 6: 31

XrmQGetSearchResource 6: 31

XrmQPutResource 6: 31

XrmQPutStringResource 6: 31

XrmQuarkToString 6: 31

XrmSetDatabase 6: 31

XrmStringToBindingQuarkList 6: 31

IN-36 Index



Page: 266



XrmStringToQuark 6: 31

XrmStringToQuarkList 6: 31

XrmUniqueQuark 6: 31

XRootWindow 6: 31

XRootWindowOfScreen 6: 31

XRotateBuffers 6: 31

XRotateWindowProperties 6: 31

XSaveContext 6: 31

XScreenCount 6: 31

XScreenNumberOfScreen 6: 31

XScreenOfDisplay 6: 31

XScreenResourceString 6: 31

XSelectInput 6: 31

XSendEvent 6: 31

XServerVendor 6: 31

XSetAccessControl 6: 31

XSetAfterFunction 6: 31

XSetArcMode 6: 31

XSetBackground 6: 31

XSetClassHint 6: 31

XSetClipMask 6: 31

XSetClipOrigin 6: 31

XSetClipRectangles 6: 31

XSetCloseDownMode 6: 31

XSetCommand 6: 31

XSetDashes 6: 31

XSetErrorHandler 6: 31

XSetFillRule 6: 31

XSetFillStyle 6: 31

XSetFont 6: 31

XSetFontPath 6: 31XSetForeground 6: 31

XSetFunction 6: 31

XSetGraphicsExposures 6: 31

XSetICFocus 6: 31

XSetIconName 6: 31

XSetIconSizes 6: 31

XSetICValues 6: 31

XSetInputFocus 6: 31

XSetIOErrorHandler 6: 31

XSetLineAttributes 6: 31

XSetLocaleModifiers 6: 31

XSetModifierMapping 6: 31

XSetNormalHints 6: 31

XSetPlaneMask 6: 31

XSetPointerMapping 6: 31

XSetRegion 6: 31

XSetRGBColormaps 6: 31

XSetScreenSaver 6: 31

XSetSelectionOwner 6: 31

XSetSizeHints 6: 31

XSetStandardColormap 6: 31

XSetStandardProperties 6: 31

XSetState 6: 31

XSetStipple 6: 31

XSetSubwindowMode 6: 31

XSetTextProperty 6: 31

XSetTile 6: 31

XSetTransientForHint 6: 31

XSetTSOrigin 6: 31

XSetWindowBackground 6: 31

XSetWindowBackgroundPixmap

6: 31

XSetWindowBorder 6: 31

XSetWindowBorderPixmap 6: 31

XSetWindowBorderWidth 6: 31

XSetWindowColormap 6: 31

XSetWMClientMachine 6: 31

XSetWMColormapWindows 6: 31

XSetWMHints 6: 31

XSetWMIconName 6: 31

XSetWMName 6: 31

XSetWMNormalHints 6: 31XSetWMProperties 6: 31

XSetWMProtocols 6: 31

XSetWMSizeHints 6: 31

XShapeCombineMask 6: 33

XShapeCombineRectangles 6: 33

XShapeCombineRegion 6: 33

XShapeCombineShape 6: 33

XShapeGetRectangles 6: 33

XShapeInputSelected 6: 33

XShapeOffsetShape 6: 33

XShapeQueryExtension 6: 33

Index IN-37



Page: 267



XShapeQueryExtents 6: 33

XShapeQueryVersion 6: 33

XShapeSelectInput 6: 33

XShrinkRegion 6: 31

XStoreBuffer 6: 31

XStoreBytes 6: 31

XStoreColor 6: 31

XStoreColors 6: 31

XStoreName 6: 31

XStoreNamedColor 6: 31

XStringListToTextProperty 6: 31

XStringToKeysym 6: 31

XSubImage 6: 31

XSubtractRegion 6: 31

XSupportsLocale 6: 31

XSync 6: 31

XSynchronize 6: 31

XtAddCallback 6: 36

XtAddCallbacks 6: 36

XtAddEventHandler 6: 36

XtAddExposureToRegion 6: 36

XtAddGrab 6: 36

XtAddRawEventHandler 6: 36

XtAllocateGC 6: 36

XtAppAddActionHook 6: 36

XtAppAddActions 6: 36

XtAppAddInput 6: 36

XtAppAddTimeOut 6: 36

XtAppAddWorkProc 6: 36

XtAppCreateShell 6: 36

XtAppError 6: 36XtAppErrorMsg 6: 36

XtAppGetErrorDatabase 6: 36

XtAppGetErrorDatabaseText 6: 36

XtAppGetSelectionTimeout 6: 36

XtAppInitialize 6: 36

XtAppMainLoop 6: 36

XtAppNextEvent 6: 36

XtAppPeekEvent 6: 36

XtAppPending 6: 36

XtAppProcessEvent 6: 36

XtAppReleaseCacheRefs 6: 36

XtAppSetErrorHandler 6: 36

XtAppSetErrorMsgHandler 6: 36

XtAppSetFallbackResources 6: 36

XtAppSetSelectionTimeout 6: 36

XtAppSetTypeConverter 6: 36

XtAppSetWarningHandler 6: 36

XtAppSetWarningMsgHandler 6: 36

XtAppWarning 6: 36

XtAppWarningMsg 6: 36

XtAugmentTranslations 6: 36

XtBuildEventMask 6: 36

XtCallAcceptFocus 6: 36

XtCallActionProc 6: 36

XtCallbackExclusive 6: 36

XtCallbackNone 6: 36

XtCallbackNonexclusive 6: 36

XtCallbackPopdown 6: 36

XtCallbackReleaseCacheRef 6: 36

XtCallbackReleaseCacheRefList 6: 36

XtCallCallbackList 6: 36

XtCallCallbacks 6: 36

XtCallConverter 6: 36

XtCalloc 6: 36

XtClass 6: 36

XtCloseDisplay 6: 36

XtConfigureWidget 6: 36

XtConvertAndStore 6: 36

XtConvertCase 6: 36

XtCreateApplicationContext 6: 36

XtCreateManagedWidget 6: 36

XtCreatePopupShell 6: 36XtCreateWidget 6: 36

XtCreateWindow 6: 36

XtCvtColorToPixel 6: 36

XtCvtIntToBool 6: 36

XtCvtIntToBoolean 6: 36

XtCvtIntToColor 6: 36

XtCvtIntToFloat 6: 36

XtCvtIntToFont 6: 36

XtCvtIntToPixel 6: 36

XtCvtIntToPixmap 6: 36

XtCvtIntToShort 6: 36

IN-38 Index



Page: 268



XtCvtIntToUnsignedChar 6: 36

XtCvtStringToAcceleratorTable 6: 36

XtCvtStringToAtom 6: 36

XtCvtStringToBool 6: 36

XtCvtStringToBoolean 6: 36

XtCvtStringToCursor 6: 36

XtCvtStringToDimension 6: 36

XtCvtStringToDisplay 6: 36

XtCvtStringToFile 6: 36

XtCvtStringToFloat 6: 36

XtCvtStringToFont 6: 36

XtCvtStringToFontSet 6: 36

XtCvtStringToFontStruct 6: 36

XtCvtStringToInitialState 6: 36

XtCvtStringToInt 6: 36

XtCvtStringToPixel 6: 36

XtCvtStringToShort 6: 36

XtCvtStringToTranslationTable 6: 36

XtCvtStringToUnsignedChar 6: 36

XtCvtStringToVisual 6: 36

XtDatabase 6: 36

XtDestroyApplicationContext 6: 36

XtDestroyWidget 6: 36

XtDisownSelection 6: 36

XtDispatchEvent 6: 36

XtDisplay 6: 36

XtDisplayInitialize 6: 36

XtDisplayOfObject 6: 36

XtDisplayStringConversionWarning

6: 36

XtDisplayToApplicationContext 6: 36XTextExtents 6: 31

XTextExtents16 6: 31

XTextPropertyToStringList 6: 31

XTextWidth 6: 31

XTextWidth16 6: 31

XtFindFile 6: 36

XtFree 6: 36

XtGetActionKeysym 6: 36

XtGetActionList 6: 36

XtGetApplicationNameAndClass

6: 36

XtGetApplicationResources 6: 36

XtGetConstraintResourceList 6: 36

XtGetGC 6: 36

XtGetKeysymTable 6: 36

XtGetMultiClickTime 6: 36

XtGetResourceList 6: 36

XtGetSelectionRequest 6: 36

XtGetSelectionValue 6: 36

XtGetSelectionValueIncremental 6: 36

XtGetSelectionValues 6: 36

XtGetSelectionValuesIncremental

6: 36

XtGetSubresources 6: 36

XtGetSubvalues 6: 36

XtGetValues 6: 36

XtGrabButton 6: 36

XtGrabKey 6: 36

XtGrabKeyboard 6: 36

XtGrapPointer 6: 36

XtHasCallbacks 6: 36

XTI 12: 4

_xti _accept 6: 19

_xti _alloc 6: 19

_xti _bind 6: 19

_xti _close 6: 19

_xti _connect 6: 19

_xti _error 6: 19

_xti _free 6: 19

_xti _getinfo 6: 19

_xti _getprotaddr 6: 19

_xti _getstate 6: 19 _xti _listen 6: 19

_xti _look 6: 19

XtInitializeWidgetClass 6: 36

XtInsertEventHandler 6: 36

XtInsertRawEventHandler 6: 36

XtInstallAccelerators 6: 36

XtInstallAllAccelerators 6: 36

_xti _open 6: 19

_xti _rcv 6: 19

_xti _rcvconnect 6: 19

_xti _rcvdis 6: 19

Index IN-39



Page: 269



XtSuperclass 6: 36

XtToolkitInitialize 6: 36

XtTranslateCoords 6: 36

XUnsetICFocus 6: 31

XVaCreateNestedList 6: 31

XVendorRelease 6: 31

Generic UNIX ABI-41

Documents

Transcript of Generic UNIX ABI-41