Implementation Defined Characteristics

Next: Intrinsic Subprograms, Previous: Implementation Advice, Up: Top

4 Implementation Defined Characteristics

In addition to the implementation dependent pragmas and attributes, and the implementation advice, there are a number of other Ada features that are potentially implementation dependent. These are mentioned throughout the Ada Reference Manual, and are summarized in annex M.

A requirement for conforming Ada compilers is that they provide documentation describing how the implementation deals with each of these issues. In this chapter, you will find each point in annex M listed followed by a description in italic font of how GNAT handles the implementation dependence.

You can use this chapter as a guide to minimizing implementation dependent features in your programs if portability to other compilers and other operating systems is an important consideration. The numbers in each section below correspond to the paragraph number in the Ada Reference Manual.

2. Whether or not each recommendation given in Implementation Advice is followed. See 1.1.2(37).
See Implementation Advice.

3. Capacity limitations of the implementation. See 1.1.3(3).
The complexity of programs that can be processed is limited only by the total amount of available virtual memory, and disk space for the generated object files.

4. Variations from the standard that are impractical to avoid given the implementation's execution environment. See 1.1.3(6).
There are no variations from the standard.

5. Which code_statements cause external interactions. See 1.1.3(10).
Any code_statement can potentially cause external interactions.

6. The coded representation for the text of an Ada program. See 2.1(4).
See separate section on source representation.

7. The control functions allowed in comments. See 2.1(14).
See separate section on source representation.

8. The representation for an end of line. See 2.2(2).
See separate section on source representation.

9. Maximum supported line length and lexical element length. See 2.2(15).
The maximum line length is 255 characters and the maximum length of a lexical element is also 255 characters.

10. Implementation defined pragmas. See 2.8(14).
See Implementation Defined Pragmas.

11. Effect of pragma Optimize. See 2.8(27).
Pragma Optimize, if given with a Time or Space parameter, checks that the optimization flag is set, and aborts if it is not.

12. The sequence of characters of the value returned by S'Image when some of the graphic characters of S'Wide_Image are not defined in Character. See 3.5(37).
The sequence of characters is as defined by the wide character encoding method used for the source. See section on source representation for further details.

13. The predefined integer types declared in Standard. See 3.5.4(25).

Short_Short_Integer: 8 bit signed
Short_Integer: (Short) 16 bit signed
Integer: 32 bit signed
Long_Integer: 64 bit signed (Alpha OpenVMS only) 32 bit signed (all other targets)
Long_Long_Integer: 64 bit signed

14. Any nonstandard integer types and the operators defined for them. See 3.5.4(26).
There are no nonstandard integer types.

15. Any nonstandard real types and the operators defined for them. See 3.5.6(8).
There are no nonstandard real types.

16. What combinations of requested decimal precision and range are supported for floating point types. See 3.5.7(7).
The precision and range is as defined by the IEEE standard.

17. The predefined floating point types declared in Standard. See 3.5.7(16).

Short_Float: 32 bit IEEE short
Float: (Short) 32 bit IEEE short
Long_Float: 64 bit IEEE long
Long_Long_Float: 64 bit IEEE long (80 bit IEEE long on x86 processors)

18. The small of an ordinary fixed point type. See 3.5.9(8).
Fine_Delta is 2**(−63)

19. What combinations of small, range, and digits are supported for fixed point types. See 3.5.9(10).
Any combinations are permitted that do not result in a small less than Fine_Delta and do not result in a mantissa larger than 63 bits. If the mantissa is larger than 53 bits on machines where Long_Long_Float is 64 bits (true of all architectures except ia32), then the output from Text_IO is accurate to only 53 bits, rather than the full mantissa. This is because floating-point conversions are used to convert fixed point.

20. The result of Tags.Expanded_Name for types declared within an unnamed block_statement. See 3.9(10).
Block numbers of the form Bnnn, where nnn is a decimal integer are allocated.

21. Implementation-defined attributes. See 4.1.4(12).
See Implementation Defined Attributes.

22. Any implementation-defined time types. See 9.6(6).
There are no implementation-defined time types.

23. The time base associated with relative delays.
See 9.6(20). The time base used is that provided by the C library function gettimeofday.

24. The time base of the type Calendar.Time. See 9.6(23).
The time base used is that provided by the C library function gettimeofday.

25. The time zone used for package Calendar operations. See 9.6(24).
The time zone used by package Calendar is the current system time zone setting for local time, as accessed by the C library function localtime.

26. Any limit on delay_until_statements of select_statements. See 9.6(29).
There are no such limits.

27. Whether or not two non overlapping parts of a composite object are independently addressable, in the case where packing, record layout, or Component_Size is specified for the object. See 9.10(1).
Separate components are independently addressable if they do not share overlapping storage units.

28. The representation for a compilation. See 10.1(2).
A compilation is represented by a sequence of files presented to the compiler in a single invocation of the gcc command.

29. Any restrictions on compilations that contain multiple compilation_units. See 10.1(4).
No single file can contain more than one compilation unit, but any sequence of files can be presented to the compiler as a single compilation.

30. The mechanisms for creating an environment and for adding and replacing compilation units. See 10.1.4(3).
See separate section on compilation model.

31. The manner of explicitly assigning library units to a partition. See 10.2(2).
If a unit contains an Ada main program, then the Ada units for the partition are determined by recursive application of the rules in the Ada Reference Manual section 10.2(2-6). In other words, the Ada units will be those that are needed by the main program, and then this definition of need is applied recursively to those units, and the partition contains the transitive closure determined by this relationship. In short, all the necessary units are included, with no need to explicitly specify the list. If additional units are required, e.g. by foreign language units, then all units must be mentioned in the context clause of one of the needed Ada units.

If the partition contains no main program, or if the main program is in a language other than Ada, then GNAT provides the binder options -z and -n respectively, and in this case a list of units can be explicitly supplied to the binder for inclusion in the partition (all units needed by these units will also be included automatically). For full details on the use of these options, refer to the GNAT User's Guide sections on Binding and Linking.

32. The implementation-defined means, if any, of specifying which compilation units are needed by a given compilation unit. See 10.2(2).
The units needed by a given compilation unit are as defined in the Ada Reference Manual section 10.2(2-6). There are no implementation-defined pragmas or other implementation-defined means for specifying needed units.

33. The manner of designating the main subprogram of a partition. See 10.2(7).
The main program is designated by providing the name of the corresponding ALI file as the input parameter to the binder.

34. The order of elaboration of library_items. See 10.2(18).
The first constraint on ordering is that it meets the requirements of Chapter 10 of the Ada Reference Manual. This still leaves some implementation dependent choices, which are resolved by first elaborating bodies as early as possible (i.e., in preference to specs where there is a choice), and second by evaluating the immediate with clauses of a unit to determine the probably best choice, and third by elaborating in alphabetical order of unit names where a choice still remains.

35. Parameter passing and function return for the main subprogram. See 10.2(21).
The main program has no parameters. It may be a procedure, or a function returning an integer type. In the latter case, the returned integer value is the return code of the program (overriding any value that may have been set by a call to Ada.Command_Line.Set_Exit_Status).

36. The mechanisms for building and running partitions. See 10.2(24).
GNAT itself supports programs with only a single partition. The GNATDIST tool provided with the GLADE package (which also includes an implementation of the PCS) provides a completely flexible method for building and running programs consisting of multiple partitions. See the separate GLADE manual for details.

37. The details of program execution, including program termination. See 10.2(25).
See separate section on compilation model.

38. The semantics of any non-active partitions supported by the implementation. See 10.2(28).
Passive partitions are supported on targets where shared memory is provided by the operating system. See the GLADE reference manual for further details.

39. The information returned by Exception_Message. See 11.4.1(10).
Exception message returns the null string unless a specific message has been passed by the program.

40. The result of Exceptions.Exception_Name for types declared within an unnamed block_statement. See 11.4.1(12).
Blocks have implementation defined names of the form Bnnn where nnn is an integer.

41. The information returned by Exception_Information. See 11.4.1(13).
Exception_Information returns a string in the following format:

     Exception_Name: nnnnn
     Message: mmmmm
     PID: ppp
     Call stack traceback locations:
     0xhhhh 0xhhhh 0xhhhh ... 0xhhh

where

nnnn is the fully qualified name of the exception in all upper case letters. This line is always present.
mmmm is the message (this line present only if message is non-null)
ppp is the Process Id value as a decimal integer (this line is present only if the Process Id is nonzero). Currently we are not making use of this field.
The Call stack traceback locations line and the following values are present only if at least one traceback location was recorded. The values are given in C style format, with lower case letters for a-f, and only as many digits present as are necessary.

The line terminator sequence at the end of each line, including the last line is a single LF character (16#0A#).

42. Implementation-defined check names. See 11.5(27).
The implementation defined check name Alignment_Check controls checking of address clause values for proper alignment (that is, the address supplied must be consistent with the alignment of the type).

In addition, a user program can add implementation-defined check names by means of the pragma Check_Name.

43. The interpretation of each aspect of representation. See 13.1(20).
See separate section on data representations.

44. Any restrictions placed upon representation items. See 13.1(20).
See separate section on data representations.

45. The meaning of Size for indefinite subtypes. See 13.3(48).
Size for an indefinite subtype is the maximum possible size, except that for the case of a subprogram parameter, the size of the parameter object is the actual size.

46. The default external representation for a type tag. See 13.3(75).
The default external representation for a type tag is the fully expanded name of the type in upper case letters.

47. What determines whether a compilation unit is the same in two different partitions. See 13.3(76).
A compilation unit is the same in two different partitions if and only if it derives from the same source file.

48. Implementation-defined components. See 13.5.1(15).
The only implementation defined component is the tag for a tagged type, which contains a pointer to the dispatching table.

49. If Word_Size = Storage_Unit, the default bit ordering. See 13.5.3(5).
Word_Size (32) is not the same as Storage_Unit (8) for this implementation, so no non-default bit ordering is supported. The default bit ordering corresponds to the natural endianness of the target architecture.

50. The contents of the visible part of package System and its language-defined children. See 13.7(2).
See the definition of these packages in files system.ads and s-stoele.ads.

51. The contents of the visible part of package System.Machine_Code, and the meaning of code_statements. See 13.8(7).
See the definition and documentation in file s-maccod.ads.

52. The effect of unchecked conversion. See 13.9(11).
Unchecked conversion between types of the same size results in an uninterpreted transmission of the bits from one type to the other. If the types are of unequal sizes, then in the case of discrete types, a shorter source is first zero or sign extended as necessary, and a shorter target is simply truncated on the left. For all non-discrete types, the source is first copied if necessary to ensure that the alignment requirements of the target are met, then a pointer is constructed to the source value, and the result is obtained by dereferencing this pointer after converting it to be a pointer to the target type. Unchecked conversions where the target subtype is an unconstrained array are not permitted. If the target alignment is greater than the source alignment, then a copy of the result is made with appropriate alignment

53. The manner of choosing a storage pool for an access type when Storage_Pool is not specified for the type. See 13.11(17).
There are 3 different standard pools used by the compiler when Storage_Pool is not specified depending whether the type is local to a subprogram or defined at the library level and whether Storage_Sizeis specified or not. See documentation in the runtime library units System.Pool_Global, System.Pool_Size and System.Pool_Local in files s-poosiz.ads, s-pooglo.ads and s-pooloc.ads for full details on the default pools used.

54. Whether or not the implementation provides user-accessible names for the standard pool type(s). See 13.11(17).
See documentation in the sources of the run time mentioned in paragraph 53 . All these pools are accessible by means of with'ing these units.

55. The meaning of Storage_Size. See 13.11(18).
Storage_Size is measured in storage units, and refers to the total space available for an access type collection, or to the primary stack space for a task.

56. Implementation-defined aspects of storage pools. See 13.11(22).
See documentation in the sources of the run time mentioned in paragraph 53 for details on GNAT-defined aspects of storage pools.

57. The set of restrictions allowed in a pragma Restrictions. See 13.12(7).
All RM defined Restriction identifiers are implemented. The following additional restriction identifiers are provided. There are two separate lists of implementation dependent restriction identifiers. The first set requires consistency throughout a partition (in other words, if the restriction identifier is used for any compilation unit in the partition, then all compilation units in the partition must obey the restriction.

Simple_Barriers

This restriction ensures at compile time that barriers in entry declarations for protected types are restricted to either static boolean expressions or references to simple boolean variables defined in the private part of the protected type. No other form of entry barriers is permitted. This is one of the restrictions of the Ravenscar profile for limited tasking (see also pragma Profile (Ravenscar)).

Max_Entry_Queue_Length => Expr

This restriction is a declaration that any protected entry compiled in the scope of the restriction has at most the specified number of tasks waiting on the entry at any one time, and so no queue is required. This restriction is not checked at compile time. A program execution is erroneous if an attempt is made to queue more than the specified number of tasks on such an entry.

No_Calendar

This restriction ensures at compile time that there is no implicit or explicit dependence on the package Ada.Calendar.

No_Direct_Boolean_Operators

This restriction ensures that no logical (and/or/xor) or comparison operators are used on operands of type Boolean (or any type derived from Boolean). This is intended for use in safety critical programs where the certification protocol requires the use of short-circuit (and then, or else) forms for all composite boolean operations.

No_Dispatching_Calls

This restriction ensures at compile time that the code generated by the compiler involves no dispatching calls. The use of this restriction allows the safe use of record extensions, classwide membership tests and other classwide features not involving implicit dispatching. This restriction ensures that the code contains no indirect calls through a dispatching mechanism. Note that this includes internally-generated calls created by the compiler, for example in the implementation of class-wide objects assignments. The membership test is allowed in the presence of this restriction, because its implementation requires no dispatching. This restriction is comparable to the official Ada restriction No_Dispatch except that it is a bit less restrictive in that it allows all classwide constructs that do not imply dispatching. The following example indicates constructs that violate this restriction.

          package Pkg is
            type T is tagged record
              Data : Natural;
            end record;
            procedure P (X : T);
          
            type DT is new T with record
              More_Data : Natural;
            end record;
            procedure Q (X : DT);
          end Pkg;
          
          with Pkg; use Pkg;
          procedure Example is
            procedure Test (O : T'Class) is
              N : Natural  := O'Size;--  Error: Dispatching call
              C : T'Class := O;      --  Error: implicit Dispatching Call
            begin
              if O in DT'Class then  --  OK   : Membership test
                 Q (DT (O));         --  OK   : Type conversion plus direct call
              else
                 P (O);              --  Error: Dispatching call
              end if;
            end Test;
          
            Obj : DT;
          begin
            P (Obj);                 --  OK   : Direct call
            P (T (Obj));             --  OK   : Type conversion plus direct call
            P (T'Class (Obj));       --  Error: Dispatching call
          
            Test (Obj);              --  OK   : Type conversion
          
            if Obj in T'Class then   --  OK   : Membership test
               null;
            end if;
          end Example;

No_Dynamic_Attachment

This restriction ensures that there is no call to any of the operations defined in package Ada.Interrupts.

No_Enumeration_Maps

This restriction ensures at compile time that no operations requiring enumeration maps are used (that is Image and Value attributes applied to enumeration types).

No_Entry_Calls_In_Elaboration_Code

This restriction ensures at compile time that no task or protected entry calls are made during elaboration code. As a result of the use of this restriction, the compiler can assume that no code past an accept statement in a task can be executed at elaboration time.

No_Exception_Handlers

This restriction ensures at compile time that there are no explicit exception handlers. It also indicates that no exception propagation will be provided. In this mode, exceptions may be raised but will result in an immediate call to the last chance handler, a routine that the user must define with the following profile:

procedure Last_Chance_Handler (Source_Location : System.Address; Line : Integer); pragma Export (C, Last_Chance_Handler, "__gnat_last_chance_handler");

The parameter is a C null-terminated string representing a message to be associated with the exception (typically the source location of the raise statement generated by the compiler). The Line parameter when nonzero represents the line number in the source program where the raise occurs.

No_Exception_Propagation

This restriction guarantees that exceptions are never propagated to an outer subprogram scope). The only case in which an exception may be raised is when the handler is statically in the same subprogram, so that the effect of a raise is essentially like a goto statement. Any other raise statement (implicit or explicit) will be considered unhandled. Exception handlers are allowed, but may not contain an exception occurrence identifier (exception choice). In addition use of the package GNAT.Current_Exception is not permitted, and reraise statements (raise with no operand) are not permitted.

No_Exception_Registration

This restriction ensures at compile time that no stream operations for types Exception_Id or Exception_Occurrence are used. This also makes it impossible to pass exceptions to or from a partition with this restriction in a distributed environment. If this exception is active, then the generated code is simplified by omitting the otherwise-required global registration of exceptions when they are declared.

No_Implicit_Conditionals

This restriction ensures that the generated code does not contain any implicit conditionals, either by modifying the generated code where possible, or by rejecting any construct that would otherwise generate an implicit conditional. Note that this check does not include run time constraint checks, which on some targets may generate implicit conditionals as well. To control the latter, constraint checks can be suppressed in the normal manner. Constructs generating implicit conditionals include comparisons of composite objects and the Max/Min attributes.

No_Implicit_Dynamic_Code

This restriction prevents the compiler from building “trampolines”. This is a structure that is built on the stack and contains dynamic code to be executed at run time. On some targets, a trampoline is built for the following features: Access, Unrestricted_Access, or Address of a nested subprogram; nested task bodies; primitive operations of nested tagged types. Trampolines do not work on machines that prevent execution of stack data. For example, on windows systems, enabling DEP (data execution protection) will cause trampolines to raise an exception.

No_Implicit_Loops

This restriction ensures that the generated code does not contain any implicit for loops, either by modifying the generated code where possible, or by rejecting any construct that would otherwise generate an implicit for loop. If this restriction is active, it is possible to build large array aggregates with all static components without generating an intermediate temporary, and without generating a loop to initialize individual components. Otherwise, a loop is created for arrays larger than about 5000 scalar components.

No_Initialize_Scalars

This restriction ensures that no unit in the partition is compiled with pragma Initialize_Scalars. This allows the generation of more efficient code, and in particular eliminates dummy null initialization routines that are otherwise generated for some record and array types.

No_Local_Protected_Objects

This restriction ensures at compile time that protected objects are only declared at the library level.

No_Protected_Type_Allocators

This restriction ensures at compile time that there are no allocator expressions that attempt to allocate protected objects.

No_Secondary_Stack

This restriction ensures at compile time that the generated code does not contain any reference to the secondary stack. The secondary stack is used to implement functions returning unconstrained objects (arrays or records) on some targets.

No_Select_Statements

This restriction ensures at compile time no select statements of any kind are permitted, that is the keyword select may not appear. This is one of the restrictions of the Ravenscar profile for limited tasking (see also pragma Profile (Ravenscar)).

No_Standard_Storage_Pools

This restriction ensures at compile time that no access types use the standard default storage pool. Any access type declared must have an explicit Storage_Pool attribute defined specifying a user-defined storage pool.

No_Streams

This restriction ensures at compile/bind time that there are no stream objects created (and therefore no actual stream operations). This restriction does not forbid dependences on the package Ada.Streams. So it is permissible to with Ada.Streams (or another package that does so itself) as long as no actual stream objects are created.

No_Task_Attributes_Package

This restriction ensures at compile time that there are no implicit or explicit dependencies on the package Ada.Task_Attributes.

No_Task_Termination

This restriction ensures at compile time that no terminate alternatives appear in any task body.

No_Tasking

This restriction prevents the declaration of tasks or task types throughout the partition. It is similar in effect to the use of Max_Tasks => 0 except that violations are caught at compile time and cause an error message to be output either by the compiler or binder.

Static_Priorities

This restriction ensures at compile time that all priority expressions are static, and that there are no dependencies on the package Ada.Dynamic_Priorities.

Static_Storage_Size

This restriction ensures at compile time that any expression appearing in a Storage_Size pragma or attribute definition clause is static.

The second set of implementation dependent restriction identifiers does not require partition-wide consistency. The restriction may be enforced for a single compilation unit without any effect on any of the other compilation units in the partition.

No_Elaboration_Code

This restriction ensures at compile time that no elaboration code is generated. Note that this is not the same condition as is enforced by pragma Preelaborate. There are cases in which pragma Preelaborate still permits code to be generated (e.g. code to initialize a large array to all zeroes), and there are cases of units which do not meet the requirements for pragma Preelaborate, but for which no elaboration code is generated. Generally, it is the case that preelaborable units will meet the restrictions, with the exception of large aggregates initialized with an others_clause, and exception declarations (which generate calls to a run-time registry procedure). This restriction is enforced on a unit by unit basis, it need not be obeyed consistently throughout a partition.

In the case of aggregates with others, if the aggregate has a dynamic size, there is no way to eliminate the elaboration code (such dynamic bounds would be incompatible with Preelaborate in any case). If the bounds are static, then use of this restriction actually modifies the code choice of the compiler to avoid generating a loop, and instead generate the aggregate statically if possible, no matter how many times the data for the others clause must be repeatedly generated.

It is not possible to precisely document the constructs which are compatible with this restriction, since, unlike most other restrictions, this is not a restriction on the source code, but a restriction on the generated object code. For example, if the source contains a declaration:

             Val : constant Integer := X;

where X is not a static constant, it may be possible, depending on complex optimization circuitry, for the compiler to figure out the value of X at compile time, in which case this initialization can be done by the loader, and requires no initialization code. It is not possible to document the precise conditions under which the optimizer can figure this out.

Note that this the implementation of this restriction requires full code generation. If it is used in conjunction with "semantics only" checking, then some cases of violations may be missed.

No_Entry_Queue

This restriction is a declaration that any protected entry compiled in the scope of the restriction has at most one task waiting on the entry at any one time, and so no queue is required. This restriction is not checked at compile time. A program execution is erroneous if an attempt is made to queue a second task on such an entry.

No_Implementation_Attributes

This restriction checks at compile time that no GNAT-defined attributes are present. With this restriction, the only attributes that can be used are those defined in the Ada Reference Manual.

No_Implementation_Pragmas

This restriction checks at compile time that no GNAT-defined pragmas are present. With this restriction, the only pragmas that can be used are those defined in the Ada Reference Manual.

No_Implementation_Restrictions

This restriction checks at compile time that no GNAT-defined restriction identifiers (other than No_Implementation_Restrictions itself) are present. With this restriction, the only other restriction identifiers that can be used are those defined in the Ada Reference Manual.

No_Wide_Characters

This restriction ensures at compile time that no uses of the types Wide_Character or Wide_String or corresponding wide wide types appear, and that no wide or wide wide string or character literals appear in the program (that is literals representing characters not in type Character.

58. The consequences of violating limitations on Restrictions pragmas. See 13.12(9).
Restrictions that can be checked at compile time result in illegalities if violated. Currently there are no other consequences of violating restrictions.

59. The representation used by the Read and Write attributes of elementary types in terms of stream elements. See 13.13.2(9).
The representation is the in-memory representation of the base type of the type, using the number of bits corresponding to the type'Size value, and the natural ordering of the machine.

60. The names and characteristics of the numeric subtypes declared in the visible part of package Standard. See A.1(3).
See items describing the integer and floating-point types supported.

61. The accuracy actually achieved by the elementary functions. See A.5.1(1).
The elementary functions correspond to the functions available in the C library. Only fast math mode is implemented.

62. The sign of a zero result from some of the operators or functions in Numerics.Generic_Elementary_Functions, when Float_Type'Signed_Zeros is True. See A.5.1(46).
The sign of zeroes follows the requirements of the IEEE 754 standard on floating-point.

63. The value of Numerics.Float_Random.Max_Image_Width. See A.5.2(27).
Maximum image width is 649, see library file a-numran.ads.

64. The value of Numerics.Discrete_Random.Max_Image_Width. See A.5.2(27).
Maximum image width is 80, see library file a-nudira.ads.

65. The algorithms for random number generation. See A.5.2(32).
The algorithm is documented in the source files a-numran.ads and a-numran.adb.

66. The string representation of a random number generator's state. See A.5.2(38).
See the documentation contained in the file a-numran.adb.

67. The minimum time interval between calls to the time-dependent Reset procedure that are guaranteed to initiate different random number sequences. See A.5.2(45).
The minimum period between reset calls to guarantee distinct series of random numbers is one microsecond.

68. The values of the Model_Mantissa, Model_Emin, Model_Epsilon, Model, Safe_First, and Safe_Last attributes, if the Numerics Annex is not supported. See A.5.3(72).
See the source file ttypef.ads for the values of all numeric attributes.

69. Any implementation-defined characteristics of the input-output packages. See A.7(14).
There are no special implementation defined characteristics for these packages.

70. The value of Buffer_Size in Storage_IO. See A.9(10).
All type representations are contiguous, and the Buffer_Size is the value of type'Size rounded up to the next storage unit boundary.

71. External files for standard input, standard output, and standard error See A.10(5).
These files are mapped onto the files provided by the C streams libraries. See source file i-cstrea.ads for further details.

72. The accuracy of the value produced by Put. See A.10.9(36).
If more digits are requested in the output than are represented by the precision of the value, zeroes are output in the corresponding least significant digit positions.

73. The meaning of Argument_Count, Argument, and Command_Name. See A.15(1).
These are mapped onto the argv and argc parameters of the main program in the natural manner.

74. Implementation-defined convention names. See B.1(11).
The following convention names are supported

Ada: Ada
Assembler: Assembly language
Asm: Synonym for Assembler
Assembly: Synonym for Assembler
C: C
C_Pass_By_Copy: Allowed only for record types, like C, but also notes that record is to be passed by copy rather than reference.
COBOL: COBOL
C_Plus_Plus (or CPP): C++
Default: Treated the same as C
External: Treated the same as C
Fortran: Fortran
Intrinsic: For support of pragma Import with convention Intrinsic, see separate section on Intrinsic Subprograms.
Stdcall: Stdcall (used for Windows implementations only). This convention correspond to the WINAPI (previously called Pascal convention) C/C++ convention under Windows. A function with this convention cleans the stack before exit.
DLL: Synonym for Stdcall
Win32: Synonym for Stdcall
Stubbed: Stubbed is a special convention used to indicate that the body of the subprogram will be entirely ignored. Any call to the subprogram is converted into a raise of the Program_Error exception. If a pragma Import specifies convention stubbed then no body need be present at all. This convention is useful during development for the inclusion of subprograms whose body has not yet been written.

In addition, all otherwise unrecognized convention names are also treated as being synonymous with convention C. In all implementations except for VMS, use of such other names results in a warning. In VMS implementations, these names are accepted silently.

75. The meaning of link names. See B.1(36).
Link names are the actual names used by the linker.

76. The manner of choosing link names when neither the link name nor the address of an imported or exported entity is specified. See B.1(36).
The default linker name is that which would be assigned by the relevant external language, interpreting the Ada name as being in all lower case letters.

77. The effect of pragma Linker_Options. See B.1(37).
The string passed to Linker_Options is presented uninterpreted as an argument to the link command, unless it contains Ascii.NUL characters. NUL characters if they appear act as argument separators, so for example

     pragma Linker_Options ("-labc" & ASCII.Nul & "-ldef");

causes two separate arguments -labc and -ldef to be passed to the linker. The order of linker options is preserved for a given unit. The final list of options passed to the linker is in reverse order of the elaboration order. For example, linker options for a body always appear before the options from the corresponding package spec.

78. The contents of the visible part of package Interfaces and its language-defined descendants. See B.2(1).
See files with prefix i- in the distributed library.

79. Implementation-defined children of package Interfaces. The contents of the visible part of package Interfaces. See B.2(11).
See files with prefix i- in the distributed library.

80. The types Floating, Long_Floating, Binary, Long_Binary, Decimal_ Element, and COBOL_Character; and the initialization of the variables Ada_To_COBOL and COBOL_To_Ada, in Interfaces.COBOL. See B.4(50).

Floating: Float
Long_Floating: (Floating) Long_Float
Binary: Integer
Long_Binary: Long_Long_Integer
Decimal_Element: Character
COBOL_Character: Character

For initialization, see the file i-cobol.ads in the distributed library.

81. Support for access to machine instructions. See C.1(1).
See documentation in file s-maccod.ads in the distributed library.

82. Implementation-defined aspects of access to machine operations. See C.1(9).
See documentation in file s-maccod.ads in the distributed library.

83. Implementation-defined aspects of interrupts. See C.3(2).
Interrupts are mapped to signals or conditions as appropriate. See definition of unit Ada.Interrupt_Names in source file a-intnam.ads for details on the interrupts supported on a particular target.

84. Implementation-defined aspects of pre-elaboration. See C.4(13).
GNAT does not permit a partition to be restarted without reloading, except under control of the debugger.

85. The semantics of pragma Discard_Names. See C.5(7).
Pragma Discard_Names causes names of enumeration literals to be suppressed. In the presence of this pragma, the Image attribute provides the image of the Pos of the literal, and Value accepts Pos values.

86. The result of the Task_Identification.Image attribute. See C.7.1(7).
The result of this attribute is a string that identifies the object or component that denotes a given task. If a variable Var has a task type, the image for this task will have the form Var_XXXXXXXX, where the suffix is the hexadecimal representation of the virtual address of the corresponding task control block. If the variable is an array of tasks, the image of each task will have the form of an indexed component indicating the position of a given task in the array, eg. Group(5)_XXXXXXX. If the task is a component of a record, the image of the task will have the form of a selected component. These rules are fully recursive, so that the image of a task that is a subcomponent of a composite object corresponds to the expression that designates this task. If a task is created by an allocator, its image depends on the context. If the allocator is part of an object declaration, the rules described above are used to construct its image, and this image is not affected by subsequent assignments. If the allocator appears within an expression, the image includes only the name of the task type. If the configuration pragma Discard_Names is present, or if the restriction No_Implicit_Heap_Allocation is in effect, the image reduces to the numeric suffix, that is to say the hexadecimal representation of the virtual address of the control block of the task.

87. The value of Current_Task when in a protected entry or interrupt handler. See C.7.1(17).
Protected entries or interrupt handlers can be executed by any convenient thread, so the value of Current_Task is undefined.

88. The effect of calling Current_Task from an entry body or interrupt handler. See C.7.1(19).
The effect of calling Current_Task from an entry body or interrupt handler is to return the identification of the task currently executing the code.

89. Implementation-defined aspects of Task_Attributes. See C.7.2(19).
There are no implementation-defined aspects of Task_Attributes.

90. Values of all Metrics. See D(2).
The metrics information for GNAT depends on the performance of the underlying operating system. The sources of the run-time for tasking implementation, together with the output from -gnatG can be used to determine the exact sequence of operating systems calls made to implement various tasking constructs. Together with appropriate information on the performance of the underlying operating system, on the exact target in use, this information can be used to determine the required metrics.

91. The declarations of Any_Priority and Priority. See D.1(11).
See declarations in file system.ads.

92. Implementation-defined execution resources. See D.1(15).
There are no implementation-defined execution resources.

93. Whether, on a multiprocessor, a task that is waiting for access to a protected object keeps its processor busy. See D.2.1(3).
On a multi-processor, a task that is waiting for access to a protected object does not keep its processor busy.

94. The affect of implementation defined execution resources on task dispatching. See D.2.1(9).
Tasks map to threads in the threads package used by GNAT. Where possible and appropriate, these threads correspond to native threads of the underlying operating system.

95. Implementation-defined policy_identifiers allowed in a pragma Task_Dispatching_Policy. See D.2.2(3).
There are no implementation-defined policy-identifiers allowed in this pragma.

96. Implementation-defined aspects of priority inversion. See D.2.2(16).
Execution of a task cannot be preempted by the implementation processing of delay expirations for lower priority tasks.

97. Implementation defined task dispatching. See D.2.2(18).
The policy is the same as that of the underlying threads implementation.

98. Implementation-defined policy_identifiers allowed in a pragma Locking_Policy. See D.3(4).
The only implementation defined policy permitted in GNAT is Inheritance_Locking. On targets that support this policy, locking is implemented by inheritance, i.e. the task owning the lock operates at a priority equal to the highest priority of any task currently requesting the lock.

99. Default ceiling priorities. See D.3(10).
The ceiling priority of protected objects of the type System.Interrupt_Priority'Last as described in the Ada Reference Manual D.3(10),

100. The ceiling of any protected object used internally by the implementation. See D.3(16).
The ceiling priority of internal protected objects is System.Priority'Last.

101. Implementation-defined queuing policies. See D.4(1).
There are no implementation-defined queuing policies.

102. On a multiprocessor, any conditions that cause the completion of an aborted construct to be delayed later than what is specified for a single processor. See D.6(3).
The semantics for abort on a multi-processor is the same as on a single processor, there are no further delays.

103. Any operations that implicitly require heap storage allocation. See D.7(8).
The only operation that implicitly requires heap storage allocation is task creation.

104. Implementation-defined aspects of pragma Restrictions. See D.7(20).
There are no such implementation-defined aspects.

105. Implementation-defined aspects of package Real_Time. See D.8(17).
There are no implementation defined aspects of package Real_Time.

106. Implementation-defined aspects of delay_statements. See D.9(8).
Any difference greater than one microsecond will cause the task to be delayed (see D.9(7)).

107. The upper bound on the duration of interrupt blocking caused by the implementation. See D.12(5).
The upper bound is determined by the underlying operating system. In no cases is it more than 10 milliseconds.

108. The means for creating and executing distributed programs. See E(5).
The GLADE package provides a utility GNATDIST for creating and executing distributed programs. See the GLADE reference manual for further details.

109. Any events that can result in a partition becoming inaccessible. See E.1(7).
See the GLADE reference manual for full details on such events.

110. The scheduling policies, treatment of priorities, and management of shared resources between partitions in certain cases. See E.1(11).
See the GLADE reference manual for full details on these aspects of multi-partition execution.

111. Events that cause the version of a compilation unit to change. See E.3(5).
Editing the source file of a compilation unit, or the source files of any units on which it is dependent in a significant way cause the version to change. No other actions cause the version number to change. All changes are significant except those which affect only layout, capitalization or comments.

112. Whether the execution of the remote subprogram is immediately aborted as a result of cancellation. See E.4(13).
See the GLADE reference manual for details on the effect of abort in a distributed application.

113. Implementation-defined aspects of the PCS. See E.5(25).
See the GLADE reference manual for a full description of all implementation defined aspects of the PCS.

114. Implementation-defined interfaces in the PCS. See E.5(26).
See the GLADE reference manual for a full description of all implementation defined interfaces.

115. The values of named numbers in the package Decimal. See F.2(7).

Max_Scale: +18
Min_Scale: -18
Min_Delta: 1.0E-18
Max_Delta: 1.0E+18
Max_Decimal_Digits: 18

116. The value of Max_Picture_Length in the package Text_IO.Editing. See F.3.3(16).
64

117. The value of Max_Picture_Length in the package Wide_Text_IO.Editing. See F.3.4(5).
64

118. The accuracy actually achieved by the complex elementary functions and by other complex arithmetic operations. See G.1(1).
Standard library functions are used for the complex arithmetic operations. Only fast math mode is currently supported.

119. The sign of a zero result (or a component thereof) from any operator or function in Numerics.Generic_Complex_Types, when Real'Signed_Zeros is True. See G.1.1(53).
The signs of zero values are as recommended by the relevant implementation advice.

120. The sign of a zero result (or a component thereof) from any operator or function in Numerics.Generic_Complex_Elementary_Functions, when Real'Signed_Zeros is True. See G.1.2(45).
The signs of zero values are as recommended by the relevant implementation advice.

121. Whether the strict mode or the relaxed mode is the default. See G.2(2).
The strict mode is the default. There is no separate relaxed mode. GNAT provides a highly efficient implementation of strict mode.

122. The result interval in certain cases of fixed-to-float conversion. See G.2.1(10).
For cases where the result interval is implementation dependent, the accuracy is that provided by performing all operations in 64-bit IEEE floating-point format.

123. The result of a floating point arithmetic operation in overflow situations, when the Machine_Overflows attribute of the result type is False. See G.2.1(13).
Infinite and NaN values are produced as dictated by the IEEE floating-point standard.

Note that on machines that are not fully compliant with the IEEE floating-point standard, such as Alpha, the -mieee compiler flag must be used for achieving IEEE confirming behavior (although at the cost of a significant performance penalty), so infinite and NaN values are properly generated.

124. The result interval for division (or exponentiation by a negative exponent), when the floating point hardware implements division as multiplication by a reciprocal. See G.2.1(16).
Not relevant, division is IEEE exact.

125. The definition of close result set, which determines the accuracy of certain fixed point multiplications and divisions. See G.2.3(5).
Operations in the close result set are performed using IEEE long format floating-point arithmetic. The input operands are converted to floating-point, the operation is done in floating-point, and the result is converted to the target type.

126. Conditions on a universal_real operand of a fixed point multiplication or division for which the result shall be in the perfect result set. See G.2.3(22).
The result is only defined to be in the perfect result set if the result can be computed by a single scaling operation involving a scale factor representable in 64-bits.

127. The result of a fixed point arithmetic operation in overflow situations, when the Machine_Overflows attribute of the result type is False. See G.2.3(27).
Not relevant, Machine_Overflows is True for fixed-point types.

128. The result of an elementary function reference in overflow situations, when the Machine_Overflows attribute of the result type is False. See G.2.4(4).
IEEE infinite and Nan values are produced as appropriate.

129. The value of the angle threshold, within which certain elementary functions, complex arithmetic operations, and complex elementary functions yield results conforming to a maximum relative error bound. See G.2.4(10).
Information on this subject is not yet available.

130. The accuracy of certain elementary functions for parameters beyond the angle threshold. See G.2.4(10).
Information on this subject is not yet available.

131. The result of a complex arithmetic operation or complex elementary function reference in overflow situations, when the Machine_Overflows attribute of the corresponding real type is False. See G.2.6(5).
IEEE infinite and Nan values are produced as appropriate.

132. The accuracy of certain complex arithmetic operations and certain complex elementary functions for parameters (or components thereof) beyond the angle threshold. See G.2.6(8).
Information on those subjects is not yet available.

133. Information regarding bounded errors and erroneous execution. See H.2(1).
Information on this subject is not yet available.

134. Implementation-defined aspects of pragma Inspection_Point. See H.3.2(8).
Pragma Inspection_Point ensures that the variable is live and can be examined by the debugger at the inspection point.

135. Implementation-defined aspects of pragma Restrictions. See H.4(25).
There are no implementation-defined aspects of pragma Restrictions. The use of pragma Restrictions [No_Exceptions] has no effect on the generated code. Checks must suppressed by use of pragma Suppress.

136. Any restrictions on pragma Restrictions. See H.4(27).
There are no restrictions on pragma Restrictions.