1. OMG Mailing List
  2. Interface Definition Language (IDL) 4.2 RTF

Open Issues

  • Issues not resolved
  • Name: idl-rtf42
  • Issues Count: 3

Issues Descriptions

IDL Lacks Support for 8-bit Signed/Unsigned Integers

  • Key: IDL42-2
  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    As of version 4.1, IDL lacks explicit support for 8-bit signed/unsigned integers. While, there are two data type with 1-byte size, these are not suitable for encoding 8-bit integers:

    • char => 8-bit quantity that:
      • encodes a single-byte character from any byte-oriented code set, or
      • in an array, encodes a multi-byte character from a multi-byte code set
    • octet => opaque 8-bit. guaranteed not to undergo any change by the middleware.

    Unfortunately, reference programming languages don't have consistent behavior:

    • Java: byte => signed 8-bit
    • C#
      • byte => unsigned 8-bit
      • sbyte => signed 8 bit
    • C (C90 and later)
    • C++
      • char => recommended for chars only. Allowed for numbers but unspecified sign
      • signed char => signed 8-bit number
      • unsigned char => unsigned 8-bit number

    Other dialects of IDL provide support for 8-bit signed/unsigned integers as follows:

    • MIDL (Microsoft's IDL)
      • Introduces the small keyword to represent 8-bit integers (see MIDL documentation). Additionally, it uses the hyper keyword to represent 64-bit integers (i.e., a long long in OMG IDL).
      • The integer types in MIDL are:
        • [unsigned] small (8-bit integer)
        • [unsigned] short (16-bit integer)
        • [unsigned] long (32-bit integer)
        • [unsigned] hyper (64-bit integer)
      • This IDL dialect introduces also the signed keyword and therefore numeric values can be marked as signed or unsigned (if unspecified they default to signed).
      • Web IDL
        • Introduces byte keyword to represent a signed 8-bit integer and treats octets as an unsigned 8-bit integer (see documentation).
        • The integer types in Web IDL are:
          • byte (signed 8-bit integer)
          • octet (unsigned 8-bit integer)
          • [unsigned] short (16-bit integer)
          • [unsigned] long (32-bit integer)
          • [unsigned] long long (64-bit integer)
    • XPIDL
  • Reported: IDL 4.1 — Wed, 26 Jul 2017 14:28 GMT
  • Updated: Wed, 26 Jul 2017 21:35 GMT
  • Attachments:

Missing and inconsistently named annotations

  • Key: IDL42-3
  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Extensibility Annotation

    Section 8.3.1.6 defines the @extensibility annotation as follows:

    @annotation extensibility {
        enum ExtensibilityKind {
            FINAL,
            APPEND,
            MUTABLE
        };
        ExtensibililtyKind value;
    };
    

    However, section 7.2.3 of DDS-XTYPES specifies that the types of extensibility and mutability are the following:

    • FINAL
    • APPENDABLE
    • MUTABLE

    For consistency, the IDL specification should use "APPENDABLE" instead of "APPEND".

    Shortcut Annotations

    In Section 8.3.1 the IDL specification defines the annotations @final as a shorcut for @extensibility(FINAL) (Section 8.3.1.7) and @extensible as a shortcut for and @extensibility(EXTENSIBLE) (Section 8.3.1.8).

    For consistency, the IDL specification should introduce @appendable as a shortcut for @extensibility(APPENDABLE).

    Default Literal Annotation

    DDS-XTYPES Section 7.3.1.2.1.10 (Default Literal for Enumeration) defines the annotation @default_literal as:

    @annotation default_literal {};

    This is a general purpose annotation that marks an element of an enumeration as the default one for that enumeration.

    For consistency with similar generic annotations it should be added to IDL section 8.3.2 (Group of Annotations Data Modeling)

  • Reported: IDL 4.1 — Wed, 26 Jul 2017 15:39 GMT
  • Updated: Wed, 26 Jul 2017 21:22 GMT

Rule 174 requires space after opening curly brace

  • Key: IDL42-1
  • Status: open  
  • Source: Vanderbilt University (ISIS) ( Spencer Crosswy)
  • Summary:

    Rule 174 requires a space after the open brace:
    (174) > <porttype_def ::= "porttype" <identifier> "

    { " <port_body> "}

    "

    This has the following consequence:
    Valid:
    porttype TESTPORT

    { provides FOO BAR; }

    ;

    Invalid:
    porttype TESTPORT

    {provides FOO BAR; }

    ;

    I expect this was just an oversight, because it's the only instance in the grammar that requires a space after an opening curly brace.

  • Reported: IDL 4.0 — Wed, 12 Apr 2017 15:23 GMT
  • Updated: Thu, 22 Jun 2017 17:22 GMT