Go to the first, previous, next, last section, table of contents.

Implementation Advice

The main text of the Ada 95 Reference Manual describes the required behavior of all Ada 95 compilers, and the GNAT compiler conforms to these requirements.

In addition, there are sections throughout the Ada 95 reference manual headed by the phrase "implementation advice". These sections are not normative, i.e. they do not specify requirements that all compilers must follow. Rather they provide advice on generally desirable behavior. You may wonder why they are not requirements. The most typical answer is that they describe behavior that seems generally desirable, but cannot be provided on all systems, or which may be undesirable on some systems.

As far as practical, GNAT follows the implementation advice sections in the Ada 95 Reference Manual. This chapter contains a table giving the reference manual section number, paragraph number and several keywords for each advice. Each entry consists of the text of the advice followed by the GNAT interpretation of this advice. Most often, this simply says "followed", which means that GNAT follows the advice. However, in a number of cases, GNAT deliberately deviates from this advice, in which case the text describes what GNAT does and why.

1.1.3(20): Error Detection
If an implementation detects the use of an unsupported Specialized Needs Annex feature at run time, it should raise Program_Error if feasible. Not relevant. All specialized needs annex features are either supported, or diagnosed at compile time.
1.1.3(31): Child Units
If an implementation wishes to provide implementation-defined extensions to the functionality of a language-defined library unit, it should normally do so by adding children to the library unit. Followed.
1.1.5(12): Bounded Errors
If an implementation detects a bounded error or erroneous execution, it should raise Program_Error. Followed in all cases in which the implementation detects a bounded error or erroneous execution. Not all such situations are detected at runtime.
2.8(16): Pragmas
Normally, implementation-defined pragmas should have no semantic effect for error-free programs; that is, if the implementation-defined pragmas are removed from a working program, the program should still be legal, and should still have the same semantics. The following implementation defined pragmas are exceptions to this rule:
Abort_Defer
Affects semantics
Ada_83
Affects legality
Assert
Affects semantics
CPP_Class
Affects semantics
CPP_Constructor
Affects semantics
CPP_Destructor
Affects semantics
CPP_Virtual
Affects semantics
CPP_Vtable
Affects semantics
Debug
Affects semantics
Interface_Name
Affects semantics
Machine_Attribute
Affects semantics
Unimplemented_Unit
Affects legality
Unchecked_Union
Affects semantics
In each of the above cases, it is essential to the purpose of the pragma that this advice not be followed. For details see the separate section on implementation defined pragmas.
2.8(17-19): Pragmas
Normally, an implementation should not define pragmas that can make an illegal program legal, except as follows: A pragma used to complete a declaration, such as a pragma Import; A pragma used to configure the environment by adding, removing, or replacing library_items. See response to paragraph 16 of this same section.
3.5.2(5): Alternative Character Sets
If an implementation supports a mode with alternative interpretations for Character and Wide_Character, the set of graphic characters of Character should nevertheless remain a proper subset of the set of graphic characters of Wide_Character. Any character set "localizations" should be reflected in the results of the subprograms defined in the language-defined package Characters.Handling (see A.3) available in such a mode. In a mode with an alternative interpretation of Character, the implementation should also support a corresponding change in what is a legal identifier_letter. Not all wide character modes follow this advice, in particular the JIS and IEC modes reflect standard usage in Japan, and in these encoding, the upper half of the Latin-1 set is not part of the wide-character subset, since the most significant bit is used for wide character encoding. However, this only applies to the external forms. Internally there is no such restriction.
3.5.4(28): Integer Types
An implementation should support Long_Integer in addition to Integer if the target machine supports 32-bit (or longer) arithmetic. No other named integer subtypes are recommended for package Standard. Instead, appropriate named integer subtypes should be provided in the library package Interfaces (see B.2). Long_Integer is supported. Other standard integer types are supported so this advice is not fully followed. These types are supported for convenient interface to C, and so that all hardware types of the machine are easily available.
3.5.4(29): Integer Types
An implementation for a two's complement machine should support modular types with a binary modulus up to System.Max_Int*2+2. An implementation should support a non-binary modules up to Integer'Last. Followed.
3.5.5(8): Enumeration Values
For the evaluation of a call on S'Pos for an enumeration subtype, if the value of the operand does not correspond to the internal code for any enumeration literal of its type (perhaps due to an un-initialized variable), then the implementation should raise Program_Error. This is particularly important for enumeration types with noncontiguous internal codes specified by an enumeration_representation_clause. Followed.
3.5.7(17): Float Types
An implementation should support Long_Float in addition to Float if the target machine supports 11 or more digits of precision. No other named floating point subtypes are recommended for package Standard. Instead, appropriate named floating point subtypes should be provided in the library package Interfaces (see B.2). Short_Float and Long_Long_Float are also provided. The former provides improved compatibility with other implementations supporting this type. The latter corresponds to the highest precision floating-point type supported by the hardware. On most machines, this will be the same as Long_Float, but on some machines, it will correspond to the IEEE extended form. On the Silicon Graphics processors, which do not support IEEE extended form, Long_Long_Float is the same as Long_Float.
3.6.2(11): Multidimensional Arrays
An implementation should normally represent multidimensional arrays in row-major order, consistent with the notation used for multidimensional array aggregates (see 4.3.3). However, if a pragma Convention (Fortran, ...) applies to a multidimensional array type, then column-major order should be used instead (see B.5, "Interfacing with Fortran"). Followed.
9.6(30-31): Duration'Small
Whenever possible in an implementation, the value of Duration'Small should be no greater than 100 microseconds. Followed. (Duration'Small = 10**(-9)). The time base for delay_relative_statements should be monotonic; it need not be the same time base as used for Calendar.Clock. Followed.
10.2.1(12): Consistent Representation
In an implementation, a type declared in a pre-elaborated package should have the same representation in every elaboration of a given version of the package, whether the elaborations occur in distinct executions of the same program, or in executions of distinct programs or partitions that include the given version. Followed, except in the case of tagged types. Tagged types involve implicit pointers to a local copy of a dispatch table, and these pointers have representations which thus depend on a particular elaboration of the package. It is not easy to see how it would be possible to follow this advice without severely impacting efficiency of execution.
11.4.1(19): Exception Information
Exception_Message by default and Exception_Information should produce information useful for debugging. Exception_Message should be short, about one line. Exception_Information can be long. Exception_Message should not include the Exception_Name. Exception_Information should include both the Exception_Name and the Exception_Message. Followed. For each exception that doesn't have a specified Exception_Message, the compiler generates one containing the location of the raise statement. This location has the form "file:line", where file is the short file name (without path information) and line is the line number in the file. Note that in the case of the Zero Cost Exception mechanism, these messages become redundant with the Exception_Information that contains a full backtrace of the calling sequence, so they are disabled. To disable explicitly the generation of the source location message, use the Pragma Discard_Names.
11.5(28): Suppression of Checks
The implementation should minimize the code executed for checks that have been suppressed. Followed.
13.1 (21-24): Representation Clauses
The recommended level of support for all representation items is qualified as follows: An implementation need not support representation items containing non-static expressions, except that an implementation should support a representation item for a given entity if each non-static expression in the representation item is a name that statically denotes a constant declared before the entity. Followed. GNAT does not support non-static expressions in representation clauses unless they are constants declared before the entity. For example: 
     X : typ;
     for X'Address use To_address (16#2000#);
will be rejected, since the To_Address expression is non-static. Instead write: 
     X_Address : constant Address : = 
     To_Address    ((16#2000#); 
     X : typ;
     for X'Address use X_Address;
An implementation need not support a specification for the Size for a given composite subtype, nor the size or storage place for an object (including a component) of a given composite subtype, unless the constraints on the subtype and its composite subcomponents (if any) are all static constraints. Followed. Size Clauses are not permitted on non-static components, as described above. An aliased component, or a component whose type is by-reference, should always be allocated at an addressable location. Followed.
13.2(6-8): Packed Types
If a type is packed, then the implementation should try to minimize storage allocated to objects of the type, possibly at the expense of speed of accessing components, subject to reasonable complexity in addressing calculations. The recommended level of support pragma Pack is: For a packed record type, the components should be packed as tightly as possible subject to the Sizes of the component subtypes, and subject to any record_representation_clause that applies to the type; the implementation may, but need not, reorder components or cross aligned word boundaries to improve the packing. A component whose Size is greater than the word size may be allocated an integral number of words. Followed. Tight packing of arrays is supported for all component sizes up to 32-bits, which is the word size on typical implementations of GNAT. An implementation should support Address clauses for imported subprograms. Followed.
13.3(14-19): Address Clauses
For an array X, X'Address should point at the first component of the array, and not at the array bounds. Followed. The recommended level of support for the Address attribute is: X'Address should produce a useful result if X is an object that is aliased or of a by-reference type, or is an entity whose Address has been specified. Followed. A valid address will be produced even if none of those conditions have been met. If necessary, the object is forced into memory to ensure the address is valid. An implementation should support Address clauses for imported subprograms. Followed. Objects (including subcomponents) that are aliased or of a by-reference type should be allocated on storage element boundaries. Followed. If the Address of an object is specified, or it is imported or exported, then the implementation should not perform optimizations based on assumptions of no aliases. Followed.
13.3(29-35): Alignment Clauses
The recommended level of support for the Alignment attribute for subtypes is: An implementation should support specified Alignments that are factors and multiples of the number of storage elements per word, subject to the following: Followed. An implementation need not support specified Alignments for combinations of Sizes and Alignments that cannot be easily loaded and stored by available machine instructions. Followed. An implementation need not support specified Alignments that are greater than the maximum Alignment the implementation ever returns by default. Followed. The recommended level of support for the Alignment attribute for objects is: Same as above, for subtypes, but in addition: Followed. For stand-alone library-level objects of statically constrained subtypes, the implementation should support all Alignments supported by the target linker. For example, page alignment is likely to be supported for such objects, but not for subtypes. Followed.
13.3(42-43): Size Clauses
The recommended level of support for the Size attribute of objects is: A Size clause should be supported for an object if the specified Size is at least as large as its subtype's Size, and corresponds to a size in storage elements that is a multiple of the object's Alignment (if the Alignment is nonzero). Followed.
13.3(50-56): Size Clauses
If the Size of a subtype is specified, and allows for efficient independent addressability (see 9.10) on the target architecture, then the Size of the following objects of the subtype should equal the Size of the subtype: Aliased objects (including components). Followed. Size clause on a composite subtype should not affect the internal layout of components. Followed. The recommended level of support for the Size attribute of subtypes is: The Size (if not specified) of a static discrete or fixed point subtype should be the number of bits needed to represent each value belonging to the subtype using an unbiased representation, leaving space for a sign bit only if the subtype contains negative values. If such a subtype is a first subtype, then an implementation should support a specified Size for it that reflects this representation. Followed. For a subtype implemented with levels of indirection, the Size should include the size of the pointers, but not the size of what they point at. Followed.
13.3(71-73): Component Size Clauses
The recommended level of support for the Component_Size attribute is: pe: Aliased objects (including components). Followeter contains a table giving the reference manual section number, paragraph number and several keywords for each advice. Each entry consists of the text of the advice followed by the GNAT interpretation of this advice. Most often, this simply says "followed", which means that GNAT follows the advice. However, in a number of cases, GNAT deliberately deviates from this advice, in which case the text describes what GNAT does and why.
1.1.3(20): Error Detection
If an implementation detects the use of an unsupported Specialized Needs Annex feature at run time, it should raise Program_Error if feasible. Not relevant. All specialized needs annex features are either supported, or diagnosed at compile time.
1.1.3(31): Child Units
If an implementation wishes to provide implementation-defined extensions to the functionality of a language-defined library unit, it should normally do so by adding children to the library unit. Followed.
1.1.5(12): Bounded Errors
If an implementation detects a bounded error or erroneous execution, it should raise Program_Error. Followed in all cases in which the implementation detects a bounded error or erroneous execution. Not all such situations are detected at runtime.
2.8(16): Pragmas
Normally, implementation-defined pragmas should have no semantic effect for error-free programs; that is, if the implementation-defined pragmas are removed from a working program, the program should still be legal, and should still have the same semantics. The following implementation defined pragmas are exceptions to this rule:
Abort_Defer
Affects semantics
Ada_83
Affects legality
Assert
Affects semantics
CPP_Class
Affects semantics
CPP_Constructor
Affects semantics
CPP_Destructor
Affects semantics
CPP_Virtual
Affects semantics
CPP_Vtable
Affects semantics
Debug
Affects semantics
Interface_Name
Affects semantics
Machine_Attribute
Affects semantics
Unimplemented_Unit
Affects legality
Unchecked_Union
Affects semantics
In each of the above cases, it is essential to the purpose of the pragma that this advice not be followed. For details see the separate section on implementation defined pragmas.
2.8(17-19): Pragmas
Normally, an implementation should not define pragmas that can make an illegal program legal, except as follows: A pragma used to complete a declaration, such as a pragma Import; A pragma used to configure the environment by adding, removing, or replacing library_items. See response to paragraph 16 of this same section.
3.5.2(5): Alternative Character Sets
If an implementation supports a mode with alternative interpretations for Character and Wide_Character, the set of graphic characters of Character should nevertheless remain a proper subset of the set of graphic characters of Wide_Character. Any character set "localizations" should be reflected in the results of the subprograms defined in the language-defined package Characters.Handling (see A.3) available in such a mode. In a mode with an alternative interpretation of Character, the implementation should also support a corresponding change in what is a legal identifier_letter. Not all wide character modes follow this advice, in particular the JIS and IEC modes reflect standard usage in Japan, and in these encoding, the upper half of the Latin-1 set is not part of the wide-character subset, since the most significant bit is used for wide character encoding. However, this only applies to the external forms. Internally there is no such restriction.
3.5.4(28): Integer Types
An implementation should support Long_Integer in addition to Integer if the target machine supports 32-bit (or longer) arithmetic. No other named integer subtypes are recommended for package Standard. Instead, appropriate named integer subtypes should be provided in the library package Interfaces (see B.2). Long_Integer is supported. Other standard integer types are supported so this advice is not fully followed. These types are supported for convenient interface to C, and so that all hardware types of the machine are easily available.
3.5.4(29): Integer Types
An implementation for a two's complement machine should support modular types with a binary modulus up to System.Max_Int*2+2. An implementation should support a non-binary modules up to Integer'Last. Followed.
3.5.5(8): Enumeration Values
For the evaluation of a call on S'Pos for an enumeration subtype, if the value of the operand does not correspond to the internal code for any enumeration literal of its type (perhaps due to an un-initialized variable), then the implementation should raise Program_Error. This is particularly important for enumeration types with noncontiguous internal codes specified by an enumeration_representation_clause. Followed.
3.5.7(17): Float Types
An implementation should support Long_Float in addition to Float if the target machine supports 11 or more digits of precision. No other named floating point subtypes are recommended for package Standard. Instead, appropriate named floating point subtypes should be provided in the library package Interfaces (see B.2). Short_Float and Long_Long_Float are also provided. The former provides improved compatibility with other implementations supporting this type. The latter corresponds to the highest precision floating-point type supported by the hardware. On most machines, this will be the same as Long_Float, but on some machines, it will correspond to the IEEE extended form. On the Silicon Graphics processors, which do not support IEEE extended form, Long_Long_Float is the same as Long_Float.
3.6.2(11): Multidimensional Arrays
An implementation should normally represent multidimensional arrays in row-major order, consistent with the notation used for multidimensional array aggregates (see 4.3.3). However, if a pragma Convention (Fortran, ...) applies to a multidimensional array type, then column-major order should be used instead (see B.5, "Interfacing with Fortran"). Followed.
9.6(30-31): Duration'Small
Whenever possible in an implementation, the value of Duration'Small should be no greater than 100 microseconds. Followed. (Duration'Small = 10**(-9)). The time base for delay_relative_statements should be monotonic; it need not be the same time base as used for Calendar.Clock. Followed.
10.2.1(12): Consistent Representation
In an implementation, a type declared in a pre-elaborated package should have the same representation in every elaboration of a given version of the package, whether the elaborations occur in distinct executions of the same program, or in executions of distinct programs or partitions that include the given version. Followed, except in the case of tagged types. Tagged types involve implicit pointers to a local copy of a dispatch table, and these pointers have representations which thus depend on a particular elaboration of the package. It is not easy to see how it would be possible to follow this advice without severely impacting efficiency of execution.
11.4.1(19): Exception Information
Exception_Message by default and Exception_Information should produce information useful for debugging. Exception_Message should be short, about one line. Exception_Information can be long. Exception_Message should not include the Exception_Name. Exception_Information should include both the Exception_Name and the Exception_Message. Followed. For each exception that doesn't have a specified Exception_Message, the compiler generates one containing the location of the raise statement. This location has the form "file:line", where file is the short file name (without path information) and line is the line number in the file. Note that in the case of the Zero Cost Exception mechanism, these messages become redundant with the Exception_Information that contains a full backtrace of the calling sequence, so they are disabled. To disable explicitly the generation of the source location message, use the Pragma Discard_Names.
11.5(28): Suppression of Checks
The implementation should minimize the code executed for checks that have been suppressed. Followed.
13.1 (21-24): Representation Clauses
The recommended level of support for all representation items is qualified as follows: An implementation need not support representation items containing non-static expressions, except that an implementation should support a representation item for a given entity if each non-static expression in the representation item is a name that statically denotes a constant declared before the entity. Followed. GNAT does not support non-static expressions in representation clauses unless they are constants declared before the entity. For example: 
     X : typ;
     for X'Address use To_address (16#2000#);
will be rejected, since the To_Address expression is non-static. Instead write: 
     X_Address : constant Address : = 
     To_Address    ((16#2000#); 
     X : typ;
     for X'Address use X_Address;
An implementation need not support a specification for the Size for a given composite subtype, nor the size or storage place for an object (including a component) of a given composite subtype, unless the constraints on the subtype and its composite subcomponents (if any) are all static constraints. Followed. Size Clauses are not permitted on non-static components, as described above. An aliased component, or a component whose type is by-reference, should always be allocated at an addressable location. Followed.
13.2(6-8): Packed Types
If a type is packed, then the implementation should try to minimize storage allocated to objects of the type, possibly at the expense of speed of accessing components, subject to reasonable complexity in addressing calculations. The recommended level of support pragma Pack is: For a packed record type, the components should be packed as tightly as possible subject to the Sizes of the component subtypes, and subject to any record_representation_clause that applies to the type; the implementation may, but need not, reorder components or cross aligned word boundaries to improve the packing. A component whose Size is greater than the word size may be allocated an integral number of words. Followed. Tight packing of arrays is supported for all component sizes up to 32-bits, which is the word size on typical implementations of GNAT. An implementation should support Address clauses for imported subprograms. Followed.
13.3(14-19): Address Clauses
For an array X, X'Address should point at the first component of the array, and not at the array bounds. Followed. The recommended level of support for the Address attribute is: X'Address should produce a useful result if X is an object that is aliased or of a by-reference type, or is an entity whose Address has been specified. Followed. A valid address will be produced even if none of those conditions have been met. If necessary, the object is forced into memory to ensure the address is valid. An implementation should support Address clauses for imported subprograms. Followed. Objects (including subcomponents) that are aliased or of a by-reference type should be allocated on storage element boundaries. Followed. If the Address of an object is specified, or it is imported or exported, then the implementation should not perform optimizations based on assumptions of no aliases. Followed.
13.3(29-35): Alignment Clauses
The recommended level of support for the Alignment attribute for subtypes is: An implementation should support specified Alignments that are factors and multiples of the number of storage elements per word, subject to the following: Followed. An implementation need not support specified Alignments for combinations of Sizes and Alignments that cannot be easily loaded and stored by available machine instructions. Followed. An implementation need not support specified Alignments that are greater than the maximum Alignment the implementation ever returns by default. Followed. The recommended level of support for the Alignment attribute for objects is: Same as above, for subtypes, but in addition: Followed. For stand-alone library-level objects of statically constrained subtypes, the implementation should support all Alignments supported by the target linker. For example, page alignment is likely to be supported for such objects, but not for subtypes. Followed.
13.3(42-43): Size Clauses
The recommended level of support for the Size attribute of objects is: A Size clause should be supported for an object if the specified Size is at least as large as its subtype's Size, and corresponds to a size in storage elements that is a multiple of the object's Alignment (if the Alignment is nonzero). Followed.
13.3(50-56): Size Clauses
If the Size of a subtype is specified, and allows for efficient independent addressability (see 9.10) on the target architecture, then the Size of the following objects of the subtype should equal the Size of the subtype: Aliased objects (including components). Followed. Size clause on a composite subtype should not affect the internal layout of components. Followed. The recommended level of support for the Size attribute of subtypes is: The Size (if not specified) of a static discrete or fixed point subtype should be the number of bits needed to represent each value belonging to the subtype using an unbiased representation, leaving space for a sign bit only if the subtype contains negative values. If such a subtype is a first subtype, then an implementation should support a specified Size for it that reflects this representation. Followed. For a subtype implemented with levels of indirection, the Size should include the size of the pointers, but not the size of what they point at. Followed.
13.3(71-73): Component Size Clauses
The recommended level of support for the Component_Size attribute is: pe: Aliased objects (including components). Followeter contains a table giving the reference manual section number, paragraph number and several keywords for each advice. Each entry consists of the text of the advice followed by the GNAT interpretation of this advice. Most often, this simply says "followed", which means that GNAT follows the advice. However, in a number of cases, GNAT deliberately deviates from this advice, in which case the text describes what GNAT does and why.
1.1.3(20): Error Detection
If an implementation detects the use of an unsupported Specialized Needs Annex feature at run time, it should raise Program_Error if feasible. Not relevant. All specialized needs annex features are either supported, or diagnosed at compile time.
1.1.3(31): Child Units
If an implementation wishes to provide implementation-defined extensions to the functionality of a language-defined library unit, it should normally do so by adding children to the library unit. Followed.
1.1.5(12): Bounded Errors
If an implementation detects a bounded error or erroneous execution, it should raise Program_Error. Followed in all cases in which the implementation detects a bounded error or erroneous execution. Not all such situations are detected at runtime.
2.8(16): Pragmas
Normally, implementation-defined pragmas should have no semantic effect for error-free programs; that is, if the implementation-defined pragmas are removed from a working program, the program should still be legal, and should still have the same semantics. The following implementation defined pragmas are exceptions to this rule:
Abort_Defer
Affects semantics
Ada_83
Affects legality
Assert
Affects semantics
CPP_Class
Affects semantics
CPP_Constructor
Affects semantics
CPP_Destructor
Affects semantics
CPP_Virtual
Affects semantics
CPP_Vtable
Affects semantics
Debug
Affects semantics
Interface_Name
Affects semantics
Machine_Attribute
Affects semantics
Unimplemented_Unit
Affects legality
Unchecked_Union
Affects semantics
In each of the above cases, it is essential to the purpose of the pragma that this advice not be followed. For details see the separate section on implementation defined pragmas.
2.8(17-19): Pragmas
Normally, an implementation should not define pragmas that can make an illegal program legal, except as follows: A pragma used to complete a declaration, such as a pragma Import; A pragma used to configure the environment by adding, removing, or replacing library_items. See response to paragraph 16 of this same section.
3.5.2(5): Alternative Character Sets
If an implementation supports a mode with alternative interpretations for Character and Wide_Character, the set of graphic characters of Character should nevertheless remain a proper subset of the set of graphic characters of Wide_Character. Any character set "localizations" should be reflected in the results of the subprograms defined in the language-defined package Characters.Handling (see A.3) available in such a mode. In a mode with an alternative interpretation of Character, the implementation should also support a corresponding change in what is a legal identifier_letter. Not all wide character modes follow this advice, in particular the JIS and IEC modes reflect standard usage in Japan, and in these encoding, the upper half of the Latin-1 set is not part of the wide-character subset, since the most significant bit is used for wide character encoding. However, this only applies to the external forms. Internally there is no such restriction.
3.5.4(28): Integer Types
An implementation should support Long_Integer in addition to Integer if the target machine supports 32-bit (or longer) arithmetic. No other named integer subtypes are recommended for package Standard. Instead, appropriate named integer subtypes should be provided in the library package Interfaces (see B.2). Long_Integer is supported. Other standard integer types are supported so this advice is not fully followed. These types are supported for convenient interface to C, and so that all hardware types of the machine are easily available.
3.5.4(29): Integer Types
An implementation for a two's complement machine should support modular types with a binary modulus up to System.Max_Int*2+2. An implementation should support a non-binary modules up to Integer'Last. Followed.
3.5.5(8): Enumeration Values
For the evaluation of a call on S'Pos for an enumeration subtype, if the value of the operand does not correspond to the internal code for any enumeration literal of its type (perhaps due to an un-initialized variable), then the implementation should raise Program_Error. This is particularly important for enumeration types with noncontiguous internal codes specified by an enumeration_representation_clause. Followed.
3.5.7(17): Float Types
An implementation should support Long_Float in addition to Float if the target machine supports 11 or more digits of precision. No other named floating point subtypes are recommended for package Standard. Instead, appropriate named floating point subtypes should be provided in the library package Interfaces (see B.2). Short_Float and Long_Long_Float are also provided. The former provides improved compatibility with other implementations supporting this type. The latter corresponds to the highest precision floating-point type supported by the hardware. On most machines, this will be the same as Long_Float, but on some machines, it will correspond to the IEEE extended form. On the Silicon Graphics processors, which do not support IEEE extended form, Long_Long_Float is the same as Long_Float.
3.6.2(11): Multidimensional Arrays
An implementation should normally represent multidimensional arrays in row-major order, consistent with the notation used for multidimensional array aggregates (see 4.3.3). However, if a pragma Convention (Fortran, ...) applies to a multidimensional array type, then column-major order should be used instead (see B.5, "Interfacing with Fortran"). Followed.
9.6(30-31): Duration'Small
Whenever possible in an implementation, the value of Duration'Small should be no greater than 100 microseconds. Followed. (Duration'Small = 10**(-9)). The time base for delay_relative_statements should be monotonic; it need not be the same time base as used for Calendar.Clock. Followed.
10.2.1(12): Consistent Representation
In an implementation, a type declared in a pre-elaborated package should have the same representation in every elaboration of a given version of the package, whether the elaborations occur in distinct executions of the same program, or in executions of distinct programs or partitions that include the given version. Followed, except in the case of tagged types. Tagged types involve implicit pointers to a local copy of a dispatch table, and these pointers have representations which thus depend on a particular elaboration of the package. It is not easy to see how it would be possible to follow this advice without severely impacting efficiency of execution.
11.4.1(19): Exception Information
Exception_Message by default and Exception_Information should produce information useful for debugging. Exception_Message should be short, about one line. Exception_Information can be long. Exception_Message should not include the Exception_Name. Exception_Information should include both the Exception_Name and the Exception_Message. Followed. For each exception that doesn't have a specified Exception_Message, the compiler generates one containing the location of the raise statement. This location has the form "file:line", where file is the short file name (without path information) and line is the line number in the file. Note that in the case of the Zero Cost Exception mechanism, these messages become redundant with the Exception_Information that contains a full backtrace of the calling sequence, so they are disabled. To disable explicitly the generation of the source location message, use the Pragma Discard_Names.
11.5(28): Suppression of Checks
The implementation should minimize the code executed for checks that have been suppressed. Followed.
13.1 (21-24): Representation Clauses
The recommended level of support for all representation items is qualified as follows: An implementation need not support representation items containing non-static expressions, except that an implementation should support a representation item for a given entity if each non-static expression in the representation item is a name that statically denotes a constant declared before the entity. Followed. GNAT does not support non-static expressions in representation clauses unless they are constants declared before the entity. For example: 
     X : typ;
     for X'Address use To_address (16#2000#);
will be rejected, since the To_Address expression is non-static. Instead write: 
     X_Address : constant Address : = 
     To_Address    ((16#2000#); 
     X : typ;
     for X'Address use X_Address;
An implementation need not support a specification for the Size for a given composite subtype, nor the size or storage place for an object (including a component) of a given composite subtype, unless the constraints on the subtype and its composite subcomponents (if any) are all static constraints. Followed. Size Clauses are not permitted on non-static components, as described above. An aliased component, or a component whose type is by-reference, should always be allocated at an addressable location. Followed.
13.2(6-8): Packed Types
If a type is packed, then the implementation should try to minimize storage allocated to objects of the type, possibly at the expense of speed of accessing components, subject to reasonable complexity in addressing calculations. The recommended level of support pragma Pack is: For a packed record type, the components should be packed as tightly as possible subject to the Sizes of the component subtypes, and subject to any record_representation_clause that applies to the type; the implementation may, but need not, reorder components or cross aligned word boundaries to improve the packing. A component whose Size is greater than the word size may be allocated an integral number of words. Followed. Tight packing of arrays is supported for all component sizes up to 32-bits, which is the word size on typical implementations of GNAT. An implementation should support Address clauses for imported subprograms. Followed.
13.3(14-19): Address Clauses
For an array X, X'Address should point at the first component of the array, and not at the array bounds. Followed. The recommended level of support for the Address attribute is: X'Address should produce a useful result if X is an object that is aliased or of a by-reference type, or is an entity whose Address has been specified. Followed. A valid address will be produced even if none of those conditions have been met. If necessary, the object is forced into memory to ensure the address is valid. An impl