ISO/IEC 14395:1996
(Main)Information technology — Test methods for measuring conformance to directory services C language interfaces — Binding for Application Program Interface (API)
Information technology — Test methods for measuring conformance to directory services C language interfaces — Binding for Application Program Interface (API)
Defines requirements for test methods for measuring conformance to ISO/IEC 14394.
Technologies de l'information — Méthodes d'essai pour mesurer la conformité aux interfaces de langage C des services de l'annuaire — Liant pour interface de programme d'application (API)
General Information
Standards Content (Sample)
INTERNATIONAL lSO/IEC
STANDARD 14395
First edition
1996-06-01
Information technology - Test methods
for measuring conformance to directory
services C language interfaces - Binding
for Application Program Interface (API)
Technologies de /‘information - Mkthodes d ’essai pour mesurer la
conformit aux interfaces de langage C des services de I’annuaire -
Lian t pour interface de programme d ‘applica tion (A PI)
Reference numbe-r
SO/I EC 14395: 1996(E)
---------------------- Page: 1 ----------------------
ISOAEC 14395:1996(E)
Contents
PAGE
0 0 0 1
Section 1: General . . . . . . . . . . .
0 0 0 1
1.1 Scope . . . . . . . . . . . . .
0 0 0 2
1.2 Normative References . . . . l . . .
0 0 0 3
1.3 Conformance . . . l l . . l . . l
5
0 0 0
Section 2: Terminology and General Requirements
0 5
0 0
2.1 Conventions . . l . . . . . . . l
11
0 0 0
2.2 Definitions . . . . . . . . . . .
23
0 0 0
Section 3: Test Assertions-General . . . . .
0 0 0 25
Section 4: Test Assertions-Terminology and General Reauirements *
0 0 0 0 0 0 0 0 0 25
4.1 Conventions . . . . . . . . . . .
0 0 0 0 0 0 0 0 0 26
4.2 Definitions . . . . . . . . . . .
0 0 0 0 0 0 0 27
0 0
Section 5: Test Assertions-The Generic Interface
0 0 0 0 0 0 27
0 0 0 0 0 0 0 0 0
5.1 Introduction . . . . .
0 0 0 27
0 0 0 0 0 0 0 0 0 0 0 0
5.2 Interface Functions . .
0 0 0 27
0 0 0 0 0 0 0 0 0 0 0 0
5.2.1 Overview
0 0 0 0 27
0 0 0 0 0 0 0 0 0 0 0
5.2.2 Common Da&&es
0 0 27
0 0 0 0 0 0 0 0 0 0 0
0 0
5.2.3 Abandon l . . l
28
0 0 0 0 0 0 0 0 0 0 0
0 0 0 0
5.2.4 Add Entry . . .
0 0 0 0 0 0 0 0 0 0 29
0 0 0 0 0
5.2.5 Bind . . . . .
0 0 0 0 0 0 29
0 0 0 0 0 0 0 0 0
5.2.6 Compare . . . .
0 0 0 0 0 0 0 0 30
0 0 0 0 0 0 0
5.2.7 Initialize . . . .
0 0 0 0 0 0 0 0 30
0 0 0 0 0 0 0 0 0
5.2.8 List
0 0 0 31
0 0 0 0 0 0 0 0 0 0 0
5.2.9 Modify&&’ . . 0
0 0 0 32
0 0 0 0 0 0 0 0 0 0 0
5.2.10 Modify RDN . . 0
0 0 0 32
0 0 0 0 0 0 0 0 0 0 0 0
5.2.11 Read . . . . .
0 33
0 0 0 0 0 0 0 0 0 0 0 0
5.2.12 Receive Result . . 0
0 0 0 34
0 0 0 0 0 0 0 0 0 0
0
5.2.13 Remove Entry . .
34
0 0 0 0 0 0 0 0 0 0 0
0 0 0
5.2.14 Search . . . .
0 0 0 0 0 0 0 0 0 35
0 0 0 0 0
5.2.15 Shutdown . . .
0 0 0 0 0 0 0 0 36
0 0 0 0 0 0
52.16 Unbind . . . .
0 0 0 0 0 0 36
0 0 0 0 0 0 0 0
5.2.17 Version . . l .
0 ISO/IEC 1996
All rights reserved. Unless otherwise specified, no part of this publication may be repro-
duced or utilized in any form or by any means, electronic or mechanical, including
photocopying and microfilm, without permission in writing from the publisher.
ISO/IEC Copyright Office l Case postale 56 l CH-1211 Geneve 20 l Switzerland
Printed in Switzerland
ii
---------------------- Page: 2 ----------------------
ISO/IEC 14395:1996(E)
0 ISO/IEC
5.3 Directory Service Package 37
...............
5.3.1 Object Identifiers . . . 37
..........
5.3.2 Enumeration Types and Constants 39
..........
5.3.3 OM Object Constants
41
..............
5.3.4 Integer Constants . .
41
5.3.5 Class Constraints . . . : . 42
l l l 42
5.4 The cxds.h> Header
0 0 0
..............
Section 6: Test Assertions-The X.500 Directory Service . .
0 0 0 0 0 43
6.1 Overview . . . . . . . . . . . . . . . .
0 0 0 0 0 43
6.2 Basic Directory Contents Package . . . . . .
0 0 0 0 0 43
6.2.1 Directory Object and Attribute Object IdentifiYers
0 0 0 0 0 43
6.2.2 OM Object and Attribute Type Identifiers 0
0 0 0 0 0 44
6.2.3 Directory Enumeration Types and Constants l .
0 0 0 0 0 45
6.2.4 Integer Constants . . . . . . . . . . . 0
0 0 0 0 46
6.3 Strong Authentication Package
0 0 0 0 0 47
6.3.1 Directory Object and Attribute ’object Identifi ’ers’
0 0 0 0 0 47
6.3.2 OM Object and Attribute Type Identifiers . .
0 0 0 0 0 47
6.3.3 Enumeration Types and Constants . . . . . 0 0 0 0 0 48
6.3.4 Integer Constants . . . . . . . . . . .
0 0 0 0 0 48
6.4 MHS Directory User Package . . . . . . . . . 0 0 0
0 0 49
6.4.1 Directory Object and Attribute Object Identifiers
0 0 0 0 0 49
6.4.2 OM Object and Attrib,ute Type Identifiers . .
0 0 0 0 0 49
6.4.3 Enumeration Types and Constants . . . . . 0
0 0 0 0 50
0 0 0 0 0
6.5 Header Files . . . . . . . . . . . . . . . 50
6.5.1 Thecxdsbdcp.h> Header . . . . . . . . 0 0 0 0
0 50
0 0
6.5.2 Thecxdssap.h> Header . . . . . . . . 0 0 0 50
6.5.3 The header . . . . . . . . 0 0 0 0 0 51
Section 7: Test Assertions-Definitions of Constants . . . . . . . . 53
7.1 Introduction 53
....................
7.2 Directory Service Package 53
...............
7.2.1 Object and Attribute Type Identifiers 53
.........
7.2.2 Enumeration Types and Constants 53
..........
7.2.3 OM Object Constants 56
..............
7.2.4 Integer Constants 57
................
7.3 Basic Directory Contents Package 57
.............
7.4 Strong Authentication Package 58
.............
7.5 MHS Directory User Package 58
..............
Annex A (informative) Bibliography . . . . . . . . . . . . . . 59
Alphabetic Topical Index . . . . . . . . . . . . . . . . . . 61
TABLES
Table 2-1 - C Naming Conventions . . . . . . . . . . . . . 8
Table 2-2 - Identifier Abbreviations . . . . . . . . . . . . . 10
. . .
111
---------------------- Page: 3 ----------------------
ISO/IEC 14395:1996(E) 0 ISO/IEC
Foreword
IS0 (the International Organization for Standardization) and IEC (the
International Electrotechnical Commission) form the specialized sys-
tem for worldwide standardization. National bodies that are members
of IS0 or IEC participate in the development of International Stan-
dards through technical committees established by the respective or-
ganization to deal with particular fields of technical activity. IS0 and
IEC technical committees collaborate in fields of mutual interest. Other
international organizations, governmental and non-governmental, in
liaison with IS0 and IEC, also take part in the work.
In the field of information technology, IS0 and IEC have established a
joint technical committee, ISO/IEC JTC 1. Draft International Stan-
dards adopted by the joint technical committee are circulated to
national bodies for voting. Publication as an International Standard
requires approval by at least 75 % of the national bodies casting a vote.
International Standard ISO/IEC 14395 was prepared by IEEE (as
IEEE Std 1328.2-1993) and was adopted, under a special “fast-track
procedure ”, by Joint Technical Committee ISO/IEC JTC 1, Information
technozogy, in parallel with its approval by national bodies of IS0 and
IEC.
Annex A of this International Standard is for information only.
iv
---------------------- Page: 4 ----------------------
0 ISO/IEC
ISOAEC 14395:1996(E)
1
Introduction
2 (This introduction is not a normative part of ISO/IEC 14395, Information technology-Test methods
3 for measuring conformance to directory services C language interfaces-Binding for Application Pro-
4 gram Interface (API), but is included for information only.)
The purpose of this International Standard is to define test methods for the C
language binding contained in ISOPZEC 14394 {8} for the language-independent
specification contained in ISOLIEC 14392 (6) of the application program interface
(API) to directory services.
A directory is a distributed collection of information, that programs can access in
9
order to make queries or updates. ISOLIEC 14392 (6) defines, in programming
10
11 language independent terms, an API to directory services. This API is known as
12 the Directory Services API (DS API). ISO/IEC 14394 (8) defines a C language
binding for the DS API.
13
14 The DS API is intended to be used to provide access to a range of directory services
15 that are instances of a common abstract model. That model is defined in the 1988
16 CCITT X.500 Series recommendations and ISO/IEC 9594: 1990. ISO/IEC 14392
17 (6) prescribes how the DS API is to be used to access the particular directory ser-
18 vice defined in ISO/IEC 9594: 1990 and indicates how it may be used to access
19 other directory services that conform to the same abstract model. Nothing in
20 ISO/IEC 14392 (6) or in this International Standard requires that the implementa-
21 tion of the interface or the Directory itself actually make use of the Directory
22 Access Protocol (DAP), the Directory System Protocol (DSP), or other parts of the
23 model, just so long as it provides the defined service.
24 The interface is designed for operational interactions with a directory, rather than
25 for management interactions such as knowledge management or schema manage-
26 ment. Also, security features are not generally visible in the interface in order to
27 permit flexibility in security policies. It is intended that an application program
28 should be able to use the interface to access a single directory service or to access
29 several directory services at the same time.
30 Related Standards
31 ISO/IEC 14392 (6) is intended to provide the basis for the definition of program-
32 ming language bindings to which implementations and applications can conform. A
33 specification for such a language binding, for the C programming language, is con-
34 tained in ISO/IEC 14394 (8). This International Standard applies to test methods
35 for measuring conformance to that programming language binding specification.
ISO/IEC 14393 (7} specifies test methods for the language-independent
36
37 specification contained in ISO/IEC 14392 (6). A set of test methods for the C bind-
ing to ISO/IEC 14392 (6) must satisfy the requirements of ISO/IEC 14393 {7}, as
38
39
well as conforming to this International Standard.
Introduction
---------------------- Page: 5 ----------------------
ISO/IEC 14395:1996(E)
0 ISO/IEC
40 The API defined in ISO/IEC 14392 (6) uses the mechanism for OS1 abstract data
41 Manipulation (OM) defined in ISO/IEC 14360 (B13). ISO/IEC 14362 (3) defines
42 the requirements that apply to test methods for measuring conformance to
ISO/IEC 14360 (B13). A C language binding to ISO/IEC 14360 (B13) is defined in
43
44 ISO/IEC 14364 (4). ISO/IEC 14366 (5) defines the requirements that apply to test
45 methods for measuring conformance to ISO/IEC 14364 (4).
46 IEEE Std 1003.3-1991 (9) defines the general requirements that shall apply to test
47 methods for measuring conformance to POSIX. A set of test methods used to meas-
ure conformance to ISO/IEC 14392 (6) must satisfy the requirements of IEEE
48
Standard 1003.3, as well as conforming to this International Standard.
49
50 Overview
51 For each section of ISO/IEC 14394 (8), this International Standard contains a
52 corresponding section containing test assertions, in accordance with IEEE Std
53 1003.3-1991 (9). A set of test methods conforms to this International Standard if it
54 tests all of the test assertions.
This International Standard is based on IEEE Std 1328.2-1993 (B15), which was
prepared by the Namespace and Directory Services Working Group (P1224.2, form-
erly P1003.17), sponsored by the Portable Applications Standards Committee of
the IEEE Computer Society.
vi
Introduction
---------------------- Page: 6 ----------------------
INTERNATIONAL STANDARD OISO/IEC ISO/IEC 14395:1996(E)
Information technology-Test methods for
measuring conformance to directory services
C language interfaces-Binding for
Application Program Interface (API)
Section 1: General
1.1 Scope
This International Standard defines requirements for test methods for measuring
conformance to ISO/IEC 14394 (8).
ISOAEC 14394 (8) contains a programming language binding specification for
ISO/IEC 14392 {6}, using the C programming language. ISO/IEC 14393 (7) con-
tains language-independent requirements for test methods for measuring confor-
mance to programming language binding specifications for ISO/IEC 14392 {6),
such as that contained in ISO/IEC 14394 {8}. This International Standard con-
tains C language-specific requirements for the test methods. Taken in conjunction
with the requirements imposed by ISO/IEC 14393 they constitute the require-
ments that shall be satisfied by test methods used for measuring conformance to
ISO/IEC 14394 (8).
1.1 Scope
---------------------- Page: 7 ----------------------
ISO/IEC 14395:1996(E)
OISOLIEC
1.2 Normative References
The following standards contain provisions which, through reference in this text,
constitute provisions of this International Standard. At the time of publication,
the editions indicated were valid. All standards are subject to revision, and parties
to agreements based on this International Standard are encouraged to investigate
the possibility of applying the most recent editions of the standards indicated
below. Members of IEC and IS0 maintain registers of currently valid Interna-
tional Standards.
ISO/IEC 9899: 1990,l) Programming languages-C.
Ul
ISO/IEC 9945-l: 19902) (IEEE Std 1003.1: 1990),3) Information
(2)
technology-Portable Operating System Interface (POSIX)-Part 1: System
Application Program Interface (API) [C language].
ISOIIEC 14362: 1996, Information technology-Test methods for measuring
131
conformance to Open Systems Interconnection (ON) abstract data
manipulation- Application Program Interface (API) [Language indepen-
dent].
ISOIIEC 14364: 1996, Information technology-Open Systems Interconnec-
{4)
tion (OSI) abstract data manipulation C language interfaces-Binding for
Application Program Interface (API).
ISOIIEC 14366: 1996, Information technology-Test methods for measuring
conformance to Open Systems Interconnection (OSI) abstract data manipula-
tion C language interfaces- Binding for Application Program Interface
(API).
ISO/IEC 14392: 1996, Information technology-Directory
(6
services-Application Program Interface (API.) [Language independent].
ISOIIEC 14393: 1996, Information technology-Test methods for measuring
conformance to directory services- Application Program Interface (API)
[Language independent].
Technology-Directory services C
ISO/IEC 14394: 1996, Information
language interfaces- Binding for Application Program Interface (API).
IEEE Std 1003.3-1991, IEEE Standard for Information Technology-Test
Methods for Measuring Conformance to POSIX.
1) ISO/IEC documents can be obtained from the IS0 Central Secretariat, 1 Rue de Varembe, Case
Postale 56, CH-1211, Geneve 20, Switzerland/Suisse.
2) ISO/IEC 9945-l: 1990 is currently under revision.
3) IEEE publications are available from the Institute of Electrical and Electronics Engineers,
Service Center, 445 Hoes Lane, P.O. Box 1331, Piscataway, NJ 08855-1331, USA.
1 General
2
---------------------- Page: 8 ----------------------
OISO/IEC
ISO/IEX 14395:1996(E)
1.3 Conformance
A set of test methods that conforms to this International Standard shall conform to
IEEE Std 1003.3-1991 (91, with references in IEEE Std 1003.3-1991 (9) to the
“P0SIX.n test method specification” being interpreted as references to this Inter-
national Standard, and references in IEEE Std 1003.3-1991 (9) to “the POSIX
standard for which conformance is being measured” being interpreted as references
to ISO/IEC 14394 (8).
In addition to meeting the conformance criteria defined in IEEE Std 1003.3-1991
(9}, a set of test methods that conforms to this International Standard shall test all
documentation assertions defined in this International Standard.
NOTE: Conformance to IEEE Std 1003.3-1991 (9) implies that the test methods will test all other
assertions defined in this International Standard.
A set of test methods that conforms to this International Standard shall also con-
form to ISO/IEC 14393 (7).
1.3 Conformance
---------------------- Page: 9 ----------------------
This page intentionally left blank
---------------------- Page: 10 ----------------------
0 ISO/IEC
ISO/IEC 14395:1996(E)
1 Section 2: Terminology and General Requirements
2 2.1 Conventions
3 2.1.1 General and Typographical Conventions
Many technical terms, such as “object” and “attribute,” are used in describing both
4
OS1 abstract data manipulation and directory services. In the first case, they refer
to constructs of the OS1 abstract data manipulation interface, while in the second
case they refer to constructs of the directory service to which the interface provides
access. The meanings ascribed to these terms in these cases are often similar but
9 different. Throughout this International Standard, care is taken to distinguish
10 between these meanings, for example by qualifying the term with “OM” or “direc-
11 tory” as appropriate (as with OM classes and directory classes and with OM attri-
12 butes and directory attributes). The unqualified term “attribute” denotes the direc-
13 tory construct, while the phrase “OM attribute” denotes the OS1 abstract data
14 manipulation construct. The phrase “object class” denotes the directory construct,
15 while the phrase “OM class” denotes the OS1 abstract data manipulation construct.
is used in two different senses, one by the language-
16 The term “operation”
17 independent specification conventions and one by the directory service descriptions.
18 When used in the sense of the directory, it is always qualified by the term “direc-
19 tory,” in the phrase “directory operation.” The unqualified term “operation” denotes
20 the language-independent specification construct. Sometimes, to reinforce the dis-
21 tinction, the phrase “interface operation” is used to denote the language-
22 independent specification construct, instead of “operation.”
23 The reader is urged to be cautious, and reference to 2.2 (Definitions) may be useful.
24 Language-independent concrete OM class names, OM attribute names, and OM
25 attribute value names appear in bold font while abstract OM class names appear
26 in bold italic font. They are all spelled with hyphens between words. The first
letters of language-independent OM class and OM attribute names are capitalized
27
(e.g., Filter-Item).
28
29 Language-independent datatype, operation argument, and error names appear in
30 Helvetica font, are lowercased, and are spelled with underscores between words
31 (e.g., ds abandon >.
-
OM class has a n associated datatype whose name i s obtained from the class
32 Each
name converting uppercase to lowercase, converting hyphens t ‘0 underscores,
33
bY
2.1 Conventions
---------------------- Page: 11 ----------------------
ISO/IEC 14395:1996(E) OISO/IEC
adding the prefix “ds- “, and adding the suffix ‘L_ type ”. (Thus, ds filter item-type is
- -
34 the datatype corresponding to OM class Filter-Item).
35 Function synopses and other extended pieces of C code appear in constant width
36 (courier) font while C language names embedded in ordinary text appear in italic
37 font. Underscores are used to separate words in C language names. The C
38 language names are derived mechanically from the corresponding language-
39 independent names in a manner described in 2.1.4.
40 A C language function, datatype, or code fragment appears in italic font. A func-
41 tion name is indicated by following parentheses [e.g., ds-abandon01 .
42
A C language symbolic constant, other than an error name, is surrounded by
43 braces (e.g., {DS MAX-OUTSTANDING-OPERATIONS)).
-
44 A C language symbolic constant for an error name is surrounded by brackets (e.g.,
45 [DS E ADMIN LIMIT-EXCEEDED]).
- - -
When important terms are introduced, they appear in italics. Italics are also used
46
47 in 2.2 for cross-references.
48 The use of fonts in this International Standard is as follows:
49 (1) The Helvetica font is used for:
50 - Language-independent operation names, such as ds-add-entry
- Language-independent datatype names, such as ds-status-type
51
52 - Language-independent error names, such as Abandon-Failed
53 (2) The itaZic font is used for:
54 - Language-independent operation arguments, such as session
- C language names embedded in ordinary text
55
56 - The introduction of important terms
57 - Cross-references in 2.2
58 (3) The bold font is used for:
- Language-independent concrete OM class names, such as Filter-Item
59
60 - Language-independent OM attribute names, such as Filter-Item-
61
Type
62 - Language-independent OM attribute values, such as approximate-
63 match
64 (4) The boZd italic font is used for:
65 - Language-independent abstract OM class names, such as Conznzon-
66 ResuZts
(5) The constant width (Courier) font is used for:
67
68 - References to terms defined in the X.500 directory standa ds
- Function synopses and other extended pieces of C code.
69
6 2 Terminology and Genera Requirements
---------------------- Page: 12 ----------------------
OISO/IEC ISO/lEC 14395:1996(E)
2.1.2 Representation of Strings of Numbers
70 Strings of numbers (such as ASN.l Object Identifier encodings) are represented in
71 the form “\xaa\xbb\xcc . . “, where each term \xnn represents an element of the
72 string, and the value of that element expressed in hexadecimal notation is nn. So,
73 for example, the string consisting of the three numbers 1, 10, 100 is represented as
74 “\xOl\xOa\x64 ”.
75 2.1.3 Language-Independent Conventions
76 The language-independent specification for this International Standard is con-
77 tained in ISO/IEC 14392 (6). The language-independent specification conventions
78 apply to that standard and to language-independent specification terms used in
79 this International Standard. These conventions are described in ISO/IEC 14360
80 (B13).
81 2.1.4 C Language Binding Conventions
82 2.1.4.1 Introduction
83 ISO/IEC 14394 (8) specifies C identifiers for all the elements of the interface, so
84 that application programs written in C can access the Directory. These elements
include function names, typedef names, and constants. All the C identifiers are
85
mechanically derived from the language-independent names as explained below.
86
87 2.1.4.2 C Naming Conventions
88 The interface uses part of the C public namespace for its facilities. All identifiers
89 start with the letters ds, Ds, or OAP. More detail about the conventions used is
90 given in Table 2-l. The interface reserves all identifiers starting with the letters
91 dsP for private (i.e., internal) use by implementations of the interface. It also
92 reserves all identifiers starting with the letters dsX or DSX for extensions of the
93 interface. If the cxds . h> header is included, the application shall not use any
94 identifier starting with these letters.
95 ISO/IEC 14360 {Bl3} uses similar, though not identical, naming conventions. All
96 OS1 abstract data manipulation identifiers are prefixed by the letters 02M or om.
97 The C identifiers are derived from the language-independent names used
throughout this International Standard by a purely mechanical process that
98
depends on the kind of name:
99
100 - The C function names are identical to the language-independent operation
101 names. Within text, they are italicized and followed by “0 ”.
102 Thus
- ds receive result
103
becomes - -
104
- ds-receive results)
105
-
2.1 Conventions
---------------------- Page: 13 ----------------------
ISO/IEC 14395:1996(E) OISO/IEC
106 Table 2-l - C Naming Conventions
107
108 Item Prefix 1
109 Reserved for implementors dsP
110 Reserved for interface extensions dsX
111 Reserved for interface extensions DSX
112 Reserved for implementors OMP
Functions ds
113
Error “problem” values DiE
114
115 OM class names DS-C-
OM value length limits DS-Vi
116
OM value number limits DS-VN-
117
Other constants DS- -
118 -
119 Attribute Type DS A
120 Object Class DS-O-
- -
121 - C function input parameters are identical to the corresponding language-
122 independent argument names. C function output parameters are derived
123 from the argument names by adding “- return” as a suffix. Thus, the output
124 argument
125
126
127
(Within text, both language-independent argument names and C function
128
parameter names are italicized.)
129
130 - The names of constants identifying OM classes are derived from the class
131 names by converting lowercase to uppercase, converting hyphens to under-
132 scores, and adding the prefix “DS C “.
- A
133 Thus
134 - Read-Result
135 becomes
- (DS C READ
136 RESULT}
- - -
137 - The names of C language constants that denote language-independent
138 specification choice values are derived from the choice value names by con-
139 verting lowercase to uppercase and adding the prefix “DS “.
-
140 Thus
141 - Default-Context
142 becomes
143 - {DS DEFAULT CONTEXT)
- -
- Enumeration tags are derived from the name of the corresponding OM syn-
144
tax by adding the prefix “DS “. Hyphens are converted to underscores, but
145
146 the case of letters is left unchanged.
147 Thus
148 - Enum(Limit-Problem)
149 becomes
150 - DS Limit Problem
- -
8
2 Terminology and General Requirements
---------------------- Page: 14 ----------------------
@ ISO/IEC
ISO/IEC 14395:1996(E)
- For enumeration constants, OM attributes and all
other constants except
151 errors, lowercase is converted to uppercase, hyphens
are converted to under-
152 scores, and the prefix “DS ” is added.
-
153 Thus
154 - O-Residential-Person
155 becomes
156 - {DS 0 RESIDENTIAL PERSON]
- - -
157 - Errors are treated as a special case. Constants that are the possible values
158 of the OM attribute Problem of a subclass of the OM class Error have
159 hyphens converted to underscores, are made entirely uppercase, and are
160 prefixed by “DS E “.
- -
161 Thus
162 - alias-dereferencing-problem
163 becomes
- [DS E ALIAS DEREFERENCING PROBLEM]
164
- - - -
165 - The constants in the “Value Length” and “Value Number” columns of the
166 OM class definition tables are also assigned identifiers. (They have no
167 names in the language-independent specification.) When the upper limit in
168 one of these columns is not “1” (one), it is given a name consisting of the OM
169 attribute name prefixed by “DS VL ” for value length or “DS VAT ” for
- - -
-
170 value numbers.
- The sequence of octets for each object identifier is also assigned an identifier
171
for internal use by certain OM macros. These identifiers are all uppercase
172
173 and are prefixed by “OMP 0 “. See ISO/IEC 14360 {Bl3} for further details
- -
174 on the use of object identifiers.
- In some cases, the transformations described above result in identifiers that
175
176 are more than 32 characters in length. The IS0 C Standard (1) only requires
177 identifiers to be unique within the first 32 characters. The abbreviations
178 listed in Table 2-2 are applied to substrings of identifiers to reduce their
length.
179
180 Note that hyphens are translated to underscores.
181 2.1.4.3 Use and Implementation of Interfaces
182 If an argument to a function has an invalid value (such as a value outside the
183 domain of the function, a pointer outside the address space of the program, or a
184 null pointer), the behavior is undefined.
Any function declared in a header may be implemented as a macro defined in the
185
header, so a library function should not be declared explicitly if its header is
186
187 included. Any macro definition of a function can be suppressed locally by enclosing
188 the name of the function in parentheses, because the name is not then followed by
189 the left parenthesis that indicates expansion of a macro function name. For the
190 same syntactic reason, it is permitted to take the address of a library function even
191 if it is also defined as a macro. The use of #undef to remove any macro definition
192 will also ensure that the identifier refers to an actual function. Any invocation of a
193 library function that is implemented as a macro shall expand to code that evalu-
194 ates each of its arguments exactly once, fully protected by parentheses where
necessary, so it is generally safe to use arbitrary expressions as arguments.
2.1 Conventions
9
---------------------- Page: 15 ----------------------
ISO/IEC 14395:1996(E) OISO/IEC
195 Table 2-2 - Identifier Abbreviations
196
Identifier Abbreviation Identifier
197 Abbreviation
I
ADMINISTRATIVE ADMIN NUMBER
198 NBR
AG OFFICE
199 AGENT OFF
APPLICATION APPLIC OPTIONAL
200 OPT
AUTOMATIC AUTO ORGANIZATIONAL
201 ORG
CERT ORGANIZATION
202 CERTIFICATE ORG
CRIT PERMISSION
203 CRITICAL PERM
DELIV PHYSICAL
204 DELIVERY PHYS
DEST PREFERRED
205 DESTINATION PREF
EXT PROHIBITED
206 EXTENSION PROHIB
EXT PROVINCE
207 EXTENSIONS PROV
IDENT QUALIFIER
208 IDENTIFIER
QUfi
IDENT REFERENCE REF
209 IDENTIFIER
INAPPROPRIATE INAPPROP REVOCATION REVOC
210
INFORMATION INFO SUPPORTED SUP
211
INTERNAT SUPPORTED SUPPORT
212 INTERNATIONAL
TERMINAL TERM
213 MODIFICATION MOD
Likewise, any function-like macros can be invoked in an expression anywhere a
214
function with a compatible return type could be called.
215
216 These concepts apply in this International Standard unless explicitly stated other-
217 wise in the C language binding descriptions.
218 2.1.4.4 Function Return Values
219 Except for ds initialize& the return value of a C function is bound to the Status
-
220 result of the language-independent description. Functions shall return a value of
221 type DS status, which is an error indication. If and only if the function succeeds,
-
its value shall be success, expressed in the C language by the constant
222
223 (DS SUCCESS]. If a function returns a status other than this, then it shall not
have updated the return parameters. The value of the status, in this case, shall be
224
an error as described in ISOIIEC 14392 (6).
225
226 Since the C language does not provid
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.