IDL43 — Mapping int8/uint8 in absence of target language native support

If an implementation wishes to claim support for the "Building Block Extended Data-Types", it must support all of its complements, including the section 7.4.13.4.4 "Integers restricted to holding 8-bits of information".

However, if the targeted programming language does not natively support int8 or uint8 then it is not obvious how the "unsupported" type may be mapped.

For example, the Java language has a native type byte which is signed.
The question then arises how the implementation maps the type uint8.

The implementation could choose to

• Maintain bit size:
  In that case, it would map uint8 to Java byte.
  The question then arises how values exceeding the positive signed maximum (127) are handled.
• Maintain numeric range:
  In that case, it could map uint8 e.g. to Java short (16 bit quantity) or int (32 bit quantity).
  The implementation must then address the interoperability with other languages where uint8 is
  mapped to an 8 bit quantity.
• Use yet a different mapping, for example a holder class (cf. Short, Integer, etc.)

I therefore propose adding the requirement that the implementation shall document its mapping choice:

If the targeted programming language does not natively support int8 or uint8 then an implementation
shall include information about how it maps the types which lack the native language support.