1、Standard ECMA-1624th Edition - December 1997Standardizing Information and Communication SystemsPhone: +41 22 849.60.00 - Fax: +41 22 849.60.01 - URL: http:/www.ecma.ch - Internet: helpdeskecma.chPortable Common ToolEnvironment (PCTE) -Ada Programming LanguageBinding.Standard ECMA-1624th Edition - De
2、cember 1997Standardizing Information and Communication SystemsPhone: +41 22 849.60.00 - Fax: +41 22 849.60.01 - URL: http:/www.ecma.ch - Internet: helpdeskecma.chIW ECMA-162.DOC 03-02-99 11,42Portable Common ToolEnvironment (PCTE) -Ada Programming LanguageBinding.Brief History(1) PCTE, Portable Comm
3、on Tool Environment, is an interface standard. The interface is designed tosupport program portability by providing machine-independent access to a set of facilities. Thesefacilities, which are described in the PCTE Abstract Specification (Standard ECMA-149), aredesigned particularly to provide an i
4、nfrastructure for programs which may be part of environmentssupporting systems engineering projects. Such programs, which are used as aids to systemsdevelopment, are often referred to as tools.(2) PCTE has its origin in the European Strategic Programme for Research and Development inInformation Tech
5、nology (ESPRIT) project 32, called “A Basis for a Portable Common ToolEnvironment“. That project produced a specification for a tool interface, an initialimplementation, and some tools on that implementation. The interface specifications wereproduced in the C Language. A number of versions of the sp
6、ecifications were produced,culminating in the fourth edition known as “PCTE Version 1.4“. That was in two volumes;volume 2 covered the user interface and volume 1 covered everything else. Subsequently, theCommission of the European Communities (CEC) commissioned Ada versions of the two volumesof the
7、 PCTE specification. Since 1988, a technical committee of ECMA, TC33, has continued thedevelopment of PCTE, in a form suitable for standardization under ECMA rules. This work wasundertaken by Task Group TGEP (later renamed TGOO) of ECMA TC33, which was formed inNovember 1988.(3) The work on the Ada
8、Language Binding for ECMA PCTE was started in mid 1990. The AdaLanguage Binding was the second binding of ECMA PCTE to be developed, though the strategyfor it was developed in parallel with that for the C Language Binding. The text of this bindingreflects the desire for the C and Ada Language Bindin
9、gs to be as compatible as possible.(4) Following acceptance of the first edition as an ECMA Standard in December 1991, review byinternational experts led to the production of second edition taking into account review commentsrelating to this standard and also maintaining consistency with the second
10、edition of StandardECMA-149. The second edition was accepted by the General Assembly of June 1993, and wassubmitted as part 3 of the draft PCTE standard to ISO/IEC JTC1 for fast-track processing tointernational standardization.(5) During the fast-track processing, which was successfully completed in
11、 September 1994,comments from National Bodies resulted in a number of changes to the draft standard. Somefurther editorial changes were requested by JTC1 ITTF. All these were incorporated in thepublished international standard, ISO/IEC 13719-3, with which the third edition of this ECMAstandard was a
12、ligned.(6) This fourth edition incorporates the resolutions of all comments received too late for considerationduring the fast-track processing, or after, and the contents of Standards ECMA-229 (Extensionsfor Support of Fine-Grain Objects) and ECMA-257 (Object Orientation Extensions). It is alignedw
13、ith the second edition of ISO/IEC 13719-3.Adopted as 4th Edition of Standard ECMA-162 by the General Assembly of December 1997.- i -Contents1 Scope 12 Conformance 13 Normative references 14 Definitions 25 Formal notations 26 Outline of the Standard 27 Binding strategy 27.1 Ada programming language s
14、tandard 27.2 General principles 27.3 Dynamic memory management 37.4 Complex entities as parameters 47.5 Character strings 47.6 Error conditions 47.7 Implementation limits 48 Datatype mapping 48.1 Mapping of PCTE datatypes to LI datatypes 58.1.1 Mapping of predefined PCTE datatypes 58.1.2 Mapping of
15、private PCTE datatypes 68.1.3 Mapping of complex PCTE datatypes 68.1.4 New LI datatype generators 78.2 Mapping of LI datatypes to Ada datatypes 88.2.1 LI datatype: boolean 88.2.2 LI datatype: pcte-integer 88.2.3 LI datatype: pcte-natural 88.2.4 LI datatype: pcte-float 98.2.5 LI datatype: pcte-time 9
16、8.2.6 LI datatype: octet 108.2.7 LI datatype: pcte-text 108.2.8 LI datatype generator: pcte-sequence 108.2.9 LI datatype generator: bounded-set 138.2.10 LI datatype: record 148.2.11 LI datatype: private 158.2.12 LI enumerated datatype: pcte-xxx 158.3 Deriving Ada subprogram semantics from the abstra
17、ct specification 158.4 Package Pcte 16- ii -9 Object managment 349.1 Object management datatypes 349.2 Link operations 349.3 Object operations 399.4 Version operations 4710 Schema management 4910.1 Schema management datatypes 4910.2 Update operations 5110.3 Usage operations 5710.4 Working schema ope
18、rations 5911 Volumes, devices, and archives 6111.1 Volume, device, and archive datatypes 6111.2 Volume, device, and archive operations 6112 Files, pipes, and devices 6712.1 File, pipe, and device datatypes 6712.2 File, pipe, and device operations 6713 Process execution 7013.1 Process execution datat
19、ypes 7013.2 Process execution 7413.3 Security operations 7713.4 Profiling operations 7813.5 Monitoring operations 7914 Message queues 8014.1 Message queue datatypes 8014.2 Message queue operations 8215 Notification 8515.1 Notification datatypes 8515.2 Notification operations 8516 Concurrency and int
20、egrity control 8616.1 Concurrency and integrity control datatypes 8616.2 Concurrency and integrity control operations 8617 Replication 8817.1 Replication datatypes 8817.2 Replication operations 88- iii -18 Network connection 8918.1 Network connection datatypes 8918.2 Network connection operations 90
21、18.3 Foreign system operations 9218.4 Time operations 9219 Discretionary security 9219.1 Discretionary security datatypes 9219.2 Discretionary access control operations 9519.3 Discretionary security administration operations 9620 Mandatory security 9720.1 Mandatory security datatypes 9720.2 Mandator
22、y security operations 9820.3 Mandatory security administration operations 9920.4 Mandatory security operations for processes 10121 Auditing 10121.1 Auditing datatypes 10221.2 Auditing operations 11022 Accounting 11622.1 Accounting datatypes 11622.2 Accounting operations 11922.3 Consumer identity ope
23、rations 12123 References 12124 Limits 12125 Errors 122Annex A - The object orientation module 133Index of abstract operations 143Index of Ada subprograms 149Index of Ada datatypes 155- iv -.1Scope(1) This ECMA Standard defines the binding of the Portable Common Tool Environment (PCTE)interfaces, as
24、specified in ECMA-149, to the Ada programming language.(2) A number of features are not completely defined in ECMA-149, some freedom being allowed tothe implementor. Some of these features are specified as implementation limits. Some constraintsare placed on these implementation limits by this ECMA
25、Standard . These constraints arespecified in clause 24.(3) PCTE is an interface to a set of facilities that forms the basis for constructing environmentssupporting systems engineering projects. These facilities are designed particularly to provide aninfrastructure for programs which may be part of s
26、uch environments. Such programs, which areused as aids to system development, are often referred to as tools.2 Conformance(1) An implementation of PCTE conforms to this ECMA Standard if it conforms to 2.2 ofECMA-149, where the binding referred to there is taken to be the Ada language binding defined
27、 inclauses 1 to 5 and 8 to 25 of this ECMA Standard. All other parts of this ECMA Standard areprovided as assistance to the reader and are not normative.(2) The Ada language binding defined in this ECMA Standard conforms to 2.1 of ECMA-149.3 Normative references(1) The following standards contain pr
28、ovisions which, through reference in this text, constituteprovisions of this ECMA Standard. At the time of publication, the editions indicated were valid.All standards are subject to revision, and parties to agreements based on this ECMA Standard areencouraged to investigate the possibility of apply
29、ing the most recent editions of the standardsindicated below.(2) ECMA-149 Portable Common Tool Environment (PCTE) - Abstract Specification(4th edition, December 1997)(3) ECMA-158 Portable Common Tool Environment (PCTE) - C Programming LanguageBinding (4th edition, December 1997)(4) ISO 8601 Data ele
30、ments and interchange formats - Information interchange -Representation of dates and times (1988)(5) ISO/IEC 8652 Information technology - Programming languages, their environmentsand system software interfaces - Ada programming language,(referring to ANSI-MIL-STD 1815A - Reference Manual for the Ad
31、aProgramming Language) (1995)(6) ISO/IEC/TR 10182 Information technology - Programming languages, their environmentsand system software interfaces - Guidelines for language bindings(1993)(7) ISO/IEC 11404 Information technology - Programming languages, their environmentsand system software interface
32、s - Language-independent datatypes(1996)- 2 -4 Definitions(1) All technical terms used in this ECMA Standard, other than a few in widespread use, are definedin the body of this ECMA Standard or in the referenced documents.5 Formal notations(1) All datatypes and subprogram definitions are expressed u
33、sing ISO/IEC 8652 conformant syntax.6 Outline of the Standard(1) Clause 7 describes the strategy used to develop this binding specification.(2) Clause 8 defines the mapping from the datatypes that are used in the abstract specification to Adaprogramming language datatypes.(3) Clauses 9 to 22 define
34、the bindings of datatypes and operations in the corresponding clauses ofECMA-149. The extensions for fine-grain objects are added at the end of clause 11.(4) Clause 23 defines the binding of object and type references, as specified in ECMA-149 23.1.2 and23.2. Because of the package structure, this c
35、lause consists of a cross-reference to the definitionswhich are in 8.4.(5) Clause 24 defines the binding of the implementation limit subprograms described in ECMA-149,clause 24.(6) Clause 25 defines the binding of the error conditions specified in ECMA-149, clause 25, anddefines binding-defined erro
36、r conditions for the Ada binding.(7) Annex A, which is normative, contains the extensions for object orientation, corresponding toannex G of ECMA-149.7 Binding strategy7.1 Ada programming language standard(1) The Ada package specifications were designed to conform to ISO/IEC 8652.7.2 General princip
37、les(1) The following general principles were applied when generating the binding in this ECMAStandard.(2) ISO/IEC/TR 10182 should be followed as far as possible for binding method 1: provide acompletely defined procedural interface.(3) Each operation in ECMA-149 should be represented by one subprogr
38、am in this ECMA Standardunless there are specific reasons to the contrary.(4) All Ada identifiers should be in lower case except for predefined identifiers, named constantvalues, and enumeration literals. Since the Ada standard is insensitive to case this is fortypographical consistency between ECMA
39、-149, ECMA-158, and this ECMA Standard.- 3 -(5) Nondefining occurrences of the names of Ada subprograms and types should use the fullyqualified form, so as to identify all package dependences.(6) All the Ada packages should have names that begin with Pcte_ to ensure they are unique withinan Ada Libr
40、ary System. The choice of case of the characters of Pcte is for typographicalconsistency with ECMA-158.(7) An abstract operation with name of the form TYPE_VERB_PHRASE should be mapped to anAda subprogram verb_phrase declared by a package called Pcte_type. For example,PROCESS_SET_WORKING_SCHEMA is m
41、apped to Pcte_process.set_working_schema(8) When a package hierarchy is required, it should be compatible with the abstract specificationclause organisation. For example, ACCOUNTING_LOG_READ is mapped toPcte_accounting.log.read.(9) Names should be retained from ECMA-149 as far as possible.(10) All a
42、dditional names should be chosen appropriately for their meanings.(11) Each operation that can return errors should have an additional in parameter of an access typedesignating an object into which error indications can be returned. This allows the subprogramsto be procedures or functions as appropr
43、iate.(12) Wherever practical, types introduced for passing complex data entities between a caller and asubprogram should be private or limited private. Limited private types should be used unless thebasic operations on entities of such types are safe and consistent with ECMA-149.(13) All simple para
44、meter types in ECMA-149 that represent attribute value types should be mappedto corresponding Ada types defined by this binding.(14) All simple parameter types in ECMA-149 that do not represent attribute value types should bemapped to predefined types or subtypes or derived types of predefined types
45、.7.3 Dynamic memory management(1) A type defined in this ECMA Standard for which an object is created dynamically is alwayslimited private, and subprograms are provided to construct, access and discard such objects.(2) It is the responsibility of the Ada program that declares a variable of such an A
46、da type to ensurethat its construct subprogram is called before the variable is read; the construct subprogramalways initializes the value of the variable. Use of a variable of this type before calling itsconstruct subprogram, or after calling its discard subprogram always causes an error to begener
47、ated.(3) It is the responsibility of the Ada program that defines variables of such Ada types to ensure thatthe discard subprogram is called when the variable is no longer needed and before the immediatescope of the variable is left. If such a variable goes out of scope without being discarded there
48、 isthe possibility that the memory allocated to it cannot be recovered, which may result in theexception STORAGE_ERROR being raised subsequently.(4) If a constructed variable is constructed again without having been discarded, no error is reported;such usages of the interface are regarded as akin to
49、 allowing such variables to go out of scopebefore they are discarded.- 4 -7.4 Complex entities as parameters(1) Some complex entities to be passed into or retrieved from an operation are defined as sets orsequences of a base type in ECMA-149. Where such sets and sequences are bounded andconstrainable by the user they are mapped to Ada language array types.(2) Where such sets and sequences are unbounded they are mapped to limited private types declaredby nested packages. These limited private types are defined with operations for construction withinitial value, acce
