Issue 5682: Insecurity about literals of typedefed enums (ada-rtf)
Source: Airbus Group (Mr. Oliver M. Kellogg, oliver.kellogg(at)airbus.com)
Nature: Uncategorized Issue
Severity: 
Summary: Description:


Given the declarations


 module m_a {
   enum enum_a { value_1, value_2 };
 };
 module m_b {
   typedef m_a::enum_a enum_b;
 };


I believe the following is illegal:


 const m_b::enum_b bconst = m_b::value_2;


Instead, to define such a constant in IDL, one needs to write


 const m_b::enum_b bconst = m_a::value_2;


However, when mapping the typedefed enum to Ada, a derived type is 
created.
The derived type implicitly creates visibility of the enum literals 
in the new scope (in this example, module m_b). 
Furthermore, enum_a and enum_b are not assignment-compatible in Ada.


A clarification should be added to the Ada mapping stating that
all mentions of scope prefixes at enum literals must be converted to 
match the Ada rules.
Thus the above example


 const m_b::enum_b bconst = m_a::value_2;


must be mapped as follows to Ada:


 bconst : constant m_b.enum_b := m_b.value_2;

Resolution: Accept the proposed resolution
Revised Text: Add the following as section 2.3.2:   2.3.2 Mapping of Enumeration Literals of Derived Types
The Ada language makes the enumeration literals of an enumeration type visible at the
point of derivation from a derived type; IDL does not. Because of this, enumeration
literals that appear in constant expressions must be qualified by the package name in
which the type is defined or derived, rather than the package mapped from the qualified
name in IDL. For example, the following IDL definitions:
module m_a {
enum enum_a { value_1, value_2 };
};
module m_b {
typedef m_a::enum_a enum_b;
};
const m_b::enum_b bconst = m_a::value_2;
must be mapped to
bconst : constant m_b.enum_b := m_b.value_2;
Disposition: Resolved
Ada RTF 1.3 Disposition: Resolved
OMG Issue No: 5682
Document
Actions taken:
October 9, 2002: received issue
January 12, 2010: closed issue
Discussion: 

End of Annotations:=====
Sender: oliver.kellogg@sysde.eads.net 
Date: Wed, 09 Oct 2002 17:20:40 +0000 
From: Oliver Kellogg <oliver.kellogg@sysde.eads.net> 
Organization: EADS Deutschland GmbH 
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.9-31 i686) 
X-Accept-Language: en 
To: Juergen Boldt <juergen@omg.org> 
CC: ada-rtf@omg.org 
Subject: Re: testing ada-rtf@omg.org 


Thanks Juergen.
Here is an issue that I wanted to send to ada-rtf in August but 
somehow the mail bounced.


Best regards,
Oliver


--


Subject: 'typedef enum' and its mapping to Ada
Nature: Clarification
Severity: Significant
Summary: Insecurity about literals of typedefed enums


Description:


Given the declarations


 module m_a {
   enum enum_a { value_1, value_2 };
 };
 module m_b {
   typedef m_a::enum_a enum_b;
 };


I believe the following is illegal:


 const m_b::enum_b bconst = m_b::value_2;


Instead, to define such a constant in IDL, one needs to write


 const m_b::enum_b bconst = m_a::value_2;


However, when mapping the typedefed enum to Ada, a derived type is 
created.
The derived type implicitly creates visibility of the enum literals 
in the new scope (in this example, module m_b). 
Furthermore, enum_a and enum_b are not assignment-compatible in Ada.


A clarification should be added to the Ada mapping stating that
all mentions of scope prefixes at enum literals must be converted to 
match the Ada rules.
Thus the above example


 const m_b::enum_b bconst = m_a::value_2;


must be mapped as follows to Ada:


 bconst : constant m_b.enum_b := m_b.value_2;



--
Oliver M. Kellogg
Naval and Ground Operations (NGO2)
Systems and Defence Electronics
EADS Deutschland GmbH
D-89070 Ulm, Germany
e-mail: oliver.kellogg@sysde.eads.net
tel.: (+49) 731 392-7138



To: ada-rtf@omg.org
Cc: Nick Roberts <nickroberts@callnetuk.com>
Subject: Proposed Resolution for Issue 5682
From: Victor Giddings <victor.giddings@mail.ois.com>
Date: Wed, 30 Apr 2008 11:16:47 -0400
X-Mailer: Apple Mail (2.753)


OMG Issue No:  5682

Title: Insecurity about Literals of typedefed enums

Source:

Daimler AG 

Mr. Oliver M. Kellogg, oliver.kellogg@eads.com Oliver.Kellogg@t-online.de

Summary:

Given the declarations


 module m_a {
   enum enum_a { value_1, value_2 };
 };
 module m_b {
   typedef m_a::enum_a enum_b;
 };


I believe the following is illegal:


 const m_b::enum_b bconst = m_b::value_2;


Instead, to define such a constant in IDL, one needs to write


 const m_b::enum_b bconst = m_a::value_2;


However, when mapping the typedefed enum to Ada, a derived type is created. The derived type implicitly creates visibility of the enum literals in the new scope (in this example, module m_b). Furthermore, enum_a and enum_b are not assignment-compatible in Ada.


A clarification should be added to the Ada mapping stating that all mentions of scope prefixes at enum literals must be converted to match the Ada rules.
Thus the above example:


 const m_b::enum_b bconst = m_a::value_2;


must be mapped as follows to Ada:


 bconst : constant m_b.enum_b := m_b.value_2;



Resolution:

Accept the proposed resolution.

Revised Text:

Add the following as section 2.3.2:



2.3.2 Mapping of Enumeration Literals of Derived Types

The Ada language makes the enumeration literals of an enumeration type visible at the point of derivation from a derived type; IDL does not. Because of this, enumeration literals that appear in constant expressions must be qualified by the package name in which the type is defined or derived, rather than the package mapped from the qualified name in IDL. For example, the following IDL definitions:


 module m_a {
   enum enum_a { value_1, value_2 };
 };
 module m_b {
   typedef m_a::enum_a enum_b;
 };
 const m_b::enum_b bconst = m_a::value_2;


must be mapped to 


 bconst : constant m_b.enum_b := m_b.value_2;



Disposition: Resolved





Victor Giddings  Objective Interface Systems
victor.giddings@mail.ois.com






fax:  (+49) 731 392-5826