Change Production 80 to remove <fixed_pt_type> as a valid parameter type:

<param_type_spec> ::= <base_type_spec>
        | <string_type>
        | <wide_string_type>
        | <fixed_pt_type>
        | <scoped_name>

Also add the missing production on page 3-19:

<fixed_pt_const_type> ::= "fixed"

Rational:

Leaving this in causes problems with the C++ binding in the same way
that the grammar from CORBA 1.1 and earlier had problems with
sequences and arrays as parameters.  This is also likely to cause
problems with the Ada binding, since each fixed point declaration is
mapped to a distinct Ada type.

Part 2:  Fix the grammar for fixed point constants [Resolves #1066]

Change the first paragraph of section 3.7.2 to read:

The <scoped_name> in the <const_type> production must be a previously
defined name of an <integer_type>, <char_type>, <wide_ char_type>,
<boolean_type>, <floating_pt_type>, <string_type>, or
<wide_string_type> constant.

Also, change the "3000.00" in the example of fixed point digits and
scale to "3000.00D".

Rational:

Fixed point constants are defined using the syntax "fixed", not
"fixed<d,s>", while fixed point types are defined using the later
syntax.  So there is no way for a <scoped_name> to refer to a
<fixed_pt_const_type>.

Part 3: Modify the paragraph at the top of 3-21 to read:

A quotient may have an arbitrary number of decimal places, denoted by
a scale of s inf . The computation proceeds pairwise, with the usual
rules for left-to-right association, operator precedence, and
parentheses. All intermediate computations should be performed using
double precision (i.e. 62 digit) arithmetic.  If an individual
computation between a pair of fixed-point literals actually generates
more than 31 significant digits, then a 31-digit result is retained as
follows:

Rational:  This change is to make sure that all IDL compilers
calculate the results of fixed-point constants the same way, so as not
to break interoperability.

Part 4: Reword the description of Fixed Type in section 3.8.3 to be:

The fixed data type represents a fixed-point decimal number of up to
31 significant digits. The scale factor is a non-negative integer less
than or equal to the total number of digits (note that constants with
effectively negative scale, such as 10000, are always permitted).

The fixed data type will be mapped to the native fixed point
capability of a programming language, if available.  If there is not a
native fixed point type, then the IDL mapping for that language will a
fixed point data type.  Applications that use the IDL fixed point type
across multiple programming languages must take in to account
differences between the languages in handling rounding, overflow, and
arithmetic precision.

Rational:

If these values of scale are not universally supported by language
bindings, then they are not portable, and so should not be supported
by IDL.

The Smalltalk, Ada, Cobol and Java languages already contain a native
fixed point facility.  To define a separate IDL fixed point capability
for these languages would be redundant and interfere with integrating
legacy code.
 

Revised Text:
1. Change Production 80 to remove <fixed_pt_type> as a valid parameter type:

<param_type_spec> ::= <base_type_spec>
        | <string_type>
        | <wide_string_type>
        | <fixed_pt_type>
        | <scoped_name>

Also add the missing production on page 3-19:

<fixed_pt_const_type> ::= "fixed"

2. Change the first paragraph of section 3.7.2 to read:

The <scoped_name> in the <const_type> production must be a previously
defined name of an <integer_type>, <char_type>, <wide_ char_type>,
<boolean_type>, <floating_pt_type>, <string_type>, or
<wide_string_type> constant.

Also, change the "3000.00" in the example of fixed point digits and
scale to "3000.00D".

3. Modify the paragraph at the top of 3-21 to read:

A quotient may have an arbitrary number of decimal places, denoted by
a scale of s inf . The computation proceeds pairwise, with the usual
rules for left-to-right association, operator precedence, and
parentheses. All intermediate computations should be performed using
double precision (i.e. 62 digit) arithmetic.  If an individual
computation between a pair of fixed-point literals actually generates
more than 31 significant digits, then a 31-digit result is retained as
follows:

4. Reword the description of Fixed Type in section 3.8.3 to be:

The fixed data type represents a fixed-point decimal number of up to
31 significant digits. The scale factor is a non-negative integer less
than or equal to the total number of digits (note that constants with
effectively negative scale, such as 10000, are always permitted).

The fixed data type will be mapped to the native fixed point
capability of a programming language, if available.  If there is not a
native fixed point type, then the IDL mapping for that language will a
fixed point data type.  Applications that use the IDL fixed point type
across multiple programming languages must take in to account
differences between the languages in handling rounding, overflow, and
arithmetic precision.

Actions to be taken: incorporate changes in 2.3 and close this issue and 1066.
October 21, 1997: received issue

Issue 776: CORBA 2.1 IR Structdef typo (orb_revision)

Issue 783: IDL types are ambiguous with inheritance (orb_revision)

Issue 884: Appendix B lists incorrect CORBA Components IDs (orb_revision)

Issue 903: Ambiguity in non_existent() specification (orb_revision)

Insert the following para after para 1:

        Probing for object non-existence may require contacting
        the ORB that implements the target object. If an attempt
        to contact the target object fails and therefore, no reliable
        determination can be made, non_existent raises whatever exception
        was raised by the remote ORB to the application code. This is
        necessary to enable an application to distinguish between the
        true, false, and indeterminate cases.
 

Actions to be taken: incorporate revised text and close issue.
January 13, 1998: received issue
 
 

Issue 910: #pragma processing (orb_revision)

Issue 912: Inheritance of Exceptions (orb_revision)

The fundamental reason why multiple inheritence can work for
interfaces, but not for exceptions is that interfaces are abstract, without any
visible data storage, but exceptions are concrete types with visible
data storage.  To allow multiple inheritence of exceptions when mapping to
a language like C, would require that the exception layout be explicitly
visible to the programmer, using a mechanism similar to C++ handling
of virtual base classes.  This solution would be very messy and make
programming with exceptions very difficult for those languages.
Revised Text:
Actions taken: Prpose close issue with above resolution and no change.
January 22, 1998: received issue

Issue 913: defined_in member of ModuleDescription for top-level module (orb_revision)

However, a Container that is not a Contained, i.e. a Repository, does not have any id attribute and presumably, thus, has no RepositoryId. For instance, there is no way to get the RepositoryId of a Repository, if it had one (which I presume it does not). That is, id is an attribute of Contained, not of Container.

This problem occurs not only for ModuleDef, but also for InterfaceDef, TypeDef, ExceptionDef, ConstantDef, i.e. things that can be placed in the top level Repository.

Probably the simplest fix would be to declare that the repositoryID of the Repository is an empty
string and use that value for the  defined_in field of the Def structures.

Revised Text:
Add the following paragraph immediately following the first paragraph of section 8.5.6 pp 8-16

"Since Repository derives only from Container and not from Contained, it does not have a RopositoryId associated with it. By default it is deemed to have the RepositoryId "" (the empty string) for purposes of assigning a value to the defined_in field of the definition structure of ModuleDef, InterfaceDef, TypeDef, ExceptionDef and ConstantDef that are contained immediately in the Repository object".

Actions to be taken: Incorporate change in 2.3 and close issue
January 21, 1998: received issue

Issue 916: Resetting #pragma prefix? (orb_revision)

Issue 918: CORBA::Contained::describe() underspecified (orb_revision)

" The 'kind' field of the returned Description struct shall give the DefinitionKind for the most derived type of the object."

Append after the last sentence of the same paragraph: "The kind field in this must contain dk_attribute and not the kind of any IRObject from which the attribute object is derived. For example returning dk_all would be an error."

Actions to be taken: incorporate proposed change in 2.3 and close issue.
January 25, 1998: received issue
 

Issue 992: CORBA 2.2 - "native" and the interface repository (orb_revision)

Issue 999: #pragma prefix issue (orb_revision)

Add the following text at the end of the intro to section 8.6 (before
section 8.6.1:

  Since new repository ID formats may be added from time to time,
    compliant IDL compilers must accept any string value of the form
    "<format>:<string>" provided as the argument to the id pragma and
    use it as the repository ID.  The OMG maintains a registry of
    allocated format identifiers.  The <format> part of the ID may not
    contain a colon (:) character.

    The version and prefix pragmas only affect default repository IDs
    that are generated by the IDL compiler using the IDL format.

Change the last sentence of para 1 in section 8.6.4 to read:

        An IDL compiler must interpret these annotations as specified.

Add the following text at the end of "The ID Pragma":

        The <id> must be a repository ID of the form described in 8.6.

        If an attempt is made to assign a repository ID to the same
        IDL construct a second time, a compile-time diagnostic shall
        be emitted, regardless of whether the second ID is in conflict or not:

        interface A {};
        #pragma ID A "IDL:A:1.1"
        #pragma ID A "IDL:X:1.1"        // Compile-time error

        interface B {};
        #pragma ID B "IDL:BB:1.1"
        #pragma ID B "IDL:BB:1.1"       // Compile-time error

        It is also an error to apply an ID to a forward-declared interface
        and then later assign the same or a different ID to that interface.

Para 1 of 8.6.4 says:

        The pragma directives can be used with the OMG IDL, DCE UUID, and
        LOCAL formats.

Change this to:

        The prefix and version pragma directives only apply to IDL formats.

Replace the last sentence of the para following the first example of 8.6.4,
"The Prefix Pragma" with the following text:

        The specified prefix applies to RepositoryIds generated after
        the pragma until the end of the current scope is reached or
        another prefix pragma is encountered. An IDL file forms a scope
        for this purpose, so a prefix resets to the previous prefix
        at the end of the scope of an included file:

        // A.idl
        #pragma prefix "A"
        interface A {};

        // B.idl
        #pragma prefix "B"
        #include "A.idl"
        interface B {};

        The repository IDs for interfaces A and B in this case are:

        IDL:A/A:1.0
        IDL:B/B:1.0
 
        Similarly, a prefix in an including file does not affect the
        prefix of an included file:

        // C.idl
        interface C {};

        // D.idl
        #pragma prefix "D"
        #include "C.idl"
        interface D {};

        The repository IDs for interface C and D in this case are:

        IDL:C:1.0
        IDL:D/D:1.0

        If an included file does not contain a #pragma prefix, the
        current prefix implicitly resets to the empty prefix:

        // E.idl
        interface E {};

        // F.idl
        module M {
        #include <E.idl>
        };

        The repository IDs for module M and interface E in this case are:

        IDL:M:1.0
        IDL:E:1.0

        If a #include directive appears at non-global scope and the included
        file contains a prefix pragma, the included file's prefix takes
        precedence, for example:

        // A.idl
        #pragma prefix "A"
        interface A {};

        // B.idl
        #pragma prefix "B"
        module M {
        #include "A.idl"
        };

        The repository ID for module M and interface A in this case are:

        IDL:B/M:1.0
        IDL:A/A:1.0

        Attempts to assign a prefix to a forward-declared interface and
        a different prefix to that interface later result in a compile-time
        diagnostic:

        #pragma prefix "A"
        interface A;            // Forward decl.

        #pragma prefix "B"
        interface A;            // Compile-time error

        #pragma prefix "C"
        interface A {           // Compile-time error
                void op();
        };

        A prefix pragma of the form

        #pragma prefix ""

        resets the prefix to the empty string. For example:

        #pragma prefix "X"
        interface X {};
        #pragma prefix ""
        interface Y {};

        The repository IDs for interface X and Y in this case are:

        IDL:X/X:1.0
        IDL:Y:1.0

        If a specification contains both a prefix pragma and an ID or version
        pragma, the prefix pragma does not affect the repository ID for
        an ID pragma, but does affect the repository ID for a version pragma:

        #pragma prefix "A"
        interface A {};
        interface B {};
        interface C {};
        #pragma ID B "IDL:myB:1.0"
        #pragma version C 9.9

        The repository IDs for this specification are

        IDL:A/A:1.0
        IDL:myB:1.0
        IDL:A/C:9.9

        A #pragma prefix must appear before the beginning of an IDL
        definition. Placing a #pragma prefix elsewhere has undefined
        behavior, for example:

        interface Bar
        #pragma prefix "foo"    // Undefined behavior
        {
                // ...
        }

Add the following text to the end of "The Version Pragma" on page 8-33:
 
        If an attempt is made to change the version of a repository ID
        that was specifed with an ID pragma, a compliant compiler shall
        emit a diagnostic:

        interface A {};
        #pragma ID A "IDL:myA:1.1"
        #pragma version A 9.9           // Compile-time error

        If an attempt is made to assign a version to the same
        IDL construct a second time, a compile-time diagnostic shall
        be emitted, regardless of whether the second version is in
        conflict or not:

        interface A {};
        #pragma version A 1.1
        #pragma version A 2.2           // Compile-time error

        interface B {};
        #pragma version B 1.1
        #pragma version B 1.1           // Compile-time error

Action to be taken: Incorporate text as above and close issues 910, 916, 999

Issue 1054: Marshalling is_equivalent (orb_revision)

Issue 1066: Fixed point constant typo in 2.2 (orb_revision)

Issue 1067: Wide character and wide string literals (orb_revision)

        1) The section about *character* literals talks about wide *string*
           literals, but the section about *string* literals says nothing
           about wide string literals.

           Character and wide character literals should be discussed in
           the section on character literals, and string and wide string
           literals should be discussed in the section on string literals.

        2) The last sentence doesn't make sense. It says that literals
           are limited to ISO 8859-1, but that identifiers are limited
           to ISO 8859-1.

           Also, with the identifier change to ASCII letters, digits, and
           underscores, this no longer applies.

        3) If wide character and string literals are exactly like normal
           literals, the tokenizer becomes context-sensitive. This is
           a Bad Thing (TM).

Here is the proposal:
Revised Text:
In section  3.2.5
Change the last para of "Character Literals" to read:

        Wide character literals have an L prefix, for example:

        const wchar C1 = L'X';

        Attempts to assign a wide character literal to a non-wide character
        constant or to assign a non-wide character literal to a wide
        character constant result in a compile-time diagnostic.

        Both wide and non-wide character literals must be specified using
        characters from the ISO 8859-1 character set.

Add the following text to the end of the "String Literals" section:

        Wide string literals have an L prefix, for example:

        const wstring S1 = L"Hello";

        Attempts to assign a wide string literal to a non-wide string
        constant or to assign a non-wide string literal to a wide
        string constant result in a compile-time diagnostic.

        Both wide and non-wide string literals must be specified using
        characters from the ISO 8859-1 character set.

        A wide string literal shall not contain the wide character with
        value zero.
 

Actions to be taken taken: Incorporate change and close issue.
March 18, 1998: received issue
 

Issue 1068: Fixed point constants issue (orb_revision)

The text is quite clear about the mechanism for assigning digits and
scale to fixed point constants.  This part of the text only addresses
how the IDL compiler evaluates arithmetic expressions involving fixed
point literals at compile time and is not intended to define how fixed
point arithmetic works in various programming languages at run time.
Revised Text:
Actions to be taken: close no change
March 18, 1998: received issue

Issue 1071: Type of fixed point quotients (orb_revision)

The text is quite clear about the mechanism for assigning digits and
scale to fixed point constants.  This part of the text only addresses
how the IDL compiler evaluates arithmetic expressions involving fixed
point literals at compile time and is not intended to define how fixed
point arithmetic works in various programming languages at run time.
Revised Text:
Actions to be taken: close no change
March 19, 1998: received issue

Issue 1074: Typo in type code section (13.3.4) (orb_revision)

Issue 1086: How to deal with object identity (orb_revision)

Issue 1087: IDl "module" construct - IDL files (orb_revision)

The only restriction with most (all?) current IDL compilers is that
all of the IDL must be compiled at once. In practice, that's not
hard to achieve.

No change needed in specification.
Revised Text:
Actions taken: Close no change
March 20, 1998: received issue

Issue 1088: ORB_init (orb_revision)

Issue 1091: Editorial issue, chapter 8 (orb_revision)

Issue 1094: Indentation on page 4-4 (orb_revision)

Issue 1146: Semantics and standard exceptions (orb_revision)

        The following provides explanations as to the conditions
        in which each exception is raised by an ORB. The list of conditions
        is not exhaustive because the number of possible failure conditions
        for a particular ORB is too large to enumerate as well as
        implementation-dependent.

The current text already explains OBJECT_NOT_EXIST and the transaction
exceptions. Add the following text to cover the remaining exceptions:

- UNKNOWN

  This exception is raised if an operation implementation throws
  a non-CORBA exception (such as an exception specific to the
  implementation's programming language), or if an operation raises
  a user exception that does not appear in the operation's raises
  expression. UNKNOWN is also raised if the server returns a system
  exception that is unknown to the client. (This can happen if the server
  uses a later version of CORBA than the client and new system exceptions
  have been added to the later version.)

- BAD_PARAM

  A parameter passed to a call is out of range or otherwise considered illegal.
  An ORB may raise this exception if null values or null pointers are passed
  to an operation (for language mappings where the concept of a null pointers
  or null values applies). BAD_PARAM can also be raised as a result of client
  generating requests with incorrect parameters using the DII.

- NO_MEMORY

  The ORB run time has run out of memory.

- IMP_LIMIT

  This exception indicates that an implementation limit was exceeded in the
  ORB run time. For example, an ORB may reach the maximum number of
  references it can can hold simultaneously in an address space, the size
  of a parameter may have exceeded the allowed maximum, or an ORB may
  impose a maximum on the number of clients or servers that can run
  simultaneously.

- COMM_FAILURE

  This exception is raised if communication is lost while an operation
  is in progress, after the request was sent by the client, but before
  the reply from the server has been returned to the client.

- INV_OBJREF

  This exception indicates that an object reference is internally
  malformed. For example, the repository ID may have incorrect syntax
  or the addressing information may be invalid. This exception is
  raised by ORB::string_to_object if the passed string does not decode
  correctly.

  An ORB may choose to detect calls via nil references (but is
  not obliged to do detect them). INV_OBJREF is used to indicate this.

- NO_PERMISSION

  An invocation failed because the caller has insufficient privileges.

- INTERNAL

  This exception indicates an interal failure in an ORB, for example,
  if an ORB has detected corruption of its internal data structures.

- MARSHAL

  A request or reply from the network is structurally invalid. This error
  typically indicates a bug in either the client-side or server-side run
  time. For example, if a reply from the server indicates that the message
  contains 1000 bytes, but the actual message is shorter or longer than
  1000 bytes, the ORB raises this exception. MARSHAL can also be caused
  by using the DII or DSI incorrectly, for example, if the type of the
  actual parameters sent does not agree with IDL signature of an operation.

- INITIALIZE

  An ORB has encountered a failure during its initialization, such as failure
  to acquire networking resources or detecting a configuration error.

- NO_IMPLEMENT

  This exception indicates that even though the operation that was invoked
  exists (it has an IDL definition), no implementation for that operation
  exists. NO_IMPLEMENT can, for example, be raised by an ORB if a client
  asks for an object's type definition from the interface repository, but
  no interface repository is provided by the ORB.

- BAD_TYPECODE

  The ORB has encounted a malformed type code (for example, a type code
  with an invalid TCKind value).

- BAD_OPERATION

  This indicates that an object reference denotes an existing object, but that
  the object does not support the operation that was invoked.

- NO_RESOURCES

  The ORB has encountered some general resource limitation. For example, the
  run time may have reached the maximum permissible number of open connections.

- NO_RESPONSE

  This exception is raised if a client attempts to retrieve the result of
  a deferred synchronous call, but the response for the request is not
  yet available.

- PERSIST_STORE

  This exception indicates a persistent storage failure, for example,
  failure to establish a database connection or corruption of a database.

- BAD_INV_ORDER

  This exception indicates that the caller has invoked operations in the
  wrong order. For example, it can be raised by an ORB if an application
  makes an ORB-related call without having correctly initialized the ORB
  first.

- TRANSIENT

  TRANSIENT indicates that the ORB attempted to reach an object
  and failed. It is not an indication that an object does not exist.
  Instead, it simply means that no further determination of an object's
  status was possible because it could not be reached.

- FREE_MEM

  The ORB failed in an attempt to free dynamic memory, for example because
  of heap corruption or memory segments being locked.

- INV_IDENT

  This exception indicates that an IDL identifier is syntactically invalid.
  It may be raised if, for example, an identifier passed to the interface
  repository does not conform to IDL identifier syntax, or if an illegal
  operation name is used with the DII.

- INV_FLAG

  An invalid flag was passed to an operation (for example, when creating
  a DII request).

- INTF_REPOS

  An ORB raises this exception if it cannot reach the interface repository,
  or some other failure relating to the interface repository is detected.

- BAD_CONTEXT

  An operation may raise this exception if a client invokes the operation
  but the passed context does not contain the context values required
  by the operation.

- OBJ_ADAPTER

  This exception typically indicates an administrative mismatch.
  For example, a server may have made an attempt to register itself
  with an implementation repository under a name that is already in
  use, or is unknown to the repository. OBJ_ADAPTER is also raised
  by the POA to indicate problems with application-supplied servant
  managers.

- DATA_CONVERSION

  This exception is raised if an ORB cannot convert the representation of
  data as marshaled into its native representation or vice-versa. For example,
  DATA_CONVERSION can be raised if wide character codeset conversion fails,
  or if an ORB cannot convert floating point values between different
  representations.
Actions to be taken: incorporate changes as above in 2.3 and close issue
April 16, 1998: received issue
June 25, 1998: moved from port-rtf to orb_revision

Issue 1241: / in prefix pragma? (orb_revision)

Issue 1258: Type code constants are not defined/mentioned in OBV spec (obv-rtf)

Replace the first paragraph of 8.7.2 with:

For IDL type declarations, the IDL compiler produces (if asked) a declaration of a TypeCode
constant. See the language mapping rules for more information about the
names of the generated TypeCode constants.  TypeCode constants include
tk_alias definitions wherever an IDL typedef is referenced.  These
constants can be used with the dynamic invocation interface and other
routines that require TypeCodes.

The predefined TypeCode constants, named according to the C language
mapping, are:

TC_null
TC_void
TC_short
TC_long
TC_longlong
TC_ushort
TC_ulong
TC_ulonglong
TC_float
TC_double
TC_longdouble
TC_boolean
TC_char
TC_wchar
TC_octet
TC_any
TC_TypeCode
TC_Object = tk_objref { Object }
TC_string= tk_string { 0 } // unbounded
TC_wstring = tk_wstring{0} mmmmm/// unbounded
Actions to be taken: incorporate change in 2.3 and close
April 28, 1998: received issue

Issue 1394: Typos in IR IDL in spec (01) (orb_revision)

Issue 1395: Typos in IR IDL in Specification (02) (orb_revision)

Issue 1396: Typos in IR IDL in Specification (03) (orb_revision)

Issue 1397: Typos in IR IDL in Specification (04) (orb_revision)

Issue 1398: Typos in IR IDL in Specification (050 (orb_revision)

Issue 1422: Does the DII support the standard object operations? (orb_revision)

The implicit object reference operations non_existent, is_a, get_interface and (deprecated) get_implementation may be invoked using DII. No other implicit object reference operations may be invoked via DII.

To create a request for any one of these allowed implicit object reference operations, create_request must be passed the name of the operation with a "_" prepended, in the  parameter "operation". For example to create a DII request for "is_a", the name passed to create_request must be "_is_a". If the name of an implicit operation that is not ivocable through DII is passed to create_request with a "_" prepended, create_request shall raise a BAD_PARAM exception. For example if "_is_equivalent" is passed to create_request as the "operation" parameter will cause create_request to raise the BAD_PARAM exception.

Actions to be taken: Incorporate new text and close issue.
 

Issue 1541: Type code typos (as only one issue) (orb_revision)

 (1) From TypeCode PIDL on Page 8-37

// deprecated interface
 long param_count ();
 any parameter (in long index) raises (Bounds);

(2) remove the text begining with "The deprecated param_count and parameter operations..." at the top of page 8-39 and ending just before section 8.7.2 on page 8-40.

Actions to be taken taken: Fix and close in 2.3
June 24, 1998: received issue
 

Issue 1542: Type code operations under-specified (orb_revision)

1) In para 6 page 8-39 insert the following after the second sentence:
"For example, the member count of a structure with three members is three."

The second half of this issue namely origin of index is addressed in 1543.

Actions to be taken: incorporate proposed change in 2.3 and close
June 24, 1998: received issue

Issue 1543: Type code parameter ordering (orb_revision)

"The order in which members are presented in the intrface repository is the same as the order in which they appeared in the IDL specification, and this ordering determines the index value for each member. The first member has index value 0. For example for a structure definition:

    struct example {
        short    member1;
        short    member2;
        long     member3;
    };

    member1 has index = 0, member2 has index = 1, and member3 has index = 2."

Actions to be taken: incorporate proposed change in 2.3 and close
June 24, 1998: received issue

Issue 1545: Type codes cannot describe all unions (orb_revision)