!standard B.1(14/3) 15-03-03 AI12-0135-1/05 !standard B.1(41/3) !standard B.3(65) !class binding interpretation 15-02-26 !status Corrigendum 2015 15-02-26 !status ARG Approved 10-0-0 15-02-26 !status work item 14-10-09 !status work item 15-01-26 !status received 14-08-18 !priority Low !difficulty Easy !subject Enumeration types should be eligible for convention C !summary Enumeration types are eligible for all languages that interface with Ada, subject to a limitation on their range of internal codes. More detailed requirements exist for mapping Ada enumeration types to C/C++ enum types. !question It is convenient to map C enumeration types to Ada enumeration types. However, enumeration types are not eligible for convention C. An implementation can allow enumeration types to have convention C via B.1(20), but this depends on the implementer, and thus impacts portability. Should Ada provide this capability? (Yes.) !recommendation Suggest support for interfacing with Ada enumeration types, so long as the number of internal codes is within some implementation defined range. Impose more detailed requirements for C/C++. (That is, include it in the Implementation Advice at the end of B.1.) !wording Add after B.1(14/3): * T is an enumeration type such that all internal codes (whether assigned by default or explicitly) are within an implementation-defined range that includes at least the range of values 0 .. 2**15-1; Modify the last sentence of B.1(41/3): Specifying the Convention aspect need not be supported for scalar types{, other than enumeration types whose internal codes fall within the range 0 .. 2**15-1}. Add after B.3(65): * An Ada enumeration type corresponds to a C enumeration type with corresponding enumeration literals having the same internal codes, provided the internal codes fall within the range of the C int type. !discussion For some reason, B.1(12-21/3) do not require any scalar types to be eligible for convention *L*. Perhaps that is because using the scalar types in the various interface packages is preferred. That's not sensible in the case of enumeration types, however. Many languages have some type similar to Ada's enumerations, and direct mapping should be supported if possible. Therefore we have chosen to require support for enumeration types in all languages that interface with Ada, subject to an implementation-defined limitation on the range of internal codes. We set the minimum supported range to be the non-negative values of the 16-bit signed integer type, since that is known to be supportable by C compilers, and is presumed to be supportable by any other language which supports integer types. For C, we require that an Ada enumeration type maps to a C enumeration type, provided the internal codes fall within the range of "int", as that is the C requirement. C++ is more flexible, but there seems no reason to specify additional requirements for C++ interfacing. !corrigendum B.1(14/3) @dinsa @xbullet has been specified for T, and T is @i @i; that is:> @dinst @xinbull !corrigendum B.1(41/3) @drepl For each supported convention @i other than Intrinsic, an implementation should support specifying the Import and Export aspects for objects of @i-compatible types and for subprograms, and the Convention aspect for @i-eligible types and for subprograms, presuming the other language has corresponding features. Specifying the Convention aspect need not be supported for scalar types. @dby For each supported convention @i other than Intrinsic, an implementation should support specifying the Import and Export aspects for objects of @i-compatible types and for subprograms, and the Convention aspect for @i-eligible types and for subprograms, presuming the other language has corresponding features. Specifying the Convention aspect need not be supported for scalar types, other than enumeration types whose internal codes fall within the range 0 .. 2**15@endash1. !corrigendum B.3(65) @dinsa @xbullet @dinst @xbullet !ASIS No impact. !ACATS test An ACATS test that convention C is accepted and works with some C code is possible. !appendix !topic Enumeration types should be eligible for convention C !reference Ada 2012 B.1(14/3) !from Victor Porton 80-07-21 !keywords convention, C, eligible, enumeration type !discussion Enumeration types should be eligible for convention C. There is one difficult thing here: An enumeration type may be declared as having convention C before its representation values are specified. So to work around of this, convention C should become effective only after enumeration representation clause is met or when it is too late. (Define "too late" precisely. By the way I do not see in the RM when it is too late for a enumeration representation clause. Should we start and other correction procedure to specify when enumeration representation clause is disallowed, because the enumeration values are already used?) Note that in GNAT enumeration types are already eligible for convention C. **************************************************************** From: Erhard Ploedereder Sent: Wednesday, January 28, 2015 1:25 PM I had a mailer problem, so this message arrives late or really late for the meeting. [Editor's note: It arrived in my inbox an hour and twenty minutes after we adjourned the meeting.] A summary of my positions on some of the issues... AI-135 (enum support in interfaces): very good idea. I would prefer if a rep.clause for all values would be mandatory to prevent users believing in magic id comparison support. They ought to be rare enough to make the extra effort not much of a burden. Else, a User Note that if the C-enumeration does no start at 0 and has contiguous values, a rep.clause is needed. [Issues associated with other AIs removed - Editor.] ***************************************************************