Version 1.10 of ai12s/ai12-0135-1.txt
!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 1-2012 15-02-26
!status WG9 Approved 15-06-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)
Insert after the paragraph:
- Convention L has been specified for T, and T is eligible for
convention L; that is:
the new paragraph:
- 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;
!corrigendum B.1(41/3)
Replace the paragraph:
For each supported convention L other than Intrinsic, an implementation
should support specifying the Import and Export aspects for objects of
L-compatible types and for subprograms, and the Convention aspect for
L-eligible types and for subprograms, presuming the other language has
corresponding features. Specifying the Convention aspect need not be supported
for scalar types.
by:
For each supported convention L other than Intrinsic, an implementation
should support specifying the Import and Export aspects for objects of
L-compatible types and for subprograms, and the Convention aspect for
L-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–1.
!corrigendum B.3(65)
Insert after the paragraph:
- An Ada function corresponds to a non-void C function.
the new paragraph:
- 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.
!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.]
***************************************************************
Questions? Ask the ACAA Technical Agent