Interface Definition Language Avatar
  1. OMG Specification

Interface Definition Language — Closed Issues

  • Acronym: IDL
  • Issues Count: 9
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Descriptions

Clarify and perhaps expand where annotations can be applied

  • Key: IDL41-9
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The specification should allow application of annotations to:
    declarations, members, function parameters, union discriminator, enumerator literals, typedefs, sequence parameter, array parameter.

    Some examples:

    struct SS {
        @MemberAnnotation(value)  MyType  m1;
    };
    
    emum EE {
        @Value(value)  Enum1;
    };
    
    union MyUnion switch ( @key long ) {
       case 1:
           @CaseMemberAnn MT1 m1;
       defalt:
           long l;
    };
    struct SS {
        @shared sequence< MyType, 3>   m1;
        sequence<@shared  MyType, 3>   m1;
    
        @shared MyType m1[3];
        MyType @shared m1[3];
    
        @shared MyMatrix mm[3][4];
        MyMatrix @shared mm[3][4];
    };
    
    
    typedef MyType @shared MyTypeArray3[3];
    typedef @shared MyType MyTypeArray3[3];
    
  • Reported: IDL 4.0 — Wed, 14 Sep 2016 21:27 GMT
  • Disposition: Resolved — IDL 4.1
  • Disposition Summary:

    Clarify application rules for annotations

    An annotation can be placed on any IDL constructs or sub-constructs.
    Stating that in the grammar rules complicates dramatically all the rules and creates a dependency issue between building-blocks.
    The proposed solution is therefore:

    1. to remove from the grammar any reference towards where annotations can be placed – cf. rule (202), as it wrongly gave the impression that annotations could only be placed on first-level definitions.
    2. to state more clearly in the text that annotations can be placed on any IDL constructs and sub-constructs.

    (Note that the format for applying annotation remains defined by EBNF rules as it was).

  • Updated: Wed, 5 Dec 2018 16:54 GMT

The IDL4 spec syntax for bitsets departed from the one used in DDS-XTYPES

  • Key: IDL41-5
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    TITLE:

    The IDL4 spec syntax for bitsets departed from the one used in DDS-XTYPES.

    DESCRIPTION:

    In DDS XTYPES a bitset is defined like an enumeration with some extra annotations. For example:

    
    @BitSet @BitBound(16)
    
         enum MyBitSet {
    
           FLAG_0,
    
           FLAG_1,
    
           @Value(7) FLAG_7
    
           @Value(15) FLAG_LAST
    
    };
    
    

    This defined the total number of bits in the bitset (16) as well provided symbolic names for the bits (FLAG_0), ... It also allowed the bit assignment to be defaulted (e.g. FLAG_0, FLAG_1) or explicitly assigned.

    It is unclear how to do this in IDL4.

    On the one hand one could write

    
    struct MyBitSet {
    
        bitset<1> FLAG_0;
    
        bitset<1> FLAG_1;
    
        bitset<1> FLAG_7
    
        bitset<1> FLAG_LAST;
    
    };
    
    

    This would indicate each flag uses one bit. But it would not constrain the size of the overall bitset, nor the bit values for the flags.

    One could also say:

    
    struct MyBitSet {
    
        bitset<1, 16> FLAG_0;
    
        bitset<1, 16> FLAG_1;
    
        bitset<1, 16> FLAG_7
    
        bitset<1, 16> FLAG_LAST;
    
    };
    
    

    According to 7.2.8.6.3.2 the second integer would specify that the representation should use a 16-bit integer. But nowhere it is stated that all these will be reusing the same 16-bit integer...

    Also bitsets can appear inside other structures as in (see 7.2.8.6.3.2):

    
    struct MyStruct {
    
                bitset<1>        foo1;
    
                bitset<3>        foo2;
    
                bitset<4>        foo3;
    
                long                 anotherMember;
    
                bitset<1>        bar1;
    
                bitset<1>        bar2;
    
    };
    
    

    Where it is stated that bitsets that appear sequentially should be put together. This seems non-intuitive and brittle... In fact the spec recommends not to mix bitsets with other types for readability...

    This syntax seems a bit arbitrary and also hard to process by IDL compiler. The XTYPES approach was simpler. If the goal was to avoid "re-purposing" the "enum" then IDL4 could have defined a new keyword, but yet use similar syntax/approach as XTYPES as in:

    
    @bound(16) 
    
    bitset {
    
        @value(0) FLAG_0;
    
        @value(1) FLAG_1;
    
        @value(7) FLAG_7;
    
        @value(15) FLAG_LAST;
    
    };
    
     
    
    // OR
    
    @bound(16) 
    
    bitset {
    
        FLAG_0 = 0;
    
        FLAG_1 = 1;
    
        FLAG_7 = 7;
    
        FLAG_LAST = 15;
    
    };
    
    

    This is less ambiguous as it separates clearly the size of the bitset from the actual flags-names used for each bit. It also allows the user to not bother assigning explicit values to each bit. Finally the syntax is closer to that of enumeration so it is much easier for IDL parsers to handle it.

  • Reported: IDL 4.0 — Wed, 10 Aug 2016 15:15 GMT
  • Disposition: Resolved — IDL 4.1
  • Disposition Summary:

    Redesign of bitsets

    In the previous version of IDL4, bit sets were created to serve two main purposes in a single construct, namely::

    • Bit fields (à la C/C++)
    • Named accesses to individual bits (as in XTypes)

    Rationale for that "all-in-one" approach was to avoid introducing too many new IDL keywords. However, the result was deemed difficult to understand and to implement (notably because a struct had then different meanings and implementation depending if it contains or not bit fields) and not fully compliant with what was designed in XTypes.

    The proposal is thus to separate those two things and to design accordingly two different constructs.
    The consequence is that it introduces 2 new keywords (bitfield and bitmask) in addition to the existing one (bitset), which is not that annoying as they should not collide too often with existing identifiers (and if they do, IDL provides a mechanism to mitigate the collision).

  • Updated: Thu, 6 Apr 2017 13:50 GMT

IDL should support empty structures

  • Key: IDL41-6
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Supporting empty structures is desired to facilitate the mapping from other data-models that may contain them. In addition the type system in XTYPES already supports them but it is not possible to express it in IDL.

    We have found many practical situations where people create empty structures. It may be used these are temporary place holders. Or they can be used as markers for specialized classes that represent different types all inheriting from a common base class.

    In all these cases when going to IDL it becomes necessary to add a dummy member like:

    struct MyEmptyStruct {
        octet __dummy_member;
    };
    

    Note that C and C++ support empty structures. So this should not create problems in the language mappings.

  • Reported: IDL 4.0 — Thu, 11 Aug 2016 07:38 GMT
  • Disposition: Resolved — IDL 4.1
  • Disposition Summary:

    Change <struct_def> in BB Extended Data-types

    In BB Extended Data-types, structure definition is already modified to support single inheritance (cf. rule (195)). Complement that extension with the ability of defining void structures.

  • Updated: Thu, 6 Apr 2017 13:50 GMT

DL 4.0 Grammar Errors - formal/2016-04-02

  • Key: IDL41-3
  • Legacy Issue Number: 19894
  • Status: closed  
  • Source: Vanderbilt University ( Mr. William Otte)
  • Summary:

    We’re trying to implement a simple parser based on a subset of the IDL 4.0 BBs, and we’re coming across a number of oversights/mistakes in the language definition. For example, template module instances are required to end with two semicolons.

    Invalid:
    Typed<FOO> BAR;

    Valid:
    Typed<FOO> BAR;;

    Rule 184 requires a semicolon after a template_module_inst:
    (184) <definition> ::+ <template_module_dcl> ";"

    <template_module_inst> ";"

    Rule 194 defines template_module_inst as ending with a semicolon:
    (190) <template_module_inst> ::= "module" <scoped_name> "<" <actual_parameters> ">" <identifier> ";"

    There were one or two additional ones that I submitted through the OMG issue process, but never received the customary note from Juergen that it had been received. (unless it went to spam).

    I’ll have to dig through my email for specifics of the other, but I believe it was:

    Invalid:

    struct foo

    { int bar; }

    Valid

    struct foo

    { int bar, baz; }

    Invalid:

    struct foo

    { int bar, baz, qux; }

    At the moment, we are proceeding under the assumption that such errors are fixed with the intuitive solution in each case, e.g., correct the grammar to allow similar behavior in such cases to IDL 3.5.

    I’d like to make sure that our internal resolutions are correct before we invest too much time going down this rabbit hole.

  • Reported: IDL 4.0 — Wed, 8 Jun 2016 04:00 GMT
  • Disposition: Resolved — IDL 4.1
  • Disposition Summary:

    Remove the extra ";" from rule (190)

    This is an obvious mistake (the general strategy is that all the ending ";" are specified when adding items to <definition>).
    The solution is just to remove that supernumerary piece at the end of rule (190).

  • Updated: Thu, 6 Apr 2017 13:50 GMT

Unnecessary paragraph in section 7.4.1.4.4.1

  • Key: IDL41-8
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In section 7.4.1.4.4.1 Simple Types, section on Char Types the paragraph that follows is redundant with what is already explained in other sections and moreover does not apply to the section. This causes confusion and therefore it should be removed.

    The ISO Latin-1 (8859-1) character set standard defines the meaning and representation of all possible graphic characters used in IDL (i.e., the space, alphabetic, digit, and graphic characters defined in Table 7-2 on page 15, Table 7-3 on page 16 and Table 7-4 on page 16). The meaning and representation of the null and formatting characters (see Table 7-5 on page 18) is the numerical value of the character as defined in the ASCII (ISO 646) standard. The meaning of all other characters is implementation-dependent.

  • Reported: IDL 4.0 — Wed, 14 Sep 2016 21:24 GMT
  • Disposition: Resolved — IDL 4.1
  • Disposition Summary:

    Suppress the unnecessary paragrap in section 7.4.1.4.4.1.3

    This paragraph overspecifies what is a char. It should be removed.
    Note that there is not such a paragraph for wchar.

  • Updated: Thu, 6 Apr 2017 13:50 GMT

Declarator specification in structures overly strict

  • Key: IDL41-1
  • Status: closed   Implementation work Blocked
  • Source: Vanderbilt University ( William Otte)
  • Summary:

    Consider the following from the standard, which defines a struct:

    ```
    (45) <struct_dcl> ::= <struct_def> | <struct_forward_dcl>
    (46) <struct_def> ::= "struct" <identifier> "

    {" <member>+ "}

    "
    (47) <member> ::= <type_spec> <declarators> ";"
    (67) <declarators> ::= <declarator>

    { "," <declarator> }
    (68) <declarator> ::= <simple_declarator>
    ```

    Note rule 67. As stated, the following is valid:

    ```
    struct Foo { int bar, baz; }
    ```

    But neither of the following:

    ```
    struct Foo { int bar; }

    struct Foo { int bar, bad, qux; }
    ```

    If rule 67 is amended thusly:
    ```
    (67) <declarators> ::= <declarator> { "," <declarator> }

    *
    ```

    then all thee above are valid. Is this intended?

    Also, rules 65 and 124 appear to suffer the same deficiency:

    ```
    (65) <any_declarators> ::= <any_declarator>

    { "," <any_declarator> }

    (124) <context_expr> ::= "context" "(" <string_literal>

    { "," <string_literal> }

    ")"
    ```

  • Reported: IDL 4.0 — Tue, 31 May 2016 13:15 GMT
  • Disposition: Resolved — IDL 4.1
  • Disposition Summary:

    Add the missing '' in the rules 65,67 and 124*

    This is just typos resulting from an unfortunate cut and paste.

    Rules 65, 67 and 124 should be:
    (65) <any_declarators> ::= <any_declarator>

    { "," <any_declarator> }

    *
    (67) <declarators> ::= <declarator>

    { "," <declarator> }

    *
    (124) ‎<context_expr>‎ ‎::=‎ ‎"context" "(" <string_literal>

    { "," <string_literal> }

    * ")"‎

    Nothing else has to be changed in the specification.

  • Updated: Thu, 6 Apr 2017 13:50 GMT

Kleene star missing from rules 65 and 67

  • Key: IDL41-11
  • Status: closed   Implementation work Blocked
  • Source: Georgia Tech Research Institute ( Joshua Anderson)
  • Summary:

    <declarators> is defined as <declarator>

    { "," <declarator>}
    <any_declarators> is defined as <any_declarator> { "," <any_declarator>}
    This requires all declarators to be used in pairs.
    Recommended change
    <declarators> := <declarator> { "," <declarator>}

    *
    <any_declarators> := <any_declarator>

    { "," <any_declarator>}

    *

    This better aligns with IDL 3.5 and likely the intention of the standard

  • Reported: IDL 4.0 — Tue, 27 Sep 2016 16:12 GMT
  • Disposition: Duplicate or Merged — IDL 4.1
  • Disposition Summary:

    Same issue as #1

    Mistakes already reported in issue #1

  • Updated: Thu, 6 Apr 2017 13:50 GMT

Map parameter types too restrictive

  • Key: IDL41-13
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Currently maps are defined to be parameterized only by "simple types". This means that anonymous types cannot be provided even if they are supported in the profile.
    This is not consistent with sequence definition where anonymous types can be used (provided that BB Anoymous Types be part of the profile)
    => In rule (198), <simple_type_spec> should be replaced with <type_spec>

  • Reported: IDL 4.0 — Thu, 29 Sep 2016 08:54 GMT
  • Disposition: Resolved — IDL 4.1
  • Disposition Summary:

    Change <simple_type_spec> to <type_spec> in map definition

    With this modification, maps will accept anonymous types in parameters (provided that BB Anonymous Types is included)
    This is more consistent with sequences (as said in the text).

  • Updated: Thu, 6 Apr 2017 13:50 GMT

Bitmask default size

  • Key: IDL41-17
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Currently the default size of a bitmask is 64.
    32 is actually used much more often and would be a more suitable default value

  • Reported: IDL 4.0 — Thu, 24 Nov 2016 09:45 GMT
  • Disposition: Resolved — IDL 4.1
  • Disposition Summary:

    Set default value of bitmask size to 32

    Amend resolution of issue #5 to set 32 as default value for a bitmask size, instead of 64.

  • Updated: Thu, 6 Apr 2017 13:50 GMT