* About This Guide::
* Implementation Defined Pragmas::
* Implementation Defined Attributes::
+* Implementation Defined Restrictions::
* Implementation Advice::
* Implementation Defined Characteristics::
* Intrinsic Subprograms::
* Pragma Shared::
* Pragma Short_Circuit_And_Or::
* Pragma Short_Descriptors::
+* Pragma Simple_Storage_Pool_Type::
* Pragma Source_File_Name::
* Pragma Source_File_Name_Project::
* Pragma Source_Reference::
* Result::
* Safe_Emax::
* Safe_Large::
+* Simple_Storage_Pool::
* Small::
* Storage_Unit::
* Stub_Type::
* Wchar_T_Size::
* Word_Size::
+Implementation Defined Restrictions
+
+* Partition-Wide Restrictions::
+* Unit-Level Restrictions::
+
+Partition-Wide Restrictions
+
+* Immediate_Reclamation::
+* Max_Asynchronous_Select_Nesting::
+* Max_Entry_Queue_Length::
+* Max_Protected_Entries::
+* Max_Select_Alternatives::
+* Max_Storage_At_Blocking::
+* Max_Task_Entries::
+* Max_Tasks::
+* No_Abort_Statements::
+* No_Access_Parameter_Allocators::
+* No_Access_Subprograms::
+* No_Allocators::
+* No_Anonymous_Allocators::
+* No_Calendar::
+* No_Coextensions::
+* No_Default_Initialization::
+* No_Delay::
+* No_Dependence::
+* No_Direct_Boolean_Operators::
+* No_Dispatch::
+* No_Dispatching_Calls::
+* No_Dynamic_Attachment::
+* No_Dynamic_Priorities::
+* No_Entry_Calls_In_Elaboration_Code::
+* No_Enumeration_Maps::
+* No_Exception_Handlers::
+* No_Exception_Propagation::
+* No_Exception_Registration::
+* No_Exceptions::
+* No_Finalization::
+* No_Fixed_Point::
+* No_Floating_Point::
+* No_Implicit_Conditionals::
+* No_Implicit_Dynamic_Code::
+* No_Implicit_Heap_Allocations::
+* No_Implicit_Loops::
+* No_Initialize_Scalars::
+* No_IO::
+* No_Local_Allocators::
+* No_Local_Protected_Objects::
+* No_Local_Timing_Events::
+* No_Nested_Finalization::
+* No_Protected_Type_Allocators::
+* No_Protected_Types::
+* No_Relative_Delay::
+* No_Requeue_Statements::
+* No_Secondary_Stack::
+* No_Select_Statements::
+* No_Specific_Termination_Handlers::
+* No_Specification_of_Aspect::
+* No_Standard_Allocators_After_Elaboration::
+* No_Standard_Storage_Pools::
+* No_Stream_Optimizations::
+* No_Streams::
+* No_Task_Allocators::
+* No_Task_Attributes_Package::
+* No_Task_Hierarchy::
+* No_Tasking::
+* No_Terminate_Alternatives::
+* No_Unchecked_Access::
+* Simple_Barriers::
+* Static_Priorities::
+* Static_Storage_Size::
+
+Unit-Level Restrictions
+
+* No_Elaboration_Code::
+* No_Entry_Queue::
+* No_Implementation_Aspect_Specifications::
+* No_Implementation_Attributes::
+* No_Implementation_Identifiers::
+* No_Implementation_Pragmas::
+* No_Implementation_Restrictions::
+* No_Implementation_Units::
+* No_Implicit_Aliasing::
+* No_Obsolescent_Features::
+* No_Recursion::
+* No_Reentrancy::
+* No_Wide_Characters::
+* SPARK::
+* No_Task_Termination::
+
The Implementation of Standard I/O
* Standard I/O Packages::
@item
@ref{Implementation Defined Attributes}, lists GNAT
-implementation-dependent attributes which can be used to extend and
+implementation-dependent attributes, which can be used to extend and
+enhance the functionality of the compiler.
+
+@item
+@ref{Implementation Defined Restrictions}, lists GNAT
+implementation-dependent restrictions, which can be used to extend and
enhance the functionality of the compiler.
@item
* Pragma Shared::
* Pragma Short_Circuit_And_Or::
* Pragma Short_Descriptors::
+* Pragma Simple_Storage_Pool_Type::
* Pragma Source_File_Name::
* Pragma Source_File_Name_Project::
* Pragma Source_Reference::
@table @code
@item Max_Entry_Queue_Length => 1
-Defines the maximum number of calls that are queued on a (protected) entry.
-Note that this restrictions is checked at run time. Violation of this
-restriction results in the raising of Program_Error exception at the point of
-the call. For the Profile (Ravenscar) the value of Max_Entry_Queue_Length is
-always 1 and hence no task can be queued on a protected entry.
-
+No task can be queued on a protected entry.
@item Max_Protected_Entries => 1
-[RM D.7] Specifies the maximum number of entries per protected type. The
-bounds of every entry family of a protected unit shall be static, or shall be
-defined by a discriminant of a subtype whose corresponding bound is static.
-For the Profile (Ravenscar) the value of Max_Protected_Entries is always 1.
-
@item Max_Task_Entries => 0
-[RM D.7] Specifies the maximum number of entries
-per task. The bounds of every entry family
-of a task unit shall be static, or shall be
-defined by a discriminant of a subtype whose
-corresponding bound is static. A value of zero
-indicates that no rendezvous are possible. For
-the Profile (Ravenscar), the value of Max_Task_Entries is always
-0 (zero).
-
+No rendezvous are possible.
@item No_Abort_Statements
-[RM D.7] There are no abort_statements, and there are
-no calls to Task_Identification.Abort_Task.
-
@item No_Dynamic_Attachment
-There is no call to any of the operations defined in package Ada.Interrupts
-(Is_Reserved, Is_Attached, Current_Handler, Attach_Handler, Exchange_Handler,
-Detach_Handler, and Reference).
-
@item No_Dynamic_Priorities
-[RM D.7] There are no semantic dependencies on the package Dynamic_Priorities.
-
@item No_Implicit_Heap_Allocations
-[RM D.7] No constructs are allowed to cause implicit heap allocation.
-
@item No_Local_Protected_Objects
-Protected objects and access types that designate
-such objects shall be declared only at library level.
-
@item No_Local_Timing_Events
-[RM D.7] All objects of type Ada.Timing_Events.Timing_Event are
-declared at the library level.
-
@item No_Protected_Type_Allocators
-There are no allocators for protected types or
-types containing protected subcomponents.
-
@item No_Relative_Delay
-There are no delay_relative statements.
-
@item No_Requeue_Statements
-Requeue statements are not allowed.
-
@item No_Select_Statements
-There are no select_statements.
-
@item No_Specific_Termination_Handlers
-[RM D.7] There are no calls to Ada.Task_Termination.Set_Specific_Handler
-or to Ada.Task_Termination.Specific_Handler.
-
@item No_Task_Allocators
-[RM D.7] There are no allocators for task types
-or types containing task subcomponents.
-
@item No_Task_Hierarchy
-[RM D.7] All (non-environment) tasks depend
-directly on the environment task of the partition.
-
@item No_Task_Termination
-Tasks which terminate are erroneous.
-
@item Simple_Barriers
-Entry barrier condition expressions shall be either static
-boolean expressions or boolean objects which are declared in
-the protected type which contains the entry.
@end table
@noindent
32-bit environment to a 64-bit environment. This pragma is ignored for non-VMS
versions.
+@node Pragma Simple_Storage_Pool_Type
+@unnumberedsec Pragma Simple_Storage_Pool_Type
+@findex Simple_Storage_Pool_Type
+@cindex Storage pool, simple
+@cindex Simple storage pool
+@noindent
+Syntax:
+
+@smallexample @c ada
+pragma Simple_Storage_Pool_Type (type_LOCAL_NAME);
+@end smallexample
+
+@noindent
+A type can be established as a ``simple storage pool type'' by applying
+the representation pragma @code{Simple_Storage_Pool_Type} to the type.
+A type named in the pragma must be a library-level immutably limited record
+type or limited tagged type declared immediately within a package declaration.
+The type can also be a limited private type whose full type is allowed as
+a simple storage pool type.
+
+For a simple storage pool type @var{SSP}, nonabstract primitive subprograms
+@code{Allocate}, @code{Deallocate}, and @code{Storage_Size} can be declared that
+are subtype conformant with the following subprogram declarations:
+
+@smallexample @c ada
+procedure Allocate
+ (Pool : in out SSP;
+ Storage_Address : out System.Address;
+ Size_In_Storage_Elements : System.Storage_Elements.Storage_Count;
+ Alignment : System.Storage_Elements.Storage_Count);
+
+procedure Deallocate
+ (Pool : in out SSP;
+ Storage_Address : System.Address;
+ Size_In_Storage_Elements : System.Storage_Elements.Storage_Count;
+ Alignment : System.Storage_Elements.Storage_Count);
+
+function Storage_Size (Pool : SSP)
+ return System.Storage_Elements.Storage_Count;
+@end smallexample
+
+@noindent
+Procedure @code{Allocate} must be declared, whereas @code{Deallocate} and
+@code{Storage_Size} are optional. If @code{Deallocate} is not declared, then
+applying an unchecked deallocation has no effect other than to set its actual
+parameter to null. If @code{Storage_Size} is not declared, then the
+@code{Storage_Size} attribute applied to an access type associated with
+a pool object of type SSP returns zero. Additional operations can be declared
+for a simple storage pool type (such as for supporting a mark/release
+storage-management discipline).
+
+An object of a simple storage pool type can be associated with an access
+type by specifying the attribute @code{Simple_Storage_Pool}. For example:
+
+@smallexample @c ada
+
+My_Pool : My_Simple_Storage_Pool_Type;
+
+type Acc is access My_Data_Type;
+
+for Acc'Simple_Storage_Pool use My_Pool;
+
+@end smallexample
+
+@noindent
+See attribute @code{Simple_Storage_Pool} for further details.
+
@node Pragma Source_File_Name
@unnumberedsec Pragma Source_File_Name
@findex Source_File_Name
* Result::
* Safe_Emax::
* Safe_Large::
+* Simple_Storage_Pool::
* Small::
* Storage_Unit::
* Stub_Type::
the Ada 83 reference manual for an exact description of the semantics of
this attribute.
+@node Simple_Storage_Pool
+@unnumberedsec Simple_Storage_Pool
+@cindex Storage pool, simple
+@cindex Simple storage pool
+@findex Simple_Storage_Pool
+@noindent
+For every nonformal, nonderived access-to-object type @var{Acc}, the
+representation attribute @code{Simple_Storage_Pool} may be specified
+via an attribute_definition_clause (or by specifying the equivalent aspect):
+
+@smallexample @c ada
+
+My_Pool : My_Simple_Storage_Pool_Type;
+
+type Acc is access My_Data_Type;
+
+for Acc'Simple_Storage_Pool use My_Pool;
+
+@end smallexample
+
+@noindent
+The name given in an attribute_definition_clause for the
+@code{Simple_Storage_Pool} attribute shall denote a variable of
+a ``simple storage pool type'' (see pragma @code{Simple_Storage_Pool_Type}).
+
+The use of this attribute is only allowed for a prefix denoting a type
+for which it has been specified. The type of the attribute is the type
+of the variable specified as the simple storage pool of the access type,
+and the attribute denotes that variable.
+
+It is illegal to specify both @code{Storage_Pool} and @code{Simple_Storage_Pool}
+for the same access type.
+
+If the @code{Simple_Storage_Pool} attribute has been specified for an access
+type, then applying the @code{Storage_Pool} attribute to the type is flagged
+with a warning and its evaluation raises the exception @code{Program_Error}.
+
+If the Simple_Storage_Pool attribute has been specified for an access
+type @var{S}, then the evaluation of the attribute @code{@var{S}'Storage_Size}
+returns the result of calling @code{Storage_Size (@var{S}'Simple_Storage_Pool)},
+which is intended to indicate the number of storage elements reserved for
+the simple storage pool. If the Storage_Size function has not been defined
+for the simple storage pool type, then this attribute returns zero.
+
+If an access type @var{S} has a specified simple storage pool of type
+@var{SSP}, then the evaluation of an allocator for that access type calls
+the primitive @code{Allocate} procedure for type @var{SSP}, passing
+@code{@var{S}'Simple_Storage_Pool} as the pool parameter. The detailed
+semantics of such allocators is the same as those defined for allocators
+in section 13.11 of the Ada Reference Manual, with the term
+``simple storage pool'' substituted for ``storage pool''.
+
+If an access type @var{S} has a specified simple storage pool of type
+@var{SSP}, then a call to an instance of the @code{Ada.Unchecked_Deallocation}
+for that access type invokes the primitive @code{Deallocate} procedure
+for type @var{SSP}, passing @code{@var{S}'Simple_Storage_Pool} as the pool
+parameter. The detailed semantics of such unchecked deallocations is the same
+as defined in section 13.11.2 of the Ada Reference Manual, except that the
+term ``simple storage pool'' is substituted for ``storage pool''.
+
@node Small
@unnumberedsec Small
@cindex Ada 83 attributes
@code{Standard'Word_Size} (@code{Standard} is the only permissible
prefix) provides the value @code{System.Word_Size}.
-@c ------------------------
-@node Implementation Advice
-@chapter Implementation Advice
+@node Implementation Defined Restrictions
+@chapter Implementation Defined Restrictions
+
@noindent
-The main text of the Ada Reference Manual describes the required
-behavior of all Ada compilers, and the GNAT compiler conforms to
-these requirements.
+All RM defined Restriction identifiers are implemented:
-In addition, there are sections throughout the Ada 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.
+@itemize @bullet
+@item language-defined restrictions (see 13.12.1)
+@item tasking restrictions (see D.7)
+@item high integrity restrictions (see H.4)
+@end itemize
-As far as practical, GNAT follows the implementation advice sections in
-the Ada 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.
+@noindent
+GNAT implements additional restriction identifiers. All restrictions, whether
+language defined or GNAT-specific, are listed in the following.
-@cindex Error detection
-@unnumberedsec 1.1.3(20): Error Detection
-@sp 1
-@cartouche
-If an implementation detects the use of an unsupported Specialized Needs
-Annex feature at run time, it should raise @code{Program_Error} if
-feasible.
-@end cartouche
-Not relevant. All specialized needs annex features are either supported,
-or diagnosed at compile time.
+@menu
+* Partition-Wide Restrictions::
+* Unit-Level Restrictions::
+@end menu
-@cindex Child Units
-@unnumberedsec 1.1.3(31): Child Units
-@sp 1
-@cartouche
-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.
-@end cartouche
-Followed.
+@node Partition-Wide Restrictions
+@section Partition-Wide Restrictions
-@cindex Bounded errors
-@unnumberedsec 1.1.5(12): Bounded Errors
-@sp 1
-@cartouche
-If an implementation detects a bounded error or erroneous
-execution, it should raise @code{Program_Error}.
-@end cartouche
-Followed in all cases in which the implementation detects a bounded
-error or erroneous execution. Not all such situations are detected at
-runtime.
+There are two separate lists of 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).
-@cindex Pragmas
-@unnumberedsec 2.8(16): Pragmas
-@sp 1
-@cartouche
-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.
-@end cartouche
-The following implementation defined pragmas are exceptions to this
-rule:
+@menu
+* Immediate_Reclamation::
+* Max_Asynchronous_Select_Nesting::
+* Max_Entry_Queue_Length::
+* Max_Protected_Entries::
+* Max_Select_Alternatives::
+* Max_Storage_At_Blocking::
+* Max_Task_Entries::
+* Max_Tasks::
+* No_Abort_Statements::
+* No_Access_Parameter_Allocators::
+* No_Access_Subprograms::
+* No_Allocators::
+* No_Anonymous_Allocators::
+* No_Calendar::
+* No_Coextensions::
+* No_Default_Initialization::
+* No_Delay::
+* No_Dependence::
+* No_Direct_Boolean_Operators::
+* No_Dispatch::
+* No_Dispatching_Calls::
+* No_Dynamic_Attachment::
+* No_Dynamic_Priorities::
+* No_Entry_Calls_In_Elaboration_Code::
+* No_Enumeration_Maps::
+* No_Exception_Handlers::
+* No_Exception_Propagation::
+* No_Exception_Registration::
+* No_Exceptions::
+* No_Finalization::
+* No_Fixed_Point::
+* No_Floating_Point::
+* No_Implicit_Conditionals::
+* No_Implicit_Dynamic_Code::
+* No_Implicit_Heap_Allocations::
+* No_Implicit_Loops::
+* No_Initialize_Scalars::
+* No_IO::
+* No_Local_Allocators::
+* No_Local_Protected_Objects::
+* No_Local_Timing_Events::
+* No_Nested_Finalization::
+* No_Protected_Type_Allocators::
+* No_Protected_Types::
+* No_Relative_Delay::
+* No_Requeue_Statements::
+* No_Secondary_Stack::
+* No_Select_Statements::
+* No_Specific_Termination_Handlers::
+* No_Specification_of_Aspect::
+* No_Standard_Allocators_After_Elaboration::
+* No_Standard_Storage_Pools::
+* No_Stream_Optimizations::
+* No_Streams::
+* No_Task_Allocators::
+* No_Task_Attributes_Package::
+* No_Task_Hierarchy::
+* No_Tasking::
+* No_Terminate_Alternatives::
+* No_Unchecked_Access::
+* Simple_Barriers::
+* Static_Priorities::
+* Static_Storage_Size::
+@end menu
-@table @code
-@item Abort_Defer
-Affects semantics
-@item Ada_83
-Affects legality
-@item Assert
-Affects semantics
-@item CPP_Class
-Affects semantics
-@item CPP_Constructor
-Affects semantics
-@item Debug
-Affects semantics
-@item Interface_Name
-Affects semantics
-@item Machine_Attribute
-Affects semantics
-@item Unimplemented_Unit
-Affects legality
-@item Unchecked_Union
-Affects semantics
-@end table
+@node Immediate_Reclamation
+@unnumberedsubsec Immediate_Reclamation
+@findex Immediate_Reclamation
+[RM H.4] This restriction ensures that, except for storage occupied by
+objects created by allocators and not deallocated via unchecked
+deallocation, any storage reserved at run time for an object is
+immediately reclaimed when the object no longer exists.
+
+@node Max_Asynchronous_Select_Nesting
+@unnumberedsubsec Max_Asynchronous_Select_Nesting
+@findex Max_Asynchronous_Select_Nesting
+[RM D.7] Specifies the maximum dynamic nesting level of asynchronous
+selects. Violations of this restriction with a value of zero are
+detected at compile time. Violations of this restriction with values
+other than zero cause Storage_Error to be raised.
+
+@node Max_Entry_Queue_Length
+@unnumberedsubsec Max_Entry_Queue_Length
+@findex Max_Entry_Queue_Length
+[RM D.7] 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.
+Note that this restriction is checked at run time. Violation of this
+restriction results in the raising of Program_Error exception at the point of
+the call.
-@noindent
-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.
+@node Max_Protected_Entries
+@unnumberedsubsec Max_Protected_Entries
+@findex Max_Protected_Entries
+[RM D.7] Specifies the maximum number of entries per protected type. The
+bounds of every entry family of a protected unit shall be static, or shall be
+defined by a discriminant of a subtype whose corresponding bound is static.
-@unnumberedsec 2.8(17-19): Pragmas
-@sp 1
-@cartouche
-Normally, an implementation should not define pragmas that can
-make an illegal program legal, except as follows:
-@end cartouche
-@sp 1
-@cartouche
-A pragma used to complete a declaration, such as a pragma @code{Import};
-@end cartouche
-@sp 1
-@cartouche
-A pragma used to configure the environment by adding, removing, or
-replacing @code{library_items}.
-@end cartouche
-See response to paragraph 16 of this same section.
+@node Max_Select_Alternatives
+@unnumberedsubsec Max_Select_Alternatives
+@findex Max_Select_Alternatives
+[RM D.7] Specifies the maximum number of alternatives in a selective accept.
+
+@node Max_Storage_At_Blocking
+@unnumberedsubsec Max_Storage_At_Blocking
+@findex Max_Storage_At_Blocking
+[RM D.7] Specifies the maximum portion (in storage elements) of a task's
+Storage_Size that can be retained by a blocked task. A violation of this
+restriction causes Storage_Error to be raised.
+
+@node Max_Task_Entries
+@unnumberedsubsec Max_Task_Entries
+@findex Max_Task_Entries
+[RM D.7] Specifies the maximum number of entries
+per task. The bounds of every entry family
+of a task unit shall be static, or shall be
+defined by a discriminant of a subtype whose
+corresponding bound is static.
+
+@node Max_Tasks
+@unnumberedsubsec Max_Tasks
+@findex Max_Tasks
+[RM D.7] Specifies the maximum number of task that may be created, not
+counting the creation of the environment task. Violations of this
+restriction with a value of zero are detected at compile
+time. Violations of this restriction with values other than zero cause
+Storage_Error to be raised.
+
+@node No_Abort_Statements
+@unnumberedsubsec No_Abort_Statements
+@findex No_Abort_Statements
+[RM D.7] There are no abort_statements, and there are
+no calls to Task_Identification.Abort_Task.
-@cindex Character Sets
-@cindex Alternative Character Sets
-@unnumberedsec 3.5.2(5): Alternative Character Sets
-@sp 1
-@cartouche
-If an implementation supports a mode with alternative interpretations
-for @code{Character} and @code{Wide_Character}, the set of graphic
-characters of @code{Character} should nevertheless remain a proper
-subset of the set of graphic characters of @code{Wide_Character}. Any
-character set ``localizations'' should be reflected in the results of
-the subprograms defined in the language-defined package
-@code{Characters.Handling} (see A.3) available in such a mode. In a mode with
-an alternative interpretation of @code{Character}, the implementation should
-also support a corresponding change in what is a legal
-@code{identifier_letter}.
-@end cartouche
-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.
+@node No_Access_Parameter_Allocators
+@unnumberedsubsec No_Access_Parameter_Allocators
+@findex No_Access_Parameter_Allocators
+[RM H.4] This restriction ensures at compile time that there are no
+occurrences of an allocator as the actual parameter to an access
+parameter.
+
+@node No_Access_Subprograms
+@unnumberedsubsec No_Access_Subprograms
+@findex No_Access_Subprograms
+[RM H.4] This restriction ensures at compile time that there are no
+declarations of access-to-subprogram types.
+
+@node No_Allocators
+@unnumberedsubsec No_Allocators
+@findex No_Allocators
+[RM H.4] This restriction ensures at compile time that there are no
+occurrences of an allocator.
+
+@node No_Anonymous_Allocators
+@unnumberedsubsec No_Anonymous_Allocators
+@findex No_Anonymous_Allocators
+[RM H.4] This restriction ensures at compile time that there are no
+occurrences of an allocator of anonymous access type.
+
+@node No_Calendar
+@unnumberedsubsec No_Calendar
+@findex No_Calendar
+[GNAT] This restriction ensures at compile time that there is no implicit or
+explicit dependence on the package @code{Ada.Calendar}.
-@cindex Integer types
-@unnumberedsec 3.5.4(28): Integer Types
+@node No_Coextensions
+@unnumberedsubsec No_Coextensions
+@findex No_Coextensions
+[RM H.4] This restriction ensures at compile time that there are no
+coextensions. See 3.10.2.
-@sp 1
-@cartouche
-An implementation should support @code{Long_Integer} in addition to
-@code{Integer} if the target machine supports 32-bit (or longer)
-arithmetic. No other named integer subtypes are recommended for package
-@code{Standard}. Instead, appropriate named integer subtypes should be
-provided in the library package @code{Interfaces} (see B.2).
-@end cartouche
-@code{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.
-@unnumberedsec 3.5.4(29): Integer Types
+@node No_Default_Initialization
+@unnumberedsubsec No_Default_Initialization
+@findex No_Default_Initialization
-@sp 1
-@cartouche
-An implementation for a two's complement machine should support
-modular types with a binary modulus up to @code{System.Max_Int*2+2}. An
-implementation should support a non-binary modules up to @code{Integer'Last}.
-@end cartouche
-Followed.
+[GNAT] This restriction prohibits any instance of default initialization
+of variables. The binder implements a consistency rule which prevents
+any unit compiled without the restriction from with'ing a unit with the
+restriction (this allows the generation of initialization procedures to
+be skipped, since you can be sure that no call is ever generated to an
+initialization procedure in a unit with the restriction active). If used
+in conjunction with Initialize_Scalars or Normalize_Scalars, the effect
+is to prohibit all cases of variables declared without a specific
+initializer (including the case of OUT scalar parameters).
+
+@node No_Delay
+@unnumberedsubsec No_Delay
+@findex No_Delay
+[RM H.4] This restriction ensures at compile time that there are no
+delay statements and no dependences on package Calendar.
+
+@node No_Dependence
+@unnumberedsubsec No_Dependence
+@findex No_Dependence
+[RM 13.12.1] This restriction checks at compile time that there are no
+dependence on a library unit.
+
+@node No_Direct_Boolean_Operators
+@unnumberedsubsec No_Direct_Boolean_Operators
+@findex No_Direct_Boolean_Operators
+[GNAT] This restriction ensures that no logical (and/or/xor) 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.
-@cindex Enumeration values
-@unnumberedsec 3.5.5(8): Enumeration Values
-@sp 1
-@cartouche
-For the evaluation of a call on @code{@var{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
-@code{Program_Error}. This is particularly important for enumeration
-types with noncontiguous internal codes specified by an
-enumeration_representation_clause.
-@end cartouche
-Followed.
+@node No_Dispatch
+@unnumberedsubsec No_Dispatch
+@findex No_Dispatch
+[RM H.4] This restriction ensures at compile time that there are no
+occurrences of @code{T'Class}, for any (tagged) subtype @code{T}.
-@cindex Float types
-@unnumberedsec 3.5.7(17): Float Types
-@sp 1
-@cartouche
-An implementation should support @code{Long_Float} in addition to
-@code{Float} if the target machine supports 11 or more digits of
-precision. No other named floating point subtypes are recommended for
-package @code{Standard}. Instead, appropriate named floating point subtypes
-should be provided in the library package @code{Interfaces} (see B.2).
-@end cartouche
-@code{Short_Float} and @code{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 @code{Long_Float}, but on some machines, it will
-correspond to the IEEE extended form. The notable case is all ia32
-(x86) implementations, where @code{Long_Long_Float} corresponds to
-the 80-bit extended precision format supported in hardware on this
-processor. Note that the 128-bit format on SPARC is not supported,
-since this is a software rather than a hardware format.
+@node No_Dispatching_Calls
+@unnumberedsubsec No_Dispatching_Calls
+@findex No_Dispatching_Calls
+[GNAT] 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
+@code{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.
-@cindex Multidimensional arrays
-@cindex Arrays, multidimensional
-@unnumberedsec 3.6.2(11): Multidimensional Arrays
-@sp 1
-@cartouche
-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 @code{Convention}
-(@code{Fortran}, @dots{}) applies to a multidimensional array type, then
-column-major order should be used instead (see B.5, ``Interfacing with
-Fortran'').
-@end cartouche
-Followed.
+@smallexample
+package Pkg is
+ type T is tagged record
+ Data : Natural;
+ end record;
+ procedure P (X : T);
-@findex Duration'Small
-@unnumberedsec 9.6(30-31): Duration'Small
-@sp 1
-@cartouche
-Whenever possible in an implementation, the value of @code{Duration'Small}
-should be no greater than 100 microseconds.
-@end cartouche
-Followed. (@code{Duration'Small} = 10**(@minus{}9)).
+ type DT is new T with record
+ More_Data : Natural;
+ end record;
+ procedure Q (X : DT);
+end Pkg;
-@sp 1
-@cartouche
-The time base for @code{delay_relative_statements} should be monotonic;
-it need not be the same time base as used for @code{Calendar.Clock}.
-@end cartouche
-Followed.
+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;
-@unnumberedsec 10.2.1(12): Consistent Representation
-@sp 1
-@cartouche
-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.
-@end cartouche
-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.
+ Obj : DT;
+begin
+ P (Obj); -- OK : Direct call
+ P (T (Obj)); -- OK : Type conversion plus direct call
+ P (T'Class (Obj)); -- Error: Dispatching call
-@cindex Exception information
-@unnumberedsec 11.4.1(19): Exception Information
-@sp 1
-@cartouche
-@code{Exception_Message} by default and @code{Exception_Information}
-should produce information useful for
-debugging. @code{Exception_Message} should be short, about one
-line. @code{Exception_Information} can be long. @code{Exception_Message}
-should not include the
-@code{Exception_Name}. @code{Exception_Information} should include both
-the @code{Exception_Name} and the @code{Exception_Message}.
-@end cartouche
-Followed. For each exception that doesn't have a specified
-@code{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 @code{Discard_Names}.
+ Test (Obj); -- OK : Type conversion
-@cindex Suppression of checks
-@cindex Checks, suppression of
-@unnumberedsec 11.5(28): Suppression of Checks
-@sp 1
-@cartouche
-The implementation should minimize the code executed for checks that
-have been suppressed.
-@end cartouche
-Followed.
+ if Obj in T'Class then -- OK : Membership test
+ null;
+ end if;
+end Example;
+@end smallexample
-@cindex Representation clauses
-@unnumberedsec 13.1 (21-24): Representation Clauses
-@sp 1
-@cartouche
-The recommended level of support for all representation items is
-qualified as follows:
-@end cartouche
-@sp 1
-@cartouche
-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.
-@end cartouche
-Followed. In fact, GNAT goes beyond the recommended level of support
-by allowing nonstatic expressions in some representation clauses even
-without the need to declare constants initialized with the values of
-such expressions.
-For example:
+@node No_Dynamic_Attachment
+@unnumberedsubsec No_Dynamic_Attachment
+@findex No_Dynamic_Attachment
+[RM D.7] This restriction ensures that there is no call to any of the
+operations defined in package Ada.Interrupts
+(Is_Reserved, Is_Attached, Current_Handler, Attach_Handler, Exchange_Handler,
+Detach_Handler, and Reference).
+
+@node No_Dynamic_Priorities
+@unnumberedsubsec No_Dynamic_Priorities
+@findex No_Dynamic_Priorities
+[RM D.7] There are no semantic dependencies on the package Dynamic_Priorities.
+
+@node No_Entry_Calls_In_Elaboration_Code
+@unnumberedsubsec No_Entry_Calls_In_Elaboration_Code
+@findex No_Entry_Calls_In_Elaboration_Code
+[GNAT] 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.
+
+@node No_Enumeration_Maps
+@unnumberedsubsec No_Enumeration_Maps
+@findex No_Enumeration_Maps
+[GNAT] This restriction ensures at compile time that no operations requiring
+enumeration maps are used (that is Image and Value attributes applied
+to enumeration types).
+
+@node No_Exception_Handlers
+@unnumberedsubsec No_Exception_Handlers
+@findex No_Exception_Handlers
+[GNAT] 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:
@smallexample @c ada
- X : Integer;
- Y : Float;
- for Y'Address use X'Address;>>
+procedure Last_Chance_Handler
+ (Source_Location : System.Address; Line : Integer);
+pragma Export (C, Last_Chance_Handler,
+ "__gnat_last_chance_handler");
@end smallexample
-@sp 1
-@cartouche
-An implementation need not support a specification for the @code{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.
-@end cartouche
-Followed. Size Clauses are not permitted on non-static components, as
-described above.
+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.
-@sp 1
-@cartouche
-An aliased component, or a component whose type is by-reference, should
-always be allocated at an addressable location.
-@end cartouche
-Followed.
+@node No_Exception_Propagation
+@unnumberedsubsec No_Exception_Propagation
+@findex No_Exception_Propagation
+[GNAT] 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.
-@cindex Packed types
-@unnumberedsec 13.2(6-8): Packed Types
-@sp 1
-@cartouche
-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.
-@end cartouche
-@sp 1
-@cartouche
-The recommended level of support pragma @code{Pack} is:
+@node No_Exception_Registration
+@unnumberedsubsec No_Exception_Registration
+@findex No_Exception_Registration
+[GNAT] 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.
-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 @code{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 @code{Size} is
-greater than the word size may be allocated an integral number of words.
-@end cartouche
-Followed. Tight packing of arrays is supported for all component sizes
-up to 64-bits. If the array component size is 1 (that is to say, if
-the component is a boolean type or an enumeration type with two values)
-then values of the type are implicitly initialized to zero. This
-happens both for objects of the packed type, and for objects that have a
-subcomponent of the packed type.
+@node No_Exceptions
+@unnumberedsubsec No_Exceptions
+@findex No_Exceptions
+[RM H.4] This restriction ensures at compile time that there are no
+raise statements and no exception handlers.
-@sp 1
-@cartouche
-An implementation should support Address clauses for imported
-subprograms.
-@end cartouche
-Followed.
-@cindex @code{Address} clauses
-@unnumberedsec 13.3(14-19): Address Clauses
+@node No_Finalization
+@unnumberedsubsec No_Finalization
+@findex No_Finalization
+[GNAT] This restriction disables the language features described in
+chapter 7.6 of the Ada 2005 RM as well as all form of code generation
+performed by the compiler to support these features. The following types
+are no longer considered controlled when this restriction is in effect:
+@itemize @bullet
+@item
+@code{Ada.Finalization.Controlled}
+@item
+@code{Ada.Finalization.Limited_Controlled}
+@item
+Derivations from @code{Controlled} or @code{Limited_Controlled}
+@item
+Class-wide types
+@item
+Protected types
+@item
+Task types
+@item
+Array and record types with controlled components
+@end itemize
+The compiler no longer generates code to initialize, finalize or adjust an
+object or a nested component, either declared on the stack or on the heap. The
+deallocation of a controlled object no longer finalizes its contents.
+
+@node No_Fixed_Point
+@unnumberedsubsec No_Fixed_Point
+@findex No_Fixed_Point
+[RM H.4] This restriction ensures at compile time that there are no
+occurrences of fixed point types and operations.
+
+@node No_Floating_Point
+@unnumberedsubsec No_Floating_Point
+@findex No_Floating_Point
+[RM H.4] This restriction ensures at compile time that there are no
+occurrences of floating point types and operations.
+
+@node No_Implicit_Conditionals
+@unnumberedsubsec No_Implicit_Conditionals
+@findex No_Implicit_Conditionals
+[GNAT] 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.
+
+@node No_Implicit_Dynamic_Code
+@unnumberedsubsec No_Implicit_Dynamic_Code
+@findex No_Implicit_Dynamic_Code
+@cindex trampoline
+[GNAT] 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: @code{Access},
+@code{Unrestricted_Access}, or @code{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.
+Trampolines are also quite slow at run time.
+
+On many targets, trampolines have been largely eliminated. Look at the
+version of system.ads for your target --- if it has
+Always_Compatible_Rep equal to False, then trampolines are largely
+eliminated. In particular, a trampoline is built for the following
+features: @code{Address} of a nested subprogram;
+@code{Access} or @code{Unrestricted_Access} of a nested subprogram,
+but only if pragma Favor_Top_Level applies, or the access type has a
+foreign-language convention; primitive operations of nested tagged
+types.
+
+@node No_Implicit_Heap_Allocations
+@unnumberedsubsec No_Implicit_Heap_Allocations
+@findex No_Implicit_Heap_Allocations
+[RM D.7] No constructs are allowed to cause implicit heap allocation.
+
+@node No_Implicit_Loops
+@unnumberedsubsec No_Implicit_Loops
+@findex No_Implicit_Loops
+[GNAT] This restriction ensures that the generated code does not contain any
+implicit @code{for} loops, either by modifying
+the generated code where possible,
+or by rejecting any construct that would otherwise generate an implicit
+@code{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.
+
+@node No_Initialize_Scalars
+@unnumberedsubsec No_Initialize_Scalars
+@findex No_Initialize_Scalars
+[GNAT] 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.
+
+@node No_IO
+@unnumberedsubsec No_IO
+@findex No_IO
+[RM H.4] This restriction ensures at compile time that there are no
+dependences on any of the library units Sequential_IO, Direct_IO,
+Text_IO, Wide_Text_IO, Wide_Wide_Text_IO, or Stream_IO.
+
+@node No_Local_Allocators
+@unnumberedsubsec No_Local_Allocators
+@findex No_Local_Allocators
+[RM H.4] This restriction ensures at compile time that there are no
+occurrences of an allocator in subprograms, generic subprograms, tasks,
+and entry bodies.
+
+@node No_Local_Protected_Objects
+@unnumberedsubsec No_Local_Protected_Objects
+@findex No_Local_Protected_Objects
+[RM D.7] This restriction ensures at compile time that protected objects are
+only declared at the library level.
+
+@node No_Local_Timing_Events
+@unnumberedsubsec No_Local_Timing_Events
+@findex No_Local_Timing_Events
+[RM D.7] All objects of type Ada.Timing_Events.Timing_Event are
+declared at the library level.
+
+@node No_Nested_Finalization
+@unnumberedsubsec No_Nested_Finalization
+@findex No_Nested_Finalization
+[RM D.7] All objects requiring finalization are declared at the library level.
+
+@node No_Protected_Type_Allocators
+@unnumberedsubsec No_Protected_Type_Allocators
+@findex No_Protected_Type_Allocators
+[RM D.7] This restriction ensures at compile time that there are no allocator
+expressions that attempt to allocate protected objects.
+
+@node No_Protected_Types
+@unnumberedsubsec No_Protected_Types
+@findex No_Protected_Types
+[RM H.4] This restriction ensures at compile time that there are no
+declarations of protected types or protected objects.
+
+@node No_Relative_Delay
+@unnumberedsubsec No_Relative_Delay
+@findex No_Relative_Delay
+[RM D.7] This restriction ensures at compile time that there are no delay
+relative statements and prevents expressions such as @code{delay 1.23;} from
+appearing in source code.
+
+@node No_Requeue_Statements
+@unnumberedsubsec No_Requeue_Statements
+@findex No_Requeue_Statements
+[RM D.7] This restriction ensures at compile time that no requeue statements
+are permitted and prevents keyword @code{requeue} from being used in source
+code.
+
+@node No_Secondary_Stack
+@unnumberedsubsec No_Secondary_Stack
+@findex No_Secondary_Stack
+[GNAT] 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.
+
+@node No_Select_Statements
+@unnumberedsubsec No_Select_Statements
+@findex No_Select_Statements
+[RM D.7] This restriction ensures at compile time no select statements of any
+kind are permitted, that is the keyword @code{select} may not appear.
+
+@node No_Specific_Termination_Handlers
+@unnumberedsubsec No_Specific_Termination_Handlers
+@findex No_Specific_Termination_Handlers
+[RM D.7] There are no calls to Ada.Task_Termination.Set_Specific_Handler
+or to Ada.Task_Termination.Specific_Handler.
+
+@node No_Specification_of_Aspect
+@unnumberedsubsec No_Specification_of_Aspect
+@findex No_Specification_of_Aspect
+[RM 13.12.1] This restriction checks at compile time that no aspect
+specification, attribute definition clause, or pragma is given for a
+given aspect.
+
+@node No_Standard_Allocators_After_Elaboration
+@unnumberedsubsec No_Standard_Allocators_After_Elaboration
+@findex No_Standard_Allocators_After_Elaboration
+[RM D.7] Specifies that an allocator using a standard storage pool
+should never be evaluated at run time after the elaboration of the
+library items of the partition has completed. Otherwise, Storage_Error
+is raised.
+
+@node No_Standard_Storage_Pools
+@unnumberedsubsec No_Standard_Storage_Pools
+@findex No_Standard_Storage_Pools
+[GNAT] 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.
+
+@node No_Stream_Optimizations
+@unnumberedsubsec No_Stream_Optimizations
+@findex No_Stream_Optimizations
+[GNAT] This restriction affects the performance of stream operations on types
+@code{String}, @code{Wide_String} and @code{Wide_Wide_String}. By default, the
+compiler uses block reads and writes when manipulating @code{String} objects
+due to their supperior performance. When this restriction is in effect, the
+compiler performs all IO operations on a per-character basis.
+
+@node No_Streams
+@unnumberedsubsec No_Streams
+@findex No_Streams
+[GNAT] This restriction ensures at compile/bind time that there are no
+stream objects created and no use of stream attributes.
+This restriction does not forbid dependences on the package
+@code{Ada.Streams}. So it is permissible to with
+@code{Ada.Streams} (or another package that does so itself)
+as long as no actual stream objects are created and no
+stream attributes are used.
+
+Note that the use of restriction allows optimization of tagged types,
+since they do not need to worry about dispatching stream operations.
+To take maximum advantage of this space-saving optimization, any
+unit declaring a tagged type should be compiled with the restriction,
+though this is not required.
+
+@node No_Task_Allocators
+@unnumberedsubsec No_Task_Allocators
+@findex No_Task_Allocators
+[RM D.7] There are no allocators for task types
+or types containing task subcomponents.
+
+@node No_Task_Attributes_Package
+@unnumberedsubsec No_Task_Attributes_Package
+@findex No_Task_Attributes_Package
+[GNAT] This restriction ensures at compile time that there are no implicit or
+explicit dependencies on the package @code{Ada.Task_Attributes}.
+
+@node No_Task_Hierarchy
+@unnumberedsubsec No_Task_Hierarchy
+@findex No_Task_Hierarchy
+[RM D.7] All (non-environment) tasks depend
+directly on the environment task of the partition.
+
+@node No_Tasking
+@unnumberedsubsec No_Tasking
+@findex No_Tasking
+[GNAT] This restriction prevents the declaration of tasks or task types
+throughout the partition. It is similar in effect to the use of
+@code{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.
+
+@node No_Terminate_Alternatives
+@unnumberedsubsec No_Terminate_Alternatives
+@findex No_Terminate_Alternatives
+[RM D.7] There are no selective accepts with terminate alternatives.
+
+@node No_Unchecked_Access
+@unnumberedsubsec No_Unchecked_Access
+@findex No_Unchecked_Access
+[RM H.4] This restriction ensures at compile time that there are no
+occurrences of the Unchecked_Access attribute.
+
+@node Simple_Barriers
+@unnumberedsubsec Simple_Barriers
+@findex Simple_Barriers
+[RM D.7] 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.
+
+@node Static_Priorities
+@unnumberedsubsec Static_Priorities
+@findex Static_Priorities
+[GNAT] This restriction ensures at compile time that all priority expressions
+are static, and that there are no dependences on the package
+@code{Ada.Dynamic_Priorities}.
+
+@node Static_Storage_Size
+@unnumberedsubsec Static_Storage_Size
+@findex Static_Storage_Size
+[GNAT] This restriction ensures at compile time that any expression appearing
+in a Storage_Size pragma or attribute definition clause is static.
+
+@node Unit-Level Restrictions
+@section Unit-Level Restrictions
+
+@noindent
+The second set of 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.
+
+@menu
+* No_Elaboration_Code::
+* No_Entry_Queue::
+* No_Implementation_Aspect_Specifications::
+* No_Implementation_Attributes::
+* No_Implementation_Identifiers::
+* No_Implementation_Pragmas::
+* No_Implementation_Restrictions::
+* No_Implementation_Units::
+* No_Implicit_Aliasing::
+* No_Obsolescent_Features::
+* No_Recursion::
+* No_Reentrancy::
+* No_Wide_Characters::
+* SPARK::
+* No_Task_Termination::
+@end menu
+
+@node No_Elaboration_Code
+@unnumberedsubsec No_Elaboration_Code
+@findex No_Elaboration_Code
+[GNAT] 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 @code{Preelaborate}. There are cases in which pragma
+@code{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 @code{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 @code{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:
+
+@smallexample
+ Val : constant Integer := X;
+@end smallexample
+
+@noindent
+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.
+
+@node No_Entry_Queue
+@unnumberedsubsec No_Entry_Queue
+@findex No_Entry_Queue
+[GNAT] 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.
+
+@node No_Implementation_Aspect_Specifications
+@unnumberedsubsec No_Implementation_Aspect_Specifications
+@findex No_Implementation_Aspect_Specifications
+[RM 13.12.1] This restriction checks at compile time that no
+GNAT-defined aspects are present. With this restriction, the only
+aspects that can be used are those defined in the Ada Reference Manual.
+
+@node No_Implementation_Attributes
+@unnumberedsubsec No_Implementation_Attributes
+@findex No_Implementation_Attributes
+[RM 13.12.1] 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.
+
+@node No_Implementation_Identifiers
+@unnumberedsubsec No_Implementation_Identifiers
+@findex No_Implementation_Identifiers
+[RM 13.12.1] This restriction checks at compile time that no
+implementation-defined identifiers occur within language-defined
+packages.
+
+@node No_Implementation_Pragmas
+@unnumberedsubsec No_Implementation_Pragmas
+@findex No_Implementation_Pragmas
+[RM 13.12.1] 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.
+
+@node No_Implementation_Restrictions
+@unnumberedsubsec No_Implementation_Restrictions
+@findex No_Implementation_Restrictions
+[GNAT] This restriction checks at compile time that no GNAT-defined restriction
+identifiers (other than @code{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.
+
+@node No_Implementation_Units
+@unnumberedsubsec No_Implementation_Units
+@findex No_Implementation_Units
+[RM 13.12.1] This restriction checks at compile time that there is no
+mention in the context clause of any implementation-defined descendants
+of packages Ada, Interfaces, or System.
+
+@node No_Implicit_Aliasing
+@unnumberedsubsec No_Implicit_Aliasing
+@findex No_Implicit_Aliasing
+[GNAT] This restriction, which is not required to be partition-wide consistent,
+requires an explicit aliased keyword for an object to which 'Access,
+'Unchecked_Access, or 'Address is applied, and forbids entirely the use of
+the 'Unrestricted_Access attribute for objects. Note: the reason that
+Unrestricted_Access is forbidden is that it would require the prefix
+to be aliased, and in such cases, it can always be replaced by
+the standard attribute Unchecked_Access which is preferable.
+
+@node No_Obsolescent_Features
+@unnumberedsubsec No_Obsolescent_Features
+@findex No_Obsolescent_Features
+[RM 13.12.1] This restriction checks at compile time that no obsolescent
+features are used, as defined in Annex J of the Ada Reference Manual.
+
+@node No_Recursion
+@unnumberedsubsec No_Recursion
+@findex No_Recursion
+[RM H.4] A program execution is erroneous if a subprogram is invoked as
+part of its execution.
+
+@node No_Reentrancy
+@unnumberedsubsec No_Reentrancy
+@findex No_Reentrancy
+[RM H.4] A program execution is erroneous if a subprogram is executed by
+two tasks at the same time.
+
+@node No_Wide_Characters
+@unnumberedsubsec No_Wide_Characters
+@findex No_Wide_Characters
+[GNAT] This restriction ensures at compile time that no uses of the types
+@code{Wide_Character} or @code{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 @code{Character}.
+
+@node SPARK
+@unnumberedsubsec SPARK
+@findex SPARK
+[GNAT] This restriction checks at compile time that some constructs
+forbidden in SPARK are not present. The SPARK version used as a
+reference is the same as the Ada mode for the unit, so a unit compiled
+in Ada 95 mode with SPARK restrictions will be checked for constructs
+forbidden in SPARK 95. Error messages related to SPARK restriction have
+the form:
+
+@smallexample
+violation of restriction "SPARK" at <file>
+ <error message>
+@end smallexample
+
+This is not a replacement for the semantic checks performed by the
+SPARK Examiner tool, as the compiler only deals currently with code,
+not at all with SPARK annotations and does not guarantee catching all
+cases of constructs forbidden by SPARK.
+
+Thus it may well be the case that code which
+passes the compiler in SPARK mode is rejected by the SPARK Examiner,
+e.g. due to the different visibility rules of the Examiner based on
+SPARK @code{inherit} annotations.
-@sp 1
-@cartouche
-For an array @var{X}, @code{@var{X}'Address} should point at the first
-component of the array, and not at the array bounds.
-@end cartouche
-Followed.
+This restriction can be useful in providing an initial filter for
+code developed using SPARK, or in examining legacy code to see how far
+it is from meeting SPARK restrictions.
-@sp 1
-@cartouche
-The recommended level of support for the @code{Address} attribute is:
+@node No_Task_Termination
+@unnumberedsubsec No_Task_Termination
+@findex No_Task_Termination
+[RM D.7] Tasks which terminate are erroneous.
-@code{@var{X}'Address} should produce a useful result if @var{X} is an
-object that is aliased or of a by-reference type, or is an entity whose
-@code{Address} has been specified.
-@end cartouche
-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.
+@c ------------------------
+@node Implementation Advice
+@chapter Implementation Advice
+@noindent
+The main text of the Ada Reference Manual describes the required
+behavior of all Ada compilers, and the GNAT compiler conforms to
+these requirements.
-@sp 1
-@cartouche
-An implementation should support @code{Address} clauses for imported
-subprograms.
-@end cartouche
-Followed.
+In addition, there are sections throughout the Ada 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.
-@sp 1
-@cartouche
-Objects (including subcomponents) that are aliased or of a by-reference
-type should be allocated on storage element boundaries.
-@end cartouche
-Followed.
+As far as practical, GNAT follows the implementation advice sections in
+the Ada 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.
+@cindex Error detection
+@unnumberedsec 1.1.3(20): Error Detection
@sp 1
@cartouche
-If the @code{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.
+If an implementation detects the use of an unsupported Specialized Needs
+Annex feature at run time, it should raise @code{Program_Error} if
+feasible.
@end cartouche
-Followed.
+Not relevant. All specialized needs annex features are either supported,
+or diagnosed at compile time.
-@cindex @code{Alignment} clauses
-@unnumberedsec 13.3(29-35): Alignment Clauses
+@cindex Child Units
+@unnumberedsec 1.1.3(31): Child Units
@sp 1
@cartouche
-The recommended level of support for the @code{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:
+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.
@end cartouche
Followed.
+@cindex Bounded errors
+@unnumberedsec 1.1.5(12): Bounded Errors
@sp 1
@cartouche
-An implementation need not support specified @code{Alignment}s for
-combinations of @code{Size}s and @code{Alignment}s that cannot be easily
-loaded and stored by available machine instructions.
+If an implementation detects a bounded error or erroneous
+execution, it should raise @code{Program_Error}.
@end cartouche
-Followed.
+Followed in all cases in which the implementation detects a bounded
+error or erroneous execution. Not all such situations are detected at
+runtime.
+@cindex Pragmas
+@unnumberedsec 2.8(16): Pragmas
@sp 1
@cartouche
-An implementation need not support specified @code{Alignment}s that are
-greater than the maximum @code{Alignment} the implementation ever returns by
-default.
+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.
@end cartouche
-Followed.
+The following implementation defined pragmas are exceptions to this
+rule:
-@sp 1
-@cartouche
-The recommended level of support for the @code{Alignment} attribute for
-objects is:
+@table @code
+@item Abort_Defer
+Affects semantics
+@item Ada_83
+Affects legality
+@item Assert
+Affects semantics
+@item CPP_Class
+Affects semantics
+@item CPP_Constructor
+Affects semantics
+@item Debug
+Affects semantics
+@item Interface_Name
+Affects semantics
+@item Machine_Attribute
+Affects semantics
+@item Unimplemented_Unit
+Affects legality
+@item Unchecked_Union
+Affects semantics
+@end table
-Same as above, for subtypes, but in addition:
-@end cartouche
-Followed.
+@noindent
+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.
+@unnumberedsec 2.8(17-19): Pragmas
@sp 1
@cartouche
-For stand-alone library-level objects of statically constrained
-subtypes, the implementation should support all @code{Alignment}s
-supported by the target linker. For example, page alignment is likely to
-be supported for such objects, but not for subtypes.
+Normally, an implementation should not define pragmas that can
+make an illegal program legal, except as follows:
@end cartouche
-Followed.
-
-@cindex @code{Size} clauses
-@unnumberedsec 13.3(42-43): Size Clauses
@sp 1
@cartouche
-The recommended level of support for the @code{Size} attribute of
-objects is:
-
-A @code{Size} clause should be supported for an object if the specified
-@code{Size} is at least as large as its subtype's @code{Size}, and
-corresponds to a size in storage elements that is a multiple of the
-object's @code{Alignment} (if the @code{Alignment} is nonzero).
+A pragma used to complete a declaration, such as a pragma @code{Import};
@end cartouche
-Followed.
-
-@unnumberedsec 13.3(50-56): Size Clauses
@sp 1
@cartouche
-If the @code{Size} of a subtype is specified, and allows for efficient
-independent addressability (see 9.10) on the target architecture, then
-the @code{Size} of the following objects of the subtype should equal the
-@code{Size} of the subtype:
-
-Aliased objects (including components).
+A pragma used to configure the environment by adding, removing, or
+replacing @code{library_items}.
@end cartouche
-Followed.
+See response to paragraph 16 of this same section.
+@cindex Character Sets
+@cindex Alternative Character Sets
+@unnumberedsec 3.5.2(5): Alternative Character Sets
@sp 1
@cartouche
-@code{Size} clause on a composite subtype should not affect the
-internal layout of components.
+If an implementation supports a mode with alternative interpretations
+for @code{Character} and @code{Wide_Character}, the set of graphic
+characters of @code{Character} should nevertheless remain a proper
+subset of the set of graphic characters of @code{Wide_Character}. Any
+character set ``localizations'' should be reflected in the results of
+the subprograms defined in the language-defined package
+@code{Characters.Handling} (see A.3) available in such a mode. In a mode with
+an alternative interpretation of @code{Character}, the implementation should
+also support a corresponding change in what is a legal
+@code{identifier_letter}.
@end cartouche
-Followed. But note that this can be overridden by use of the implementation
-pragma Implicit_Packing in the case of packed arrays.
+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.
+
+@cindex Integer types
+@unnumberedsec 3.5.4(28): Integer Types
@sp 1
@cartouche
-The recommended level of support for the @code{Size} attribute of subtypes is:
+An implementation should support @code{Long_Integer} in addition to
+@code{Integer} if the target machine supports 32-bit (or longer)
+arithmetic. No other named integer subtypes are recommended for package
+@code{Standard}. Instead, appropriate named integer subtypes should be
+provided in the library package @code{Interfaces} (see B.2).
@end cartouche
+@code{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.
+@unnumberedsec 3.5.4(29): Integer Types
+
@sp 1
@cartouche
-The @code{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 @code{Size} for it that reflects this representation.
+An implementation for a two's complement machine should support
+modular types with a binary modulus up to @code{System.Max_Int*2+2}. An
+implementation should support a non-binary modules up to @code{Integer'Last}.
@end cartouche
Followed.
+@cindex Enumeration values
+@unnumberedsec 3.5.5(8): Enumeration Values
@sp 1
@cartouche
-For a subtype implemented with levels of indirection, the @code{Size}
-should include the size of the pointers, but not the size of what they
-point at.
+For the evaluation of a call on @code{@var{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
+@code{Program_Error}. This is particularly important for enumeration
+types with noncontiguous internal codes specified by an
+enumeration_representation_clause.
@end cartouche
Followed.
-@cindex @code{Component_Size} clauses
-@unnumberedsec 13.3(71-73): Component Size Clauses
-@sp 1
-@cartouche
-The recommended level of support for the @code{Component_Size}
-attribute is:
-@end cartouche
+@cindex Float types
+@unnumberedsec 3.5.7(17): Float Types
@sp 1
@cartouche
-An implementation need not support specified @code{Component_Sizes} that are
-less than the @code{Size} of the component subtype.
+An implementation should support @code{Long_Float} in addition to
+@code{Float} if the target machine supports 11 or more digits of
+precision. No other named floating point subtypes are recommended for
+package @code{Standard}. Instead, appropriate named floating point subtypes
+should be provided in the library package @code{Interfaces} (see B.2).
@end cartouche
-Followed.
+@code{Short_Float} and @code{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 @code{Long_Float}, but on some machines, it will
+correspond to the IEEE extended form. The notable case is all ia32
+(x86) implementations, where @code{Long_Long_Float} corresponds to
+the 80-bit extended precision format supported in hardware on this
+processor. Note that the 128-bit format on SPARC is not supported,
+since this is a software rather than a hardware format.
+@cindex Multidimensional arrays
+@cindex Arrays, multidimensional
+@unnumberedsec 3.6.2(11): Multidimensional Arrays
@sp 1
@cartouche
-An implementation should support specified @code{Component_Size}s that
-are factors and multiples of the word size. For such
-@code{Component_Size}s, the array should contain no gaps between
-components. For other @code{Component_Size}s (if supported), the array
-should contain no gaps between components when packing is also
-specified; the implementation should forbid this combination in cases
-where it cannot support a no-gaps representation.
+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 @code{Convention}
+(@code{Fortran}, @dots{}) applies to a multidimensional array type, then
+column-major order should be used instead (see B.5, ``Interfacing with
+Fortran'').
@end cartouche
Followed.
-@cindex Enumeration representation clauses
-@cindex Representation clauses, enumeration
-@unnumberedsec 13.4(9-10): Enumeration Representation Clauses
+@findex Duration'Small
+@unnumberedsec 9.6(30-31): Duration'Small
@sp 1
@cartouche
-The recommended level of support for enumeration representation clauses
-is:
-
-An implementation need not support enumeration representation clauses
-for boolean types, but should at minimum support the internal codes in
-the range @code{System.Min_Int.System.Max_Int}.
+Whenever possible in an implementation, the value of @code{Duration'Small}
+should be no greater than 100 microseconds.
@end cartouche
-Followed.
+Followed. (@code{Duration'Small} = 10**(@minus{}9)).
-@cindex Record representation clauses
-@cindex Representation clauses, records
-@unnumberedsec 13.5.1(17-22): Record Representation Clauses
@sp 1
@cartouche
-The recommended level of support for
-@*@code{record_representation_clauses} is:
-
-An implementation should support storage places that can be extracted
-with a load, mask, shift sequence of machine code, and set with a load,
-shift, mask, store sequence, given the available machine instructions
-and run-time model.
+The time base for @code{delay_relative_statements} should be monotonic;
+it need not be the same time base as used for @code{Calendar.Clock}.
@end cartouche
Followed.
+@unnumberedsec 10.2.1(12): Consistent Representation
@sp 1
@cartouche
-A storage place should be supported if its size is equal to the
-@code{Size} of the component subtype, and it starts and ends on a
-boundary that obeys the @code{Alignment} of the component subtype.
+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.
@end cartouche
-Followed.
+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.
+@cindex Exception information
+@unnumberedsec 11.4.1(19): Exception Information
@sp 1
@cartouche
-If the default bit ordering applies to the declaration of a given type,
-then for a component whose subtype's @code{Size} is less than the word
-size, any storage place that does not cross an aligned word boundary
-should be supported.
+@code{Exception_Message} by default and @code{Exception_Information}
+should produce information useful for
+debugging. @code{Exception_Message} should be short, about one
+line. @code{Exception_Information} can be long. @code{Exception_Message}
+should not include the
+@code{Exception_Name}. @code{Exception_Information} should include both
+the @code{Exception_Name} and the @code{Exception_Message}.
@end cartouche
-Followed.
+Followed. For each exception that doesn't have a specified
+@code{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 @code{Discard_Names}.
+@cindex Suppression of checks
+@cindex Checks, suppression of
+@unnumberedsec 11.5(28): Suppression of Checks
@sp 1
@cartouche
-An implementation may reserve a storage place for the tag field of a
-tagged type, and disallow other components from overlapping that place.
+The implementation should minimize the code executed for checks that
+have been suppressed.
@end cartouche
-Followed. The storage place for the tag field is the beginning of the tagged
-record, and its size is Address'Size. GNAT will reject an explicit component
-clause for the tag field.
+Followed.
+@cindex Representation clauses
+@unnumberedsec 13.1 (21-24): Representation Clauses
@sp 1
@cartouche
-An implementation need not support a @code{component_clause} for a
-component of an extension part if the storage place is not after the
-storage places of all components of the parent type, whether or not
-those storage places had been specified.
+The recommended level of support for all representation items is
+qualified as follows:
@end cartouche
-Followed. The above advice on record representation clauses is followed,
-and all mentioned features are implemented.
-
-@cindex Storage place attributes
-@unnumberedsec 13.5.2(5): Storage Place Attributes
@sp 1
@cartouche
-If a component is represented using some form of pointer (such as an
-offset) to the actual data of the component, and this data is contiguous
-with the rest of the object, then the storage place attributes should
-reflect the place of the actual data, not the pointer. If a component is
-allocated discontinuously from the rest of the object, then a warning
-should be generated upon reference to one of its storage place
-attributes.
+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.
@end cartouche
-Followed. There are no such components in GNAT@.
+Followed. In fact, GNAT goes beyond the recommended level of support
+by allowing nonstatic expressions in some representation clauses even
+without the need to declare constants initialized with the values of
+such expressions.
+For example:
+
+@smallexample @c ada
+ X : Integer;
+ Y : Float;
+ for Y'Address use X'Address;>>
+@end smallexample
-@cindex Bit ordering
-@unnumberedsec 13.5.3(7-8): Bit Ordering
@sp 1
@cartouche
-The recommended level of support for the non-default bit ordering is:
+An implementation need not support a specification for the @code{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.
@end cartouche
+Followed. Size Clauses are not permitted on non-static components, as
+described above.
+
@sp 1
@cartouche
-If @code{Word_Size} = @code{Storage_Unit}, then the implementation
-should support the non-default bit ordering in addition to the default
-bit ordering.
+An aliased component, or a component whose type is by-reference, should
+always be allocated at an addressable location.
@end cartouche
-Followed. Word size does not equal storage size in this implementation.
-Thus non-default bit ordering is not supported.
+Followed.
-@cindex @code{Address}, as private type
-@unnumberedsec 13.7(37): Address as Private
+@cindex Packed types
+@unnumberedsec 13.2(6-8): Packed Types
@sp 1
@cartouche
-@code{Address} should be of a private type.
+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.
@end cartouche
-Followed.
-
-@cindex Operations, on @code{Address}
-@cindex @code{Address}, operations of
-@unnumberedsec 13.7.1(16): Address Operations
@sp 1
@cartouche
-Operations in @code{System} and its children should reflect the target
-environment semantics as closely as is reasonable. For example, on most
-machines, it makes sense for address arithmetic to ``wrap around''.
-Operations that do not make sense should raise @code{Program_Error}.
+The recommended level of support pragma @code{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 @code{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 @code{Size} is
+greater than the word size may be allocated an integral number of words.
@end cartouche
-Followed. Address arithmetic is modular arithmetic that wraps around. No
-operation raises @code{Program_Error}, since all operations make sense.
+Followed. Tight packing of arrays is supported for all component sizes
+up to 64-bits. If the array component size is 1 (that is to say, if
+the component is a boolean type or an enumeration type with two values)
+then values of the type are implicitly initialized to zero. This
+happens both for objects of the packed type, and for objects that have a
+subcomponent of the packed type.
-@cindex Unchecked conversion
-@unnumberedsec 13.9(14-17): Unchecked Conversion
@sp 1
@cartouche
-The @code{Size} of an array object should not include its bounds; hence,
-the bounds should not be part of the converted data.
+An implementation should support Address clauses for imported
+subprograms.
@end cartouche
Followed.
+@cindex @code{Address} clauses
+@unnumberedsec 13.3(14-19): Address Clauses
@sp 1
@cartouche
-The implementation should not generate unnecessary run-time checks to
-ensure that the representation of @var{S} is a representation of the
-target type. It should take advantage of the permission to return by
-reference when possible. Restrictions on unchecked conversions should be
-avoided unless required by the target environment.
+For an array @var{X}, @code{@var{X}'Address} should point at the first
+component of the array, and not at the array bounds.
@end cartouche
-Followed. There are no restrictions on unchecked conversion. A warning is
-generated if the source and target types do not have the same size since
-the semantics in this case may be target dependent.
+Followed.
@sp 1
@cartouche
-The recommended level of support for unchecked conversions is:
+The recommended level of support for the @code{Address} attribute is:
+
+@code{@var{X}'Address} should produce a useful result if @var{X} is an
+object that is aliased or of a by-reference type, or is an entity whose
+@code{Address} has been specified.
@end cartouche
+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.
+
@sp 1
@cartouche
-Unchecked conversions should be supported and should be reversible in
-the cases where this clause defines the result. To enable meaningful use
-of unchecked conversion, a contiguous representation should be used for
-elementary subtypes, for statically constrained array subtypes whose
-component subtype is one of the subtypes described in this paragraph,
-and for record subtypes without discriminants whose component subtypes
-are described in this paragraph.
+An implementation should support @code{Address} clauses for imported
+subprograms.
@end cartouche
Followed.
-@cindex Heap usage, implicit
-@unnumberedsec 13.11(23-25): Implicit Heap Usage
@sp 1
@cartouche
-An implementation should document any cases in which it dynamically
-allocates heap storage for a purpose other than the evaluation of an
-allocator.
+Objects (including subcomponents) that are aliased or of a by-reference
+type should be allocated on storage element boundaries.
@end cartouche
-Followed, the only other points at which heap storage is dynamically
-allocated are as follows:
-
-@itemize @bullet
-@item
-At initial elaboration time, to allocate dynamically sized global
-objects.
-
-@item
-To allocate space for a task when a task is created.
-
-@item
-To extend the secondary stack dynamically when needed. The secondary
-stack is used for returning variable length results.
-@end itemize
+Followed.
@sp 1
@cartouche
-A default (implementation-provided) storage pool for an
-access-to-constant type should not have overhead to support deallocation of
-individual objects.
+If the @code{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.
@end cartouche
Followed.
+@cindex @code{Alignment} clauses
+@unnumberedsec 13.3(29-35): Alignment Clauses
@sp 1
@cartouche
-A storage pool for an anonymous access type should be created at the
-point of an allocator for the type, and be reclaimed when the designated
-object becomes inaccessible.
+The recommended level of support for the @code{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:
@end cartouche
Followed.
-@cindex Unchecked deallocation
-@unnumberedsec 13.11.2(17): Unchecked De-allocation
@sp 1
@cartouche
-For a standard storage pool, @code{Free} should actually reclaim the
-storage.
+An implementation need not support specified @code{Alignment}s for
+combinations of @code{Size}s and @code{Alignment}s that cannot be easily
+loaded and stored by available machine instructions.
@end cartouche
Followed.
-@cindex Stream oriented attributes
-@unnumberedsec 13.13.2(17): Stream Oriented Attributes
@sp 1
@cartouche
-If a stream element is the same size as a storage element, then the
-normal in-memory representation should be used by @code{Read} and
-@code{Write} for scalar objects. Otherwise, @code{Read} and @code{Write}
-should use the smallest number of stream elements needed to represent
-all values in the base range of the scalar type.
+An implementation need not support specified @code{Alignment}s that are
+greater than the maximum @code{Alignment} the implementation ever returns by
+default.
@end cartouche
+Followed.
-Followed. By default, GNAT uses the interpretation suggested by AI-195,
-which specifies using the size of the first subtype.
-However, such an implementation is based on direct binary
-representations and is therefore target- and endianness-dependent.
-To address this issue, GNAT also supplies an alternate implementation
-of the stream attributes @code{Read} and @code{Write},
-which uses the target-independent XDR standard representation
-for scalar types.
-@cindex XDR representation
-@cindex @code{Read} attribute
-@cindex @code{Write} attribute
-@cindex Stream oriented attributes
-The XDR implementation is provided as an alternative body of the
-@code{System.Stream_Attributes} package, in the file
-@file{s-stratt-xdr.adb} in the GNAT library.
-There is no @file{s-stratt-xdr.ads} file.
-In order to install the XDR implementation, do the following:
-@enumerate
-@item Replace the default implementation of the
-@code{System.Stream_Attributes} package with the XDR implementation.
-For example on a Unix platform issue the commands:
-@smallexample
-$ mv s-stratt.adb s-stratt-default.adb
-$ mv s-stratt-xdr.adb s-stratt.adb
-@end smallexample
-
-@item
-Rebuild the GNAT run-time library as documented in
-@ref{GNAT and Libraries,,, gnat_ugn, @value{EDITION} User's Guide}.
-@end enumerate
-
-@unnumberedsec A.1(52): Names of Predefined Numeric Types
@sp 1
@cartouche
-If an implementation provides additional named predefined integer types,
-then the names should end with @samp{Integer} as in
-@samp{Long_Integer}. If an implementation provides additional named
-predefined floating point types, then the names should end with
-@samp{Float} as in @samp{Long_Float}.
+The recommended level of support for the @code{Alignment} attribute for
+objects is:
+
+Same as above, for subtypes, but in addition:
@end cartouche
Followed.
-@findex Ada.Characters.Handling
-@unnumberedsec A.3.2(49): @code{Ada.Characters.Handling}
@sp 1
@cartouche
-If an implementation provides a localized definition of @code{Character}
-or @code{Wide_Character}, then the effects of the subprograms in
-@code{Characters.Handling} should reflect the localizations. See also
-3.5.2.
+For stand-alone library-level objects of statically constrained
+subtypes, the implementation should support all @code{Alignment}s
+supported by the target linker. For example, page alignment is likely to
+be supported for such objects, but not for subtypes.
@end cartouche
-Followed. GNAT provides no such localized definitions.
+Followed.
-@cindex Bounded-length strings
-@unnumberedsec A.4.4(106): Bounded-Length String Handling
+@cindex @code{Size} clauses
+@unnumberedsec 13.3(42-43): Size Clauses
@sp 1
@cartouche
-Bounded string objects should not be implemented by implicit pointers
-and dynamic allocation.
-@end cartouche
-Followed. No implicit pointers or dynamic allocation are used.
+The recommended level of support for the @code{Size} attribute of
+objects is:
-@cindex Random number generation
-@unnumberedsec A.5.2(46-47): Random Number Generation
-@sp 1
-@cartouche
-Any storage associated with an object of type @code{Generator} should be
-reclaimed on exit from the scope of the object.
+A @code{Size} clause should be supported for an object if the specified
+@code{Size} is at least as large as its subtype's @code{Size}, and
+corresponds to a size in storage elements that is a multiple of the
+object's @code{Alignment} (if the @code{Alignment} is nonzero).
@end cartouche
Followed.
+@unnumberedsec 13.3(50-56): Size Clauses
@sp 1
@cartouche
-If the generator period is sufficiently long in relation to the number
-of distinct initiator values, then each possible value of
-@code{Initiator} passed to @code{Reset} should initiate a sequence of
-random numbers that does not, in a practical sense, overlap the sequence
-initiated by any other value. If this is not possible, then the mapping
-between initiator values and generator states should be a rapidly
-varying function of the initiator value.
-@end cartouche
-Followed. The generator period is sufficiently long for the first
-condition here to hold true.
+If the @code{Size} of a subtype is specified, and allows for efficient
+independent addressability (see 9.10) on the target architecture, then
+the @code{Size} of the following objects of the subtype should equal the
+@code{Size} of the subtype:
-@findex Get_Immediate
-@unnumberedsec A.10.7(23): @code{Get_Immediate}
-@sp 1
-@cartouche
-The @code{Get_Immediate} procedures should be implemented with
-unbuffered input. For a device such as a keyboard, input should be
-@dfn{available} if a key has already been typed, whereas for a disk
-file, input should always be available except at end of file. For a file
-associated with a keyboard-like device, any line-editing features of the
-underlying operating system should be disabled during the execution of
-@code{Get_Immediate}.
+Aliased objects (including components).
@end cartouche
-Followed on all targets except VxWorks. For VxWorks, there is no way to
-provide this functionality that does not result in the input buffer being
-flushed before the @code{Get_Immediate} call. A special unit
-@code{Interfaces.Vxworks.IO} is provided that contains routines to enable
-this functionality.
+Followed.
-@findex Export
-@unnumberedsec B.1(39-41): Pragma @code{Export}
@sp 1
@cartouche
-If an implementation supports pragma @code{Export} to a given language,
-then it should also allow the main subprogram to be written in that
-language. It should support some mechanism for invoking the elaboration
-of the Ada library units included in the system, and for invoking the
-finalization of the environment task. On typical systems, the
-recommended mechanism is to provide two subprograms whose link names are
-@code{adainit} and @code{adafinal}. @code{adainit} should contain the
-elaboration code for library units. @code{adafinal} should contain the
-finalization code. These subprograms should have no effect the second
-and subsequent time they are called.
+@code{Size} clause on a composite subtype should not affect the
+internal layout of components.
@end cartouche
-Followed.
+Followed. But note that this can be overridden by use of the implementation
+pragma Implicit_Packing in the case of packed arrays.
@sp 1
@cartouche
-Automatic elaboration of pre-elaborated packages should be
-provided when pragma @code{Export} is supported.
+The recommended level of support for the @code{Size} attribute of subtypes is:
@end cartouche
-Followed when the main program is in Ada. If the main program is in a
-foreign language, then
-@code{adainit} must be called to elaborate pre-elaborated
-packages.
-
@sp 1
@cartouche
-For each supported convention @var{L} other than @code{Intrinsic}, an
-implementation should support @code{Import} and @code{Export} pragmas
-for objects of @var{L}-compatible types and for subprograms, and pragma
-@code{Convention} for @var{L}-eligible types and for subprograms,
-presuming the other language has corresponding features. Pragma
-@code{Convention} need not be supported for scalar types.
+The @code{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 @code{Size} for it that reflects this representation.
@end cartouche
Followed.
-@cindex Package @code{Interfaces}
-@findex Interfaces
-@unnumberedsec B.2(12-13): Package @code{Interfaces}
@sp 1
@cartouche
-For each implementation-defined convention identifier, there should be a
-child package of package Interfaces with the corresponding name. This
-package should contain any declarations that would be useful for
-interfacing to the language (implementation) represented by the
-convention. Any declarations useful for interfacing to any language on
-the given hardware architecture should be provided directly in
-@code{Interfaces}.
+For a subtype implemented with levels of indirection, the @code{Size}
+should include the size of the pointers, but not the size of what they
+point at.
@end cartouche
-Followed. An additional package not defined
-in the Ada Reference Manual is @code{Interfaces.CPP}, used
-for interfacing to C++.
+Followed.
+@cindex @code{Component_Size} clauses
+@unnumberedsec 13.3(71-73): Component Size Clauses
@sp 1
@cartouche
-An implementation supporting an interface to C, COBOL, or Fortran should
-provide the corresponding package or packages described in the following
-clauses.
+The recommended level of support for the @code{Component_Size}
+attribute is:
@end cartouche
-Followed. GNAT provides all the packages described in this section.
-
-@cindex C, interfacing with
-@unnumberedsec B.3(63-71): Interfacing with C
@sp 1
@cartouche
-An implementation should support the following interface correspondences
-between Ada and C@.
+An implementation need not support specified @code{Component_Sizes} that are
+less than the @code{Size} of the component subtype.
@end cartouche
Followed.
@sp 1
@cartouche
-An Ada procedure corresponds to a void-returning C function.
+An implementation should support specified @code{Component_Size}s that
+are factors and multiples of the word size. For such
+@code{Component_Size}s, the array should contain no gaps between
+components. For other @code{Component_Size}s (if supported), the array
+should contain no gaps between components when packing is also
+specified; the implementation should forbid this combination in cases
+where it cannot support a no-gaps representation.
@end cartouche
Followed.
+@cindex Enumeration representation clauses
+@cindex Representation clauses, enumeration
+@unnumberedsec 13.4(9-10): Enumeration Representation Clauses
@sp 1
@cartouche
-An Ada function corresponds to a non-void C function.
+The recommended level of support for enumeration representation clauses
+is:
+
+An implementation need not support enumeration representation clauses
+for boolean types, but should at minimum support the internal codes in
+the range @code{System.Min_Int.System.Max_Int}.
@end cartouche
Followed.
+@cindex Record representation clauses
+@cindex Representation clauses, records
+@unnumberedsec 13.5.1(17-22): Record Representation Clauses
@sp 1
@cartouche
-An Ada @code{in} scalar parameter is passed as a scalar argument to a C
-function.
+The recommended level of support for
+@*@code{record_representation_clauses} is:
+
+An implementation should support storage places that can be extracted
+with a load, mask, shift sequence of machine code, and set with a load,
+shift, mask, store sequence, given the available machine instructions
+and run-time model.
@end cartouche
Followed.
@sp 1
@cartouche
-An Ada @code{in} parameter of an access-to-object type with designated
-type @var{T} is passed as a @code{@var{t}*} argument to a C function,
-where @var{t} is the C type corresponding to the Ada type @var{T}.
+A storage place should be supported if its size is equal to the
+@code{Size} of the component subtype, and it starts and ends on a
+boundary that obeys the @code{Alignment} of the component subtype.
@end cartouche
Followed.
@sp 1
@cartouche
-An Ada access @var{T} parameter, or an Ada @code{out} or @code{in out}
-parameter of an elementary type @var{T}, is passed as a @code{@var{t}*}
-argument to a C function, where @var{t} is the C type corresponding to
-the Ada type @var{T}. In the case of an elementary @code{out} or
-@code{in out} parameter, a pointer to a temporary copy is used to
-preserve by-copy semantics.
+If the default bit ordering applies to the declaration of a given type,
+then for a component whose subtype's @code{Size} is less than the word
+size, any storage place that does not cross an aligned word boundary
+should be supported.
@end cartouche
Followed.
@sp 1
@cartouche
-An Ada parameter of a record type @var{T}, of any mode, is passed as a
-@code{@var{t}*} argument to a C function, where @var{t} is the C
-structure corresponding to the Ada type @var{T}.
+An implementation may reserve a storage place for the tag field of a
+tagged type, and disallow other components from overlapping that place.
@end cartouche
-Followed. This convention may be overridden by the use of the C_Pass_By_Copy
-pragma, or Convention, or by explicitly specifying the mechanism for a given
-call using an extended import or export pragma.
+Followed. The storage place for the tag field is the beginning of the tagged
+record, and its size is Address'Size. GNAT will reject an explicit component
+clause for the tag field.
@sp 1
@cartouche
-An Ada parameter of an array type with component type @var{T}, of any
-mode, is passed as a @code{@var{t}*} argument to a C function, where
-@var{t} is the C type corresponding to the Ada type @var{T}.
+An implementation need not support a @code{component_clause} for a
+component of an extension part if the storage place is not after the
+storage places of all components of the parent type, whether or not
+those storage places had been specified.
@end cartouche
-Followed.
+Followed. The above advice on record representation clauses is followed,
+and all mentioned features are implemented.
+@cindex Storage place attributes
+@unnumberedsec 13.5.2(5): Storage Place Attributes
@sp 1
@cartouche
-An Ada parameter of an access-to-subprogram type is passed as a pointer
-to a C function whose prototype corresponds to the designated
-subprogram's specification.
+If a component is represented using some form of pointer (such as an
+offset) to the actual data of the component, and this data is contiguous
+with the rest of the object, then the storage place attributes should
+reflect the place of the actual data, not the pointer. If a component is
+allocated discontinuously from the rest of the object, then a warning
+should be generated upon reference to one of its storage place
+attributes.
@end cartouche
-Followed.
+Followed. There are no such components in GNAT@.
-@cindex COBOL, interfacing with
-@unnumberedsec B.4(95-98): Interfacing with COBOL
+@cindex Bit ordering
+@unnumberedsec 13.5.3(7-8): Bit Ordering
@sp 1
@cartouche
-An Ada implementation should support the following interface
-correspondences between Ada and COBOL@.
+The recommended level of support for the non-default bit ordering is:
@end cartouche
-Followed.
-
@sp 1
@cartouche
-An Ada access @var{T} parameter is passed as a @samp{BY REFERENCE} data item of
-the COBOL type corresponding to @var{T}.
+If @code{Word_Size} = @code{Storage_Unit}, then the implementation
+should support the non-default bit ordering in addition to the default
+bit ordering.
@end cartouche
-Followed.
+Followed. Word size does not equal storage size in this implementation.
+Thus non-default bit ordering is not supported.
+@cindex @code{Address}, as private type
+@unnumberedsec 13.7(37): Address as Private
@sp 1
@cartouche
-An Ada in scalar parameter is passed as a @samp{BY CONTENT} data item of
-the corresponding COBOL type.
+@code{Address} should be of a private type.
@end cartouche
Followed.
+@cindex Operations, on @code{Address}
+@cindex @code{Address}, operations of
+@unnumberedsec 13.7.1(16): Address Operations
@sp 1
@cartouche
-Any other Ada parameter is passed as a @samp{BY REFERENCE} data item of the
-COBOL type corresponding to the Ada parameter type; for scalars, a local
-copy is used if necessary to ensure by-copy semantics.
+Operations in @code{System} and its children should reflect the target
+environment semantics as closely as is reasonable. For example, on most
+machines, it makes sense for address arithmetic to ``wrap around''.
+Operations that do not make sense should raise @code{Program_Error}.
@end cartouche
-Followed.
+Followed. Address arithmetic is modular arithmetic that wraps around. No
+operation raises @code{Program_Error}, since all operations make sense.
-@cindex Fortran, interfacing with
-@unnumberedsec B.5(22-26): Interfacing with Fortran
+@cindex Unchecked conversion
+@unnumberedsec 13.9(14-17): Unchecked Conversion
@sp 1
@cartouche
-An Ada implementation should support the following interface
-correspondences between Ada and Fortran:
+The @code{Size} of an array object should not include its bounds; hence,
+the bounds should not be part of the converted data.
@end cartouche
Followed.
@sp 1
@cartouche
-An Ada procedure corresponds to a Fortran subroutine.
+The implementation should not generate unnecessary run-time checks to
+ensure that the representation of @var{S} is a representation of the
+target type. It should take advantage of the permission to return by
+reference when possible. Restrictions on unchecked conversions should be
+avoided unless required by the target environment.
@end cartouche
-Followed.
+Followed. There are no restrictions on unchecked conversion. A warning is
+generated if the source and target types do not have the same size since
+the semantics in this case may be target dependent.
@sp 1
@cartouche
-An Ada function corresponds to a Fortran function.
+The recommended level of support for unchecked conversions is:
@end cartouche
-Followed.
-
@sp 1
@cartouche
-An Ada parameter of an elementary, array, or record type @var{T} is
-passed as a @var{T} argument to a Fortran procedure, where @var{T} is
-the Fortran type corresponding to the Ada type @var{T}, and where the
-INTENT attribute of the corresponding dummy argument matches the Ada
-formal parameter mode; the Fortran implementation's parameter passing
-conventions are used. For elementary types, a local copy is used if
-necessary to ensure by-copy semantics.
+Unchecked conversions should be supported and should be reversible in
+the cases where this clause defines the result. To enable meaningful use
+of unchecked conversion, a contiguous representation should be used for
+elementary subtypes, for statically constrained array subtypes whose
+component subtype is one of the subtypes described in this paragraph,
+and for record subtypes without discriminants whose component subtypes
+are described in this paragraph.
@end cartouche
Followed.
+@cindex Heap usage, implicit
+@unnumberedsec 13.11(23-25): Implicit Heap Usage
@sp 1
@cartouche
-An Ada parameter of an access-to-subprogram type is passed as a
-reference to a Fortran procedure whose interface corresponds to the
-designated subprogram's specification.
+An implementation should document any cases in which it dynamically
+allocates heap storage for a purpose other than the evaluation of an
+allocator.
@end cartouche
-Followed.
+Followed, the only other points at which heap storage is dynamically
+allocated are as follows:
+
+@itemize @bullet
+@item
+At initial elaboration time, to allocate dynamically sized global
+objects.
+
+@item
+To allocate space for a task when a task is created.
+
+@item
+To extend the secondary stack dynamically when needed. The secondary
+stack is used for returning variable length results.
+@end itemize
-@cindex Machine operations
-@unnumberedsec C.1(3-5): Access to Machine Operations
@sp 1
@cartouche
-The machine code or intrinsic support should allow access to all
-operations normally available to assembly language programmers for the
-target environment, including privileged instructions, if any.
+A default (implementation-provided) storage pool for an
+access-to-constant type should not have overhead to support deallocation of
+individual objects.
@end cartouche
Followed.
@sp 1
@cartouche
-The interfacing pragmas (see Annex B) should support interface to
-assembler; the default assembler should be associated with the
-convention identifier @code{Assembler}.
+A storage pool for an anonymous access type should be created at the
+point of an allocator for the type, and be reclaimed when the designated
+object becomes inaccessible.
@end cartouche
Followed.
+@cindex Unchecked deallocation
+@unnumberedsec 13.11.2(17): Unchecked De-allocation
@sp 1
@cartouche
-If an entity is exported to assembly language, then the implementation
-should allocate it at an addressable location, and should ensure that it
-is retained by the linking process, even if not otherwise referenced
-from the Ada code. The implementation should assume that any call to a
-machine code or assembler subprogram is allowed to read or update every
-object that is specified as exported.
+For a standard storage pool, @code{Free} should actually reclaim the
+storage.
@end cartouche
Followed.
-@unnumberedsec C.1(10-16): Access to Machine Operations
+@cindex Stream oriented attributes
+@unnumberedsec 13.13.2(17): Stream Oriented Attributes
@sp 1
@cartouche
-The implementation should ensure that little or no overhead is
-associated with calling intrinsic and machine-code subprograms.
+If a stream element is the same size as a storage element, then the
+normal in-memory representation should be used by @code{Read} and
+@code{Write} for scalar objects. Otherwise, @code{Read} and @code{Write}
+should use the smallest number of stream elements needed to represent
+all values in the base range of the scalar type.
@end cartouche
-Followed for both intrinsics and machine-code subprograms.
+Followed. By default, GNAT uses the interpretation suggested by AI-195,
+which specifies using the size of the first subtype.
+However, such an implementation is based on direct binary
+representations and is therefore target- and endianness-dependent.
+To address this issue, GNAT also supplies an alternate implementation
+of the stream attributes @code{Read} and @code{Write},
+which uses the target-independent XDR standard representation
+for scalar types.
+@cindex XDR representation
+@cindex @code{Read} attribute
+@cindex @code{Write} attribute
+@cindex Stream oriented attributes
+The XDR implementation is provided as an alternative body of the
+@code{System.Stream_Attributes} package, in the file
+@file{s-stratt-xdr.adb} in the GNAT library.
+There is no @file{s-stratt-xdr.ads} file.
+In order to install the XDR implementation, do the following:
+@enumerate
+@item Replace the default implementation of the
+@code{System.Stream_Attributes} package with the XDR implementation.
+For example on a Unix platform issue the commands:
+@smallexample
+$ mv s-stratt.adb s-stratt-default.adb
+$ mv s-stratt-xdr.adb s-stratt.adb
+@end smallexample
+
+@item
+Rebuild the GNAT run-time library as documented in
+@ref{GNAT and Libraries,,, gnat_ugn, @value{EDITION} User's Guide}.
+@end enumerate
+
+@unnumberedsec A.1(52): Names of Predefined Numeric Types
@sp 1
@cartouche
-It is recommended that intrinsic subprograms be provided for convenient
-access to any machine operations that provide special capabilities or
-efficiency and that are not otherwise available through the language
-constructs.
+If an implementation provides additional named predefined integer types,
+then the names should end with @samp{Integer} as in
+@samp{Long_Integer}. If an implementation provides additional named
+predefined floating point types, then the names should end with
+@samp{Float} as in @samp{Long_Float}.
@end cartouche
-Followed. A full set of machine operation intrinsic subprograms is provided.
+Followed.
+@findex Ada.Characters.Handling
+@unnumberedsec A.3.2(49): @code{Ada.Characters.Handling}
@sp 1
@cartouche
-Atomic read-modify-write operations---e.g.@:, test and set, compare and
-swap, decrement and test, enqueue/dequeue.
+If an implementation provides a localized definition of @code{Character}
+or @code{Wide_Character}, then the effects of the subprograms in
+@code{Characters.Handling} should reflect the localizations. See also
+3.5.2.
@end cartouche
-Followed on any target supporting such operations.
+Followed. GNAT provides no such localized definitions.
+@cindex Bounded-length strings
+@unnumberedsec A.4.4(106): Bounded-Length String Handling
@sp 1
@cartouche
-Standard numeric functions---e.g.@:, sin, log.
+Bounded string objects should not be implemented by implicit pointers
+and dynamic allocation.
@end cartouche
-Followed on any target supporting such operations.
+Followed. No implicit pointers or dynamic allocation are used.
+@cindex Random number generation
+@unnumberedsec A.5.2(46-47): Random Number Generation
@sp 1
@cartouche
-String manipulation operations---e.g.@:, translate and test.
+Any storage associated with an object of type @code{Generator} should be
+reclaimed on exit from the scope of the object.
@end cartouche
-Followed on any target supporting such operations.
+Followed.
@sp 1
@cartouche
-Vector operations---e.g.@:, compare vector against thresholds.
+If the generator period is sufficiently long in relation to the number
+of distinct initiator values, then each possible value of
+@code{Initiator} passed to @code{Reset} should initiate a sequence of
+random numbers that does not, in a practical sense, overlap the sequence
+initiated by any other value. If this is not possible, then the mapping
+between initiator values and generator states should be a rapidly
+varying function of the initiator value.
@end cartouche
-Followed on any target supporting such operations.
+Followed. The generator period is sufficiently long for the first
+condition here to hold true.
+@findex Get_Immediate
+@unnumberedsec A.10.7(23): @code{Get_Immediate}
@sp 1
@cartouche
-Direct operations on I/O ports.
+The @code{Get_Immediate} procedures should be implemented with
+unbuffered input. For a device such as a keyboard, input should be
+@dfn{available} if a key has already been typed, whereas for a disk
+file, input should always be available except at end of file. For a file
+associated with a keyboard-like device, any line-editing features of the
+underlying operating system should be disabled during the execution of
+@code{Get_Immediate}.
@end cartouche
-Followed on any target supporting such operations.
+Followed on all targets except VxWorks. For VxWorks, there is no way to
+provide this functionality that does not result in the input buffer being
+flushed before the @code{Get_Immediate} call. A special unit
+@code{Interfaces.Vxworks.IO} is provided that contains routines to enable
+this functionality.
-@cindex Interrupt support
-@unnumberedsec C.3(28): Interrupt Support
+@findex Export
+@unnumberedsec B.1(39-41): Pragma @code{Export}
@sp 1
@cartouche
-If the @code{Ceiling_Locking} policy is not in effect, the
-implementation should provide means for the application to specify which
-interrupts are to be blocked during protected actions, if the underlying
-system allows for a finer-grain control of interrupt blocking.
+If an implementation supports pragma @code{Export} to a given language,
+then it should also allow the main subprogram to be written in that
+language. It should support some mechanism for invoking the elaboration
+of the Ada library units included in the system, and for invoking the
+finalization of the environment task. On typical systems, the
+recommended mechanism is to provide two subprograms whose link names are
+@code{adainit} and @code{adafinal}. @code{adainit} should contain the
+elaboration code for library units. @code{adafinal} should contain the
+finalization code. These subprograms should have no effect the second
+and subsequent time they are called.
@end cartouche
-Followed. The underlying system does not allow for finer-grain control
-of interrupt blocking.
+Followed.
-@cindex Protected procedure handlers
-@unnumberedsec C.3.1(20-21): Protected Procedure Handlers
@sp 1
@cartouche
-Whenever possible, the implementation should allow interrupt handlers to
-be called directly by the hardware.
+Automatic elaboration of pre-elaborated packages should be
+provided when pragma @code{Export} is supported.
@end cartouche
-@c SGI info:
-@ignore
-This is never possible under IRIX, so this is followed by default.
-@end ignore
-Followed on any target where the underlying operating system permits
-such direct calls.
+Followed when the main program is in Ada. If the main program is in a
+foreign language, then
+@code{adainit} must be called to elaborate pre-elaborated
+packages.
@sp 1
@cartouche
-Whenever practical, violations of any
-implementation-defined restrictions should be detected before run time.
+For each supported convention @var{L} other than @code{Intrinsic}, an
+implementation should support @code{Import} and @code{Export} pragmas
+for objects of @var{L}-compatible types and for subprograms, and pragma
+@code{Convention} for @var{L}-eligible types and for subprograms,
+presuming the other language has corresponding features. Pragma
+@code{Convention} need not be supported for scalar types.
@end cartouche
-Followed. Compile time warnings are given when possible.
-
-@cindex Package @code{Interrupts}
-@findex Interrupts
-@unnumberedsec C.3.2(25): Package @code{Interrupts}
+Followed.
+@cindex Package @code{Interfaces}
+@findex Interfaces
+@unnumberedsec B.2(12-13): Package @code{Interfaces}
@sp 1
@cartouche
-If implementation-defined forms of interrupt handler procedures are
-supported, such as protected procedures with parameters, then for each
-such form of a handler, a type analogous to @code{Parameterless_Handler}
-should be specified in a child package of @code{Interrupts}, with the
-same operations as in the predefined package Interrupts.
+For each implementation-defined convention identifier, there should be a
+child package of package Interfaces with the corresponding name. This
+package should contain any declarations that would be useful for
+interfacing to the language (implementation) represented by the
+convention. Any declarations useful for interfacing to any language on
+the given hardware architecture should be provided directly in
+@code{Interfaces}.
@end cartouche
-Followed.
+Followed. An additional package not defined
+in the Ada Reference Manual is @code{Interfaces.CPP}, used
+for interfacing to C++.
-@cindex Pre-elaboration requirements
-@unnumberedsec C.4(14): Pre-elaboration Requirements
@sp 1
@cartouche
-It is recommended that pre-elaborated packages be implemented in such a
-way that there should be little or no code executed at run time for the
-elaboration of entities not already covered by the Implementation
-Requirements.
+An implementation supporting an interface to C, COBOL, or Fortran should
+provide the corresponding package or packages described in the following
+clauses.
@end cartouche
-Followed. Executable code is generated in some cases, e.g.@: loops
-to initialize large arrays.
+Followed. GNAT provides all the packages described in this section.
-@unnumberedsec C.5(8): Pragma @code{Discard_Names}
+@cindex C, interfacing with
+@unnumberedsec B.3(63-71): Interfacing with C
@sp 1
@cartouche
-If the pragma applies to an entity, then the implementation should
-reduce the amount of storage used for storing names associated with that
-entity.
+An implementation should support the following interface correspondences
+between Ada and C@.
@end cartouche
Followed.
-@cindex Package @code{Task_Attributes}
-@findex Task_Attributes
-@unnumberedsec C.7.2(30): The Package Task_Attributes
@sp 1
@cartouche
-Some implementations are targeted to domains in which memory use at run
-time must be completely deterministic. For such implementations, it is
-recommended that the storage for task attributes will be pre-allocated
-statically and not from the heap. This can be accomplished by either
-placing restrictions on the number and the size of the task's
-attributes, or by using the pre-allocated storage for the first @var{N}
-attribute objects, and the heap for the others. In the latter case,
-@var{N} should be documented.
+An Ada procedure corresponds to a void-returning C function.
@end cartouche
-Not followed. This implementation is not targeted to such a domain.
-
-@cindex Locking Policies
-@unnumberedsec D.3(17): Locking Policies
+Followed.
@sp 1
@cartouche
-The implementation should use names that end with @samp{_Locking} for
-locking policies defined by the implementation.
+An Ada function corresponds to a non-void C function.
@end cartouche
-Followed. Two implementation-defined locking policies are defined,
-whose names (@code{Inheritance_Locking} and
-@code{Concurrent_Readers_Locking}) follow this suggestion.
+Followed.
-@cindex Entry queuing policies
-@unnumberedsec D.4(16): Entry Queuing Policies
@sp 1
@cartouche
-Names that end with @samp{_Queuing} should be used
-for all implementation-defined queuing policies.
+An Ada @code{in} scalar parameter is passed as a scalar argument to a C
+function.
@end cartouche
-Followed. No such implementation-defined queuing policies exist.
+Followed.
-@cindex Preemptive abort
-@unnumberedsec D.6(9-10): Preemptive Abort
@sp 1
@cartouche
-Even though the @code{abort_statement} is included in the list of
-potentially blocking operations (see 9.5.1), it is recommended that this
-statement be implemented in a way that never requires the task executing
-the @code{abort_statement} to block.
+An Ada @code{in} parameter of an access-to-object type with designated
+type @var{T} is passed as a @code{@var{t}*} argument to a C function,
+where @var{t} is the C type corresponding to the Ada type @var{T}.
@end cartouche
Followed.
@sp 1
@cartouche
-On a multi-processor, the delay associated with aborting a task on
-another processor should be bounded; the implementation should use
-periodic polling, if necessary, to achieve this.
+An Ada access @var{T} parameter, or an Ada @code{out} or @code{in out}
+parameter of an elementary type @var{T}, is passed as a @code{@var{t}*}
+argument to a C function, where @var{t} is the C type corresponding to
+the Ada type @var{T}. In the case of an elementary @code{out} or
+@code{in out} parameter, a pointer to a temporary copy is used to
+preserve by-copy semantics.
@end cartouche
Followed.
-@cindex Tasking restrictions
-@unnumberedsec D.7(21): Tasking Restrictions
@sp 1
@cartouche
-When feasible, the implementation should take advantage of the specified
-restrictions to produce a more efficient implementation.
+An Ada parameter of a record type @var{T}, of any mode, is passed as a
+@code{@var{t}*} argument to a C function, where @var{t} is the C
+structure corresponding to the Ada type @var{T}.
@end cartouche
-GNAT currently takes advantage of these restrictions by providing an optimized
-run time when the Ravenscar profile and the GNAT restricted run time set
-of restrictions are specified. See pragma @code{Profile (Ravenscar)} and
-pragma @code{Profile (Restricted)} for more details.
+Followed. This convention may be overridden by the use of the C_Pass_By_Copy
+pragma, or Convention, or by explicitly specifying the mechanism for a given
+call using an extended import or export pragma.
-@cindex Time, monotonic
-@unnumberedsec D.8(47-49): Monotonic Time
@sp 1
@cartouche
-When appropriate, implementations should provide configuration
-mechanisms to change the value of @code{Tick}.
+An Ada parameter of an array type with component type @var{T}, of any
+mode, is passed as a @code{@var{t}*} argument to a C function, where
+@var{t} is the C type corresponding to the Ada type @var{T}.
@end cartouche
-Such configuration mechanisms are not appropriate to this implementation
-and are thus not supported.
+Followed.
@sp 1
@cartouche
-It is recommended that @code{Calendar.Clock} and @code{Real_Time.Clock}
-be implemented as transformations of the same time base.
+An Ada parameter of an access-to-subprogram type is passed as a pointer
+to a C function whose prototype corresponds to the designated
+subprogram's specification.
@end cartouche
Followed.
+@cindex COBOL, interfacing with
+@unnumberedsec B.4(95-98): Interfacing with COBOL
@sp 1
@cartouche
-It is recommended that the @dfn{best} time base which exists in
-the underlying system be available to the application through
-@code{Clock}. @dfn{Best} may mean highest accuracy or largest range.
+An Ada implementation should support the following interface
+correspondences between Ada and COBOL@.
@end cartouche
Followed.
-@cindex Partition communication subsystem
-@cindex PCS
-@unnumberedsec E.5(28-29): Partition Communication Subsystem
@sp 1
@cartouche
-Whenever possible, the PCS on the called partition should allow for
-multiple tasks to call the RPC-receiver with different messages and
-should allow them to block until the corresponding subprogram body
-returns.
+An Ada access @var{T} parameter is passed as a @samp{BY REFERENCE} data item of
+the COBOL type corresponding to @var{T}.
@end cartouche
-Followed by GLADE, a separately supplied PCS that can be used with
-GNAT.
+Followed.
@sp 1
@cartouche
-The @code{Write} operation on a stream of type @code{Params_Stream_Type}
-should raise @code{Storage_Error} if it runs out of space trying to
-write the @code{Item} into the stream.
+An Ada in scalar parameter is passed as a @samp{BY CONTENT} data item of
+the corresponding COBOL type.
@end cartouche
-Followed by GLADE, a separately supplied PCS that can be used with
-GNAT@.
+Followed.
-@cindex COBOL support
-@unnumberedsec F(7): COBOL Support
@sp 1
@cartouche
-If COBOL (respectively, C) is widely supported in the target
-environment, implementations supporting the Information Systems Annex
-should provide the child package @code{Interfaces.COBOL} (respectively,
-@code{Interfaces.C}) specified in Annex B and should support a
-@code{convention_identifier} of COBOL (respectively, C) in the interfacing
-pragmas (see Annex B), thus allowing Ada programs to interface with
-programs written in that language.
+Any other Ada parameter is passed as a @samp{BY REFERENCE} data item of the
+COBOL type corresponding to the Ada parameter type; for scalars, a local
+copy is used if necessary to ensure by-copy semantics.
@end cartouche
Followed.
-@cindex Decimal radix support
-@unnumberedsec F.1(2): Decimal Radix Support
+@cindex Fortran, interfacing with
+@unnumberedsec B.5(22-26): Interfacing with Fortran
@sp 1
@cartouche
-Packed decimal should be used as the internal representation for objects
-of subtype @var{S} when @var{S}'Machine_Radix = 10.
+An Ada implementation should support the following interface
+correspondences between Ada and Fortran:
@end cartouche
-Not followed. GNAT ignores @var{S}'Machine_Radix and always uses binary
-representations.
+Followed.
-@cindex Numerics
-@unnumberedsec G: Numerics
-@sp 2
+@sp 1
@cartouche
-If Fortran (respectively, C) is widely supported in the target
-environment, implementations supporting the Numerics Annex
-should provide the child package @code{Interfaces.Fortran} (respectively,
-@code{Interfaces.C}) specified in Annex B and should support a
-@code{convention_identifier} of Fortran (respectively, C) in the interfacing
-pragmas (see Annex B), thus allowing Ada programs to interface with
-programs written in that language.
+An Ada procedure corresponds to a Fortran subroutine.
@end cartouche
Followed.
-@cindex Complex types
-@unnumberedsec G.1.1(56-58): Complex Types
-@sp 2
+@sp 1
@cartouche
-Because the usual mathematical meaning of multiplication of a complex
-operand and a real operand is that of the scaling of both components of
-the former by the latter, an implementation should not perform this
-operation by first promoting the real operand to complex type and then
-performing a full complex multiplication. In systems that, in the
-future, support an Ada binding to IEC 559:1989, the latter technique
-will not generate the required result when one of the components of the
-complex operand is infinite. (Explicit multiplication of the infinite
-component by the zero component obtained during promotion yields a NaN
-that propagates into the final result.) Analogous advice applies in the
-case of multiplication of a complex operand and a pure-imaginary
-operand, and in the case of division of a complex operand by a real or
-pure-imaginary operand.
+An Ada function corresponds to a Fortran function.
@end cartouche
-Not followed.
+Followed.
@sp 1
@cartouche
-Similarly, because the usual mathematical meaning of addition of a
-complex operand and a real operand is that the imaginary operand remains
-unchanged, an implementation should not perform this operation by first
-promoting the real operand to complex type and then performing a full
-complex addition. In implementations in which the @code{Signed_Zeros}
-attribute of the component type is @code{True} (and which therefore
-conform to IEC 559:1989 in regard to the handling of the sign of zero in
-predefined arithmetic operations), the latter technique will not
-generate the required result when the imaginary component of the complex
-operand is a negatively signed zero. (Explicit addition of the negative
-zero to the zero obtained during promotion yields a positive zero.)
-Analogous advice applies in the case of addition of a complex operand
-and a pure-imaginary operand, and in the case of subtraction of a
-complex operand and a real or pure-imaginary operand.
+An Ada parameter of an elementary, array, or record type @var{T} is
+passed as a @var{T} argument to a Fortran procedure, where @var{T} is
+the Fortran type corresponding to the Ada type @var{T}, and where the
+INTENT attribute of the corresponding dummy argument matches the Ada
+formal parameter mode; the Fortran implementation's parameter passing
+conventions are used. For elementary types, a local copy is used if
+necessary to ensure by-copy semantics.
@end cartouche
-Not followed.
+Followed.
@sp 1
@cartouche
-Implementations in which @code{Real'Signed_Zeros} is @code{True} should
-attempt to provide a rational treatment of the signs of zero results and
-result components. As one example, the result of the @code{Argument}
-function should have the sign of the imaginary component of the
-parameter @code{X} when the point represented by that parameter lies on
-the positive real axis; as another, the sign of the imaginary component
-of the @code{Compose_From_Polar} function should be the same as
-(respectively, the opposite of) that of the @code{Argument} parameter when that
-parameter has a value of zero and the @code{Modulus} parameter has a
-nonnegative (respectively, negative) value.
+An Ada parameter of an access-to-subprogram type is passed as a
+reference to a Fortran procedure whose interface corresponds to the
+designated subprogram's specification.
@end cartouche
Followed.
-@cindex Complex elementary functions
-@unnumberedsec G.1.2(49): Complex Elementary Functions
+@cindex Machine operations
+@unnumberedsec C.1(3-5): Access to Machine Operations
@sp 1
@cartouche
-Implementations in which @code{Complex_Types.Real'Signed_Zeros} is
-@code{True} should attempt to provide a rational treatment of the signs
-of zero results and result components. For example, many of the complex
-elementary functions have components that are odd functions of one of
-the parameter components; in these cases, the result component should
-have the sign of the parameter component at the origin. Other complex
-elementary functions have zero components whose sign is opposite that of
-a parameter component at the origin, or is always positive or always
-negative.
+The machine code or intrinsic support should allow access to all
+operations normally available to assembly language programmers for the
+target environment, including privileged instructions, if any.
@end cartouche
Followed.
-@cindex Accuracy requirements
-@unnumberedsec G.2.4(19): Accuracy Requirements
@sp 1
@cartouche
-The versions of the forward trigonometric functions without a
-@code{Cycle} parameter should not be implemented by calling the
-corresponding version with a @code{Cycle} parameter of
-@code{2.0*Numerics.Pi}, since this will not provide the required
-accuracy in some portions of the domain. For the same reason, the
-version of @code{Log} without a @code{Base} parameter should not be
-implemented by calling the corresponding version with a @code{Base}
-parameter of @code{Numerics.e}.
+The interfacing pragmas (see Annex B) should support interface to
+assembler; the default assembler should be associated with the
+convention identifier @code{Assembler}.
@end cartouche
Followed.
-@cindex Complex arithmetic accuracy
-@cindex Accuracy, complex arithmetic
-@unnumberedsec G.2.6(15): Complex Arithmetic Accuracy
-
@sp 1
@cartouche
-The version of the @code{Compose_From_Polar} function without a
-@code{Cycle} parameter should not be implemented by calling the
-corresponding version with a @code{Cycle} parameter of
-@code{2.0*Numerics.Pi}, since this will not provide the required
-accuracy in some portions of the domain.
+If an entity is exported to assembly language, then the implementation
+should allocate it at an addressable location, and should ensure that it
+is retained by the linking process, even if not otherwise referenced
+from the Ada code. The implementation should assume that any call to a
+machine code or assembler subprogram is allowed to read or update every
+object that is specified as exported.
@end cartouche
Followed.
-@c -----------------------------------------
-@node Implementation Defined Characteristics
-@chapter Implementation Defined Characteristics
-
-@noindent
-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 and are designated as
-implementation-defined. 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
-@c SGI info:
-@ignore
-in the ProDev Ada
-implementation on IRIX 5.3 operating system or greater
-@end ignore
-handles the implementation dependence.
+@unnumberedsec C.1(10-16): Access to Machine Operations
+@sp 1
+@cartouche
+The implementation should ensure that little or no overhead is
+associated with calling intrinsic and machine-code subprograms.
+@end cartouche
+Followed for both intrinsics and machine-code subprograms.
-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.
+@sp 1
+@cartouche
+It is recommended that intrinsic subprograms be provided for convenient
+access to any machine operations that provide special capabilities or
+efficiency and that are not otherwise available through the language
+constructs.
+@end cartouche
+Followed. A full set of machine operation intrinsic subprograms is provided.
@sp 1
@cartouche
-@noindent
-@strong{2}. Whether or not each recommendation given in Implementation
-Advice is followed. See 1.1.2(37).
+Atomic read-modify-write operations---e.g.@:, test and set, compare and
+swap, decrement and test, enqueue/dequeue.
@end cartouche
-@noindent
-@xref{Implementation Advice}.
+Followed on any target supporting such operations.
@sp 1
@cartouche
-@noindent
-@strong{3}. Capacity limitations of the implementation. See 1.1.3(3).
+Standard numeric functions---e.g.@:, sin, log.
@end cartouche
-@noindent
-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.
+Followed on any target supporting such operations.
@sp 1
@cartouche
-@noindent
-@strong{4}. Variations from the standard that are impractical to avoid
-given the implementation's execution environment. See 1.1.3(6).
+String manipulation operations---e.g.@:, translate and test.
@end cartouche
-@noindent
-There are no variations from the standard.
+Followed on any target supporting such operations.
@sp 1
@cartouche
-@noindent
-@strong{5}. Which @code{code_statement}s cause external
-interactions. See 1.1.3(10).
+Vector operations---e.g.@:, compare vector against thresholds.
@end cartouche
-@noindent
-Any @code{code_statement} can potentially cause external interactions.
+Followed on any target supporting such operations.
@sp 1
@cartouche
-@noindent
-@strong{6}. The coded representation for the text of an Ada
-program. See 2.1(4).
+Direct operations on I/O ports.
@end cartouche
-@noindent
-See separate section on source representation.
+Followed on any target supporting such operations.
+@cindex Interrupt support
+@unnumberedsec C.3(28): Interrupt Support
@sp 1
@cartouche
-@noindent
-@strong{7}. The control functions allowed in comments. See 2.1(14).
+If the @code{Ceiling_Locking} policy is not in effect, the
+implementation should provide means for the application to specify which
+interrupts are to be blocked during protected actions, if the underlying
+system allows for a finer-grain control of interrupt blocking.
@end cartouche
-@noindent
-See separate section on source representation.
+Followed. The underlying system does not allow for finer-grain control
+of interrupt blocking.
+@cindex Protected procedure handlers
+@unnumberedsec C.3.1(20-21): Protected Procedure Handlers
@sp 1
@cartouche
-@noindent
-@strong{8}. The representation for an end of line. See 2.2(2).
+Whenever possible, the implementation should allow interrupt handlers to
+be called directly by the hardware.
@end cartouche
-@noindent
-See separate section on source representation.
+@c SGI info:
+@ignore
+This is never possible under IRIX, so this is followed by default.
+@end ignore
+Followed on any target where the underlying operating system permits
+such direct calls.
@sp 1
@cartouche
-@noindent
-@strong{9}. Maximum supported line length and lexical element
-length. See 2.2(15).
+Whenever practical, violations of any
+implementation-defined restrictions should be detected before run time.
@end cartouche
-@noindent
-The maximum line length is 255 characters and the maximum length of a
-lexical element is also 255 characters.
+Followed. Compile time warnings are given when possible.
+
+@cindex Package @code{Interrupts}
+@findex Interrupts
+@unnumberedsec C.3.2(25): Package @code{Interrupts}
@sp 1
@cartouche
-@noindent
-@strong{10}. Implementation defined pragmas. See 2.8(14).
+If implementation-defined forms of interrupt handler procedures are
+supported, such as protected procedures with parameters, then for each
+such form of a handler, a type analogous to @code{Parameterless_Handler}
+should be specified in a child package of @code{Interrupts}, with the
+same operations as in the predefined package Interrupts.
@end cartouche
-@noindent
+Followed.
-@xref{Implementation Defined Pragmas}.
+@cindex Pre-elaboration requirements
+@unnumberedsec C.4(14): Pre-elaboration Requirements
+@sp 1
+@cartouche
+It is recommended that pre-elaborated packages be implemented in such a
+way that there should be little or no code executed at run time for the
+elaboration of entities not already covered by the Implementation
+Requirements.
+@end cartouche
+Followed. Executable code is generated in some cases, e.g.@: loops
+to initialize large arrays.
+@unnumberedsec C.5(8): Pragma @code{Discard_Names}
@sp 1
@cartouche
-@noindent
-@strong{11}. Effect of pragma @code{Optimize}. See 2.8(27).
+If the pragma applies to an entity, then the implementation should
+reduce the amount of storage used for storing names associated with that
+entity.
@end cartouche
-@noindent
-Pragma @code{Optimize}, if given with a @code{Time} or @code{Space}
-parameter, checks that the optimization flag is set, and aborts if it is
-not.
+Followed.
+@cindex Package @code{Task_Attributes}
+@findex Task_Attributes
+@unnumberedsec C.7.2(30): The Package Task_Attributes
@sp 1
@cartouche
-@noindent
-@strong{12}. The sequence of characters of the value returned by
-@code{@var{S}'Image} when some of the graphic characters of
-@code{@var{S}'Wide_Image} are not defined in @code{Character}. See
-3.5(37).
+Some implementations are targeted to domains in which memory use at run
+time must be completely deterministic. For such implementations, it is
+recommended that the storage for task attributes will be pre-allocated
+statically and not from the heap. This can be accomplished by either
+placing restrictions on the number and the size of the task's
+attributes, or by using the pre-allocated storage for the first @var{N}
+attribute objects, and the heap for the others. In the latter case,
+@var{N} should be documented.
@end cartouche
-@noindent
-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.
+Not followed. This implementation is not targeted to such a domain.
+
+@cindex Locking Policies
+@unnumberedsec D.3(17): Locking Policies
@sp 1
@cartouche
-@noindent
-@strong{13}. The predefined integer types declared in
-@code{Standard}. See 3.5.4(25).
+The implementation should use names that end with @samp{_Locking} for
+locking policies defined by the implementation.
@end cartouche
-@noindent
-@table @code
-@item Short_Short_Integer
-8 bit signed
-@item Short_Integer
-(Short) 16 bit signed
-@item Integer
-32 bit signed
-@item Long_Integer
-64 bit signed (on most 64 bit targets, depending on the C definition of long).
-32 bit signed (all other targets)
-@item Long_Long_Integer
-64 bit signed
-@end table
+Followed. Two implementation-defined locking policies are defined,
+whose names (@code{Inheritance_Locking} and
+@code{Concurrent_Readers_Locking}) follow this suggestion.
+@cindex Entry queuing policies
+@unnumberedsec D.4(16): Entry Queuing Policies
@sp 1
@cartouche
-@noindent
-@strong{14}. Any nonstandard integer types and the operators defined
-for them. See 3.5.4(26).
+Names that end with @samp{_Queuing} should be used
+for all implementation-defined queuing policies.
@end cartouche
-@noindent
-There are no nonstandard integer types.
+Followed. No such implementation-defined queuing policies exist.
+@cindex Preemptive abort
+@unnumberedsec D.6(9-10): Preemptive Abort
@sp 1
@cartouche
-@noindent
-@strong{15}. Any nonstandard real types and the operators defined for
-them. See 3.5.6(8).
+Even though the @code{abort_statement} is included in the list of
+potentially blocking operations (see 9.5.1), it is recommended that this
+statement be implemented in a way that never requires the task executing
+the @code{abort_statement} to block.
@end cartouche
-@noindent
-There are no nonstandard real types.
+Followed.
@sp 1
@cartouche
-@noindent
-@strong{16}. What combinations of requested decimal precision and range
-are supported for floating point types. See 3.5.7(7).
+On a multi-processor, the delay associated with aborting a task on
+another processor should be bounded; the implementation should use
+periodic polling, if necessary, to achieve this.
@end cartouche
-@noindent
-The precision and range is as defined by the IEEE standard.
+Followed.
+@cindex Tasking restrictions
+@unnumberedsec D.7(21): Tasking Restrictions
@sp 1
@cartouche
-@noindent
-@strong{17}. The predefined floating point types declared in
-@code{Standard}. See 3.5.7(16).
+When feasible, the implementation should take advantage of the specified
+restrictions to produce a more efficient implementation.
@end cartouche
-@noindent
-@table @code
-@item Short_Float
-32 bit IEEE short
-@item Float
-(Short) 32 bit IEEE short
-@item Long_Float
-64 bit IEEE long
-@item Long_Long_Float
-64 bit IEEE long (80 bit IEEE long on x86 processors)
-@end table
+GNAT currently takes advantage of these restrictions by providing an optimized
+run time when the Ravenscar profile and the GNAT restricted run time set
+of restrictions are specified. See pragma @code{Profile (Ravenscar)} and
+pragma @code{Profile (Restricted)} for more details.
+@cindex Time, monotonic
+@unnumberedsec D.8(47-49): Monotonic Time
@sp 1
@cartouche
-@noindent
-@strong{18}. The small of an ordinary fixed point type. See 3.5.9(8).
+When appropriate, implementations should provide configuration
+mechanisms to change the value of @code{Tick}.
@end cartouche
-@noindent
-@code{Fine_Delta} is 2**(@minus{}63)
+Such configuration mechanisms are not appropriate to this implementation
+and are thus not supported.
@sp 1
@cartouche
-@noindent
-@strong{19}. What combinations of small, range, and digits are
-supported for fixed point types. See 3.5.9(10).
+It is recommended that @code{Calendar.Clock} and @code{Real_Time.Clock}
+be implemented as transformations of the same time base.
@end cartouche
-@noindent
-Any combinations are permitted that do not result in a small less than
-@code{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.
+Followed.
@sp 1
@cartouche
-@noindent
-@strong{20}. The result of @code{Tags.Expanded_Name} for types declared
-within an unnamed @code{block_statement}. See 3.9(10).
+It is recommended that the @dfn{best} time base which exists in
+the underlying system be available to the application through
+@code{Clock}. @dfn{Best} may mean highest accuracy or largest range.
@end cartouche
-@noindent
-Block numbers of the form @code{B@var{nnn}}, where @var{nnn} is a
-decimal integer are allocated.
+Followed.
+@cindex Partition communication subsystem
+@cindex PCS
+@unnumberedsec E.5(28-29): Partition Communication Subsystem
@sp 1
@cartouche
-@noindent
-@strong{21}. Implementation-defined attributes. See 4.1.4(12).
+Whenever possible, the PCS on the called partition should allow for
+multiple tasks to call the RPC-receiver with different messages and
+should allow them to block until the corresponding subprogram body
+returns.
@end cartouche
-@noindent
-@xref{Implementation Defined Attributes}.
+Followed by GLADE, a separately supplied PCS that can be used with
+GNAT.
@sp 1
@cartouche
-@noindent
-@strong{22}. Any implementation-defined time types. See 9.6(6).
+The @code{Write} operation on a stream of type @code{Params_Stream_Type}
+should raise @code{Storage_Error} if it runs out of space trying to
+write the @code{Item} into the stream.
@end cartouche
-@noindent
-There are no implementation-defined time types.
+Followed by GLADE, a separately supplied PCS that can be used with
+GNAT@.
+@cindex COBOL support
+@unnumberedsec F(7): COBOL Support
@sp 1
@cartouche
-@noindent
-@strong{23}. The time base associated with relative delays.
+If COBOL (respectively, C) is widely supported in the target
+environment, implementations supporting the Information Systems Annex
+should provide the child package @code{Interfaces.COBOL} (respectively,
+@code{Interfaces.C}) specified in Annex B and should support a
+@code{convention_identifier} of COBOL (respectively, C) in the interfacing
+pragmas (see Annex B), thus allowing Ada programs to interface with
+programs written in that language.
@end cartouche
-@noindent
-See 9.6(20). The time base used is that provided by the C library
-function @code{gettimeofday}.
+Followed.
+@cindex Decimal radix support
+@unnumberedsec F.1(2): Decimal Radix Support
@sp 1
@cartouche
-@noindent
-@strong{24}. The time base of the type @code{Calendar.Time}. See
-9.6(23).
+Packed decimal should be used as the internal representation for objects
+of subtype @var{S} when @var{S}'Machine_Radix = 10.
@end cartouche
-@noindent
-The time base used is that provided by the C library function
-@code{gettimeofday}.
+Not followed. GNAT ignores @var{S}'Machine_Radix and always uses binary
+representations.
-@sp 1
+@cindex Numerics
+@unnumberedsec G: Numerics
+@sp 2
@cartouche
-@noindent
-@strong{25}. The time zone used for package @code{Calendar}
-operations. See 9.6(24).
+If Fortran (respectively, C) is widely supported in the target
+environment, implementations supporting the Numerics Annex
+should provide the child package @code{Interfaces.Fortran} (respectively,
+@code{Interfaces.C}) specified in Annex B and should support a
+@code{convention_identifier} of Fortran (respectively, C) in the interfacing
+pragmas (see Annex B), thus allowing Ada programs to interface with
+programs written in that language.
@end cartouche
-@noindent
-The time zone used by package @code{Calendar} is the current system time zone
-setting for local time, as accessed by the C library function
-@code{localtime}.
+Followed.
-@sp 1
+@cindex Complex types
+@unnumberedsec G.1.1(56-58): Complex Types
+@sp 2
@cartouche
-@noindent
-@strong{26}. Any limit on @code{delay_until_statements} of
-@code{select_statements}. See 9.6(29).
+Because the usual mathematical meaning of multiplication of a complex
+operand and a real operand is that of the scaling of both components of
+the former by the latter, an implementation should not perform this
+operation by first promoting the real operand to complex type and then
+performing a full complex multiplication. In systems that, in the
+future, support an Ada binding to IEC 559:1989, the latter technique
+will not generate the required result when one of the components of the
+complex operand is infinite. (Explicit multiplication of the infinite
+component by the zero component obtained during promotion yields a NaN
+that propagates into the final result.) Analogous advice applies in the
+case of multiplication of a complex operand and a pure-imaginary
+operand, and in the case of division of a complex operand by a real or
+pure-imaginary operand.
@end cartouche
-@noindent
-There are no such limits.
+Not followed.
@sp 1
@cartouche
-@noindent
-@strong{27}. Whether or not two non-overlapping parts of a composite
-object are independently addressable, in the case where packing, record
-layout, or @code{Component_Size} is specified for the object. See
-9.10(1).
+Similarly, because the usual mathematical meaning of addition of a
+complex operand and a real operand is that the imaginary operand remains
+unchanged, an implementation should not perform this operation by first
+promoting the real operand to complex type and then performing a full
+complex addition. In implementations in which the @code{Signed_Zeros}
+attribute of the component type is @code{True} (and which therefore
+conform to IEC 559:1989 in regard to the handling of the sign of zero in
+predefined arithmetic operations), the latter technique will not
+generate the required result when the imaginary component of the complex
+operand is a negatively signed zero. (Explicit addition of the negative
+zero to the zero obtained during promotion yields a positive zero.)
+Analogous advice applies in the case of addition of a complex operand
+and a pure-imaginary operand, and in the case of subtraction of a
+complex operand and a real or pure-imaginary operand.
@end cartouche
-@noindent
-Separate components are independently addressable if they do not share
-overlapping storage units.
+Not followed.
@sp 1
@cartouche
-@noindent
-@strong{28}. The representation for a compilation. See 10.1(2).
+Implementations in which @code{Real'Signed_Zeros} is @code{True} should
+attempt to provide a rational treatment of the signs of zero results and
+result components. As one example, the result of the @code{Argument}
+function should have the sign of the imaginary component of the
+parameter @code{X} when the point represented by that parameter lies on
+the positive real axis; as another, the sign of the imaginary component
+of the @code{Compose_From_Polar} function should be the same as
+(respectively, the opposite of) that of the @code{Argument} parameter when that
+parameter has a value of zero and the @code{Modulus} parameter has a
+nonnegative (respectively, negative) value.
@end cartouche
-@noindent
-A compilation is represented by a sequence of files presented to the
-compiler in a single invocation of the @command{gcc} command.
+Followed.
+@cindex Complex elementary functions
+@unnumberedsec G.1.2(49): Complex Elementary Functions
@sp 1
@cartouche
-@noindent
-@strong{29}. Any restrictions on compilations that contain multiple
-compilation_units. See 10.1(4).
+Implementations in which @code{Complex_Types.Real'Signed_Zeros} is
+@code{True} should attempt to provide a rational treatment of the signs
+of zero results and result components. For example, many of the complex
+elementary functions have components that are odd functions of one of
+the parameter components; in these cases, the result component should
+have the sign of the parameter component at the origin. Other complex
+elementary functions have zero components whose sign is opposite that of
+a parameter component at the origin, or is always positive or always
+negative.
@end cartouche
-@noindent
-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.
+Followed.
+@cindex Accuracy requirements
+@unnumberedsec G.2.4(19): Accuracy Requirements
@sp 1
@cartouche
-@noindent
-@strong{30}. The mechanisms for creating an environment and for adding
-and replacing compilation units. See 10.1.4(3).
+The versions of the forward trigonometric functions without a
+@code{Cycle} parameter should not be implemented by calling the
+corresponding version with a @code{Cycle} parameter of
+@code{2.0*Numerics.Pi}, since this will not provide the required
+accuracy in some portions of the domain. For the same reason, the
+version of @code{Log} without a @code{Base} parameter should not be
+implemented by calling the corresponding version with a @code{Base}
+parameter of @code{Numerics.e}.
@end cartouche
-@noindent
-See separate section on compilation model.
+Followed.
+
+@cindex Complex arithmetic accuracy
+@cindex Accuracy, complex arithmetic
+@unnumberedsec G.2.6(15): Complex Arithmetic Accuracy
@sp 1
@cartouche
-@noindent
-@strong{31}. The manner of explicitly assigning library units to a
-partition. See 10.2(2).
+The version of the @code{Compose_From_Polar} function without a
+@code{Cycle} parameter should not be implemented by calling the
+corresponding version with a @code{Cycle} parameter of
+@code{2.0*Numerics.Pi}, since this will not provide the required
+accuracy in some portions of the domain.
@end cartouche
+Followed.
+
+@c -----------------------------------------
+@node Implementation Defined Characteristics
+@chapter Implementation Defined Characteristics
+
@noindent
-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.
+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 and are designated as
+implementation-defined. These are mentioned throughout the Ada Reference
+Manual, and are summarized in Annex M@.
-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 @option{-z} and @option{-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 @ref{The GNAT Make Program gnatmake,,, gnat_ugn,
-@value{EDITION} User's Guide}.
+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
+@c SGI info:
+@ignore
+in the ProDev Ada
+implementation on IRIX 5.3 operating system or greater
+@end ignore
+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.
@sp 1
@cartouche
@noindent
-@strong{32}. The implementation-defined means, if any, of specifying
-which compilation units are needed by a given compilation unit. See
-10.2(2).
+@strong{2}. Whether or not each recommendation given in Implementation
+Advice is followed. See 1.1.2(37).
@end cartouche
@noindent
-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.
+@xref{Implementation Advice}.
@sp 1
@cartouche
@noindent
-@strong{33}. The manner of designating the main subprogram of a
-partition. See 10.2(7).
+@strong{3}. Capacity limitations of the implementation. See 1.1.3(3).
@end cartouche
@noindent
-The main program is designated by providing the name of the
-corresponding @file{ALI} file as the input parameter to the binder.
+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.
@sp 1
@cartouche
@noindent
-@strong{34}. The order of elaboration of @code{library_items}. See
-10.2(18).
+@strong{4}. Variations from the standard that are impractical to avoid
+given the implementation's execution environment. See 1.1.3(6).
@end cartouche
@noindent
-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.
+There are no variations from the standard.
@sp 1
@cartouche
@noindent
-@strong{35}. Parameter passing and function return for the main
-subprogram. See 10.2(21).
+@strong{5}. Which @code{code_statement}s cause external
+interactions. See 1.1.3(10).
@end cartouche
@noindent
-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 @code{Ada.Command_Line.Set_Exit_Status}).
+Any @code{code_statement} can potentially cause external interactions.
@sp 1
@cartouche
@noindent
-@strong{36}. The mechanisms for building and running partitions. See
-10.2(24).
+@strong{6}. The coded representation for the text of an Ada
+program. See 2.1(4).
@end cartouche
@noindent
-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.
+See separate section on source representation.
@sp 1
@cartouche
@noindent
-@strong{37}. The details of program execution, including program
-termination. See 10.2(25).
+@strong{7}. The control functions allowed in comments. See 2.1(14).
@end cartouche
@noindent
-See separate section on compilation model.
+See separate section on source representation.
@sp 1
@cartouche
@noindent
-@strong{38}. The semantics of any non-active partitions supported by the
-implementation. See 10.2(28).
+@strong{8}. The representation for an end of line. See 2.2(2).
@end cartouche
@noindent
-Passive partitions are supported on targets where shared memory is
-provided by the operating system. See the GLADE reference manual for
-further details.
+See separate section on source representation.
@sp 1
@cartouche
@noindent
-@strong{39}. The information returned by @code{Exception_Message}. See
-11.4.1(10).
+@strong{9}. Maximum supported line length and lexical element
+length. See 2.2(15).
@end cartouche
@noindent
-Exception message returns the null string unless a specific message has
-been passed by the program.
+The maximum line length is 255 characters and the maximum length of a
+lexical element is also 255 characters.
@sp 1
@cartouche
@noindent
-@strong{40}. The result of @code{Exceptions.Exception_Name} for types
-declared within an unnamed @code{block_statement}. See 11.4.1(12).
+@strong{10}. Implementation defined pragmas. See 2.8(14).
@end cartouche
@noindent
-Blocks have implementation defined names of the form @code{B@var{nnn}}
-where @var{nnn} is an integer.
+
+@xref{Implementation Defined Pragmas}.
@sp 1
@cartouche
@noindent
-@strong{41}. The information returned by
-@code{Exception_Information}. See 11.4.1(13).
+@strong{11}. Effect of pragma @code{Optimize}. See 2.8(27).
@end cartouche
@noindent
-@code{Exception_Information} returns a string in the following format:
-
-@smallexample
-@emph{Exception_Name:} nnnnn
-@emph{Message:} mmmmm
-@emph{PID:} ppp
-@emph{Call stack traceback locations:}
-0xhhhh 0xhhhh 0xhhhh ... 0xhhh
-@end smallexample
-
-@noindent
-where
-
-@itemize @bullet
-@item
-@code{nnnn} is the fully qualified name of the exception in all upper
-case letters. This line is always present.
-
-@item
-@code{mmmm} is the message (this line present only if message is non-null)
-
-@item
-@code{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.
-
-@item
-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.
-@end itemize
-
-@noindent
-The line terminator sequence at the end of each line, including
-the last line is a single @code{LF} character (@code{16#0A#}).
+Pragma @code{Optimize}, if given with a @code{Time} or @code{Space}
+parameter, checks that the optimization flag is set, and aborts if it is
+not.
@sp 1
@cartouche
@noindent
-@strong{42}. Implementation-defined check names. See 11.5(27).
+@strong{12}. The sequence of characters of the value returned by
+@code{@var{S}'Image} when some of the graphic characters of
+@code{@var{S}'Wide_Image} are not defined in @code{Character}. See
+3.5(37).
@end cartouche
@noindent
-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.
+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.
@sp 1
@cartouche
@noindent
-@strong{43}. The interpretation of each aspect of representation. See
-13.1(20).
+@strong{13}. The predefined integer types declared in
+@code{Standard}. See 3.5.4(25).
@end cartouche
@noindent
-See separate section on data representations.
+@table @code
+@item Short_Short_Integer
+8 bit signed
+@item Short_Integer
+(Short) 16 bit signed
+@item Integer
+32 bit signed
+@item Long_Integer
+64 bit signed (on most 64 bit targets, depending on the C definition of long).
+32 bit signed (all other targets)
+@item Long_Long_Integer
+64 bit signed
+@end table
@sp 1
@cartouche
@noindent
-@strong{44}. Any restrictions placed upon representation items. See
-13.1(20).
+@strong{14}. Any nonstandard integer types and the operators defined
+for them. See 3.5.4(26).
@end cartouche
@noindent
-See separate section on data representations.
+There are no nonstandard integer types.
@sp 1
@cartouche
@noindent
-@strong{45}. The meaning of @code{Size} for indefinite subtypes. See
-13.3(48).
+@strong{15}. Any nonstandard real types and the operators defined for
+them. See 3.5.6(8).
@end cartouche
@noindent
-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.
+There are no nonstandard real types.
@sp 1
@cartouche
@noindent
-@strong{46}. The default external representation for a type tag. See
-13.3(75).
+@strong{16}. What combinations of requested decimal precision and range
+are supported for floating point types. See 3.5.7(7).
@end cartouche
@noindent
-The default external representation for a type tag is the fully expanded
-name of the type in upper case letters.
+The precision and range is as defined by the IEEE standard.
@sp 1
@cartouche
@noindent
-@strong{47}. What determines whether a compilation unit is the same in
-two different partitions. See 13.3(76).
+@strong{17}. The predefined floating point types declared in
+@code{Standard}. See 3.5.7(16).
@end cartouche
@noindent
-A compilation unit is the same in two different partitions if and only
-if it derives from the same source file.
+@table @code
+@item Short_Float
+32 bit IEEE short
+@item Float
+(Short) 32 bit IEEE short
+@item Long_Float
+64 bit IEEE long
+@item Long_Long_Float
+64 bit IEEE long (80 bit IEEE long on x86 processors)
+@end table
@sp 1
@cartouche
@noindent
-@strong{48}. Implementation-defined components. See 13.5.1(15).
+@strong{18}. The small of an ordinary fixed point type. See 3.5.9(8).
@end cartouche
@noindent
-The only implementation defined component is the tag for a tagged type,
-which contains a pointer to the dispatching table.
+@code{Fine_Delta} is 2**(@minus{}63)
@sp 1
@cartouche
@noindent
-@strong{49}. If @code{Word_Size} = @code{Storage_Unit}, the default bit
-ordering. See 13.5.3(5).
+@strong{19}. What combinations of small, range, and digits are
+supported for fixed point types. See 3.5.9(10).
@end cartouche
@noindent
-@code{Word_Size} (32) is not the same as @code{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.
+Any combinations are permitted that do not result in a small less than
+@code{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.
@sp 1
@cartouche
@noindent
-@strong{50}. The contents of the visible part of package @code{System}
-and its language-defined children. See 13.7(2).
+@strong{20}. The result of @code{Tags.Expanded_Name} for types declared
+within an unnamed @code{block_statement}. See 3.9(10).
@end cartouche
@noindent
-See the definition of these packages in files @file{system.ads} and
-@file{s-stoele.ads}.
+Block numbers of the form @code{B@var{nnn}}, where @var{nnn} is a
+decimal integer are allocated.
@sp 1
@cartouche
@noindent
-@strong{51}. The contents of the visible part of package
-@code{System.Machine_Code}, and the meaning of
-@code{code_statements}. See 13.8(7).
+@strong{21}. Implementation-defined attributes. See 4.1.4(12).
@end cartouche
@noindent
-See the definition and documentation in file @file{s-maccod.ads}.
+@xref{Implementation Defined Attributes}.
@sp 1
@cartouche
@noindent
-@strong{52}. The effect of unchecked conversion. See 13.9(11).
+@strong{22}. Any implementation-defined time types. See 9.6(6).
@end cartouche
@noindent
-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
+There are no implementation-defined time types.
@sp 1
@cartouche
@noindent
-@strong{53}. The semantics of operations on invalid representations.
-See 13.9.2(10-11).
+@strong{23}. The time base associated with relative delays.
@end cartouche
@noindent
-For assignments and other operations where the use of invalid values cannot
-result in erroneous behavior, the compiler ignores the possibility of invalid
-values. An exception is raised at the point where an invalid value would
-result in erroneous behavior. For example executing:
-
-@smallexample @c ada
-procedure invalidvals is
- X : Integer := -1;
- Y : Natural range 1 .. 10;
- for Y'Address use X'Address;
- Z : Natural range 1 .. 10;
- A : array (Natural range 1 .. 10) of Integer;
-begin
- Z := Y; -- no exception
- A (Z) := 3; -- exception raised;
-end;
-@end smallexample
+See 9.6(20). The time base used is that provided by the C library
+function @code{gettimeofday}.
+@sp 1
+@cartouche
@noindent
-As indicated, an exception is raised on the array assignment, but not
-on the simple assignment of the invalid negative value from Y to Z.
+@strong{24}. The time base of the type @code{Calendar.Time}. See
+9.6(23).
+@end cartouche
+@noindent
+The time base used is that provided by the C library function
+@code{gettimeofday}.
@sp 1
@cartouche
@noindent
-@strong{53}. The manner of choosing a storage pool for an access type
-when @code{Storage_Pool} is not specified for the type. See 13.11(17).
+@strong{25}. The time zone used for package @code{Calendar}
+operations. See 9.6(24).
@end cartouche
@noindent
-There are 3 different standard pools used by the compiler when
-@code{Storage_Pool} is not specified depending whether the type is local
-to a subprogram or defined at the library level and whether
-@code{Storage_Size}is specified or not. See documentation in the runtime
-library units @code{System.Pool_Global}, @code{System.Pool_Size} and
-@code{System.Pool_Local} in files @file{s-poosiz.ads},
-@file{s-pooglo.ads} and @file{s-pooloc.ads} for full details on the
-default pools used.
+The time zone used by package @code{Calendar} is the current system time zone
+setting for local time, as accessed by the C library function
+@code{localtime}.
@sp 1
@cartouche
@noindent
-@strong{54}. Whether or not the implementation provides user-accessible
-names for the standard pool type(s). See 13.11(17).
+@strong{26}. Any limit on @code{delay_until_statements} of
+@code{select_statements}. See 9.6(29).
@end cartouche
@noindent
-
-See documentation in the sources of the run time mentioned in paragraph
-@strong{53} . All these pools are accessible by means of @code{with}'ing
-these units.
+There are no such limits.
@sp 1
@cartouche
@noindent
-@strong{55}. The meaning of @code{Storage_Size}. See 13.11(18).
+@strong{27}. Whether or not two non-overlapping parts of a composite
+object are independently addressable, in the case where packing, record
+layout, or @code{Component_Size} is specified for the object. See
+9.10(1).
@end cartouche
@noindent
-@code{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.
+Separate components are independently addressable if they do not share
+overlapping storage units.
@sp 1
@cartouche
@noindent
-@strong{56}. Implementation-defined aspects of storage pools. See
-13.11(22).
+@strong{28}. The representation for a compilation. See 10.1(2).
@end cartouche
@noindent
-See documentation in the sources of the run time mentioned in paragraph
-@strong{53} for details on GNAT-defined aspects of storage pools.
+A compilation is represented by a sequence of files presented to the
+compiler in a single invocation of the @command{gcc} command.
@sp 1
@cartouche
@noindent
-@strong{57}. The set of restrictions allowed in a pragma
-@code{Restrictions}. See 13.12(7).
+@strong{29}. Any restrictions on compilations that contain multiple
+compilation_units. See 10.1(4).
@end cartouche
@noindent
-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.
-
-@table @code
-
-@item Simple_Barriers
-@findex 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 @code{Profile (Ravenscar)}).
-
-@item Max_Entry_Queue_Length => Expr
-@findex Max_Entry_Queue_Length
-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.
-
-@item No_Calendar
-@findex No_Calendar
-This restriction ensures at compile time that there is no implicit or
-explicit dependence on the package @code{Ada.Calendar}.
-
-@item No_Default_Initialization
-@findex No_Default_Initialization
-
-This restriction prohibits any instance of default initialization of variables.
-The binder implements a consistency rule which prevents any unit compiled
-without the restriction from with'ing a unit with the restriction (this allows
-the generation of initialization procedures to be skipped, since you can be
-sure that no call is ever generated to an initialization procedure in a unit
-with the restriction active). If used in conjunction with Initialize_Scalars or
-Normalize_Scalars, the effect is to prohibit all cases of variables declared
-without a specific initializer (including the case of OUT scalar parameters).
-
-@item No_Direct_Boolean_Operators
-@findex No_Direct_Boolean_Operators
-This restriction ensures that no logical (and/or/xor) 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.
-
-@item No_Dispatching_Calls
-@findex 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
-@code{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.
-
-@smallexample
-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;
-@end smallexample
-
-@item No_Dynamic_Attachment
-@findex No_Dynamic_Attachment
-This restriction ensures that there is no call to any of the operations
-defined in package Ada.Interrupts.
-
-@item No_Enumeration_Maps
-@findex 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).
-
-@item No_Entry_Calls_In_Elaboration_Code
-@findex 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.
-
-@item No_Exception_Handlers
-@findex 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:
-
-@smallexample @c ada
-procedure Last_Chance_Handler
- (Source_Location : System.Address; Line : Integer);
-pragma Export (C, Last_Chance_Handler,
- "__gnat_last_chance_handler");
-@end smallexample
-
-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.
-
-@item No_Exception_Propagation
-@findex 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.
-
-@item No_Exception_Registration
-@findex 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.
-
-@item No_Finalization
-@findex No_Finalization
-This restriction disables the language features described in chapter 7.6 of the
-Ada 2005 RM as well as all form of code generation performed by the compiler to
-support these features. The following types are no longer considered controlled
-when this restriction is in effect:
-@itemize @bullet
-@item
-@code{Ada.Finalization.Controlled}
-@item
-@code{Ada.Finalization.Limited_Controlled}
-@item
-Derivations from @code{Controlled} or @code{Limited_Controlled}
-@item
-Class-wide types
-@item
-Protected types
-@item
-Task types
-@item
-Array and record types with controlled components
-@end itemize
-The compiler no longer generates code to initialize, finalize or adjust an
-object or a nested component, either declared on the stack or on the heap. The
-deallocation of a controlled object no longer finalizes its contents.
-
-@item No_Implicit_Conditionals
-@findex 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 single file can contain more than one compilation unit, but any
+sequence of files can be presented to the compiler as a single
+compilation.
-@item No_Implicit_Dynamic_Code
-@findex No_Implicit_Dynamic_Code
-@cindex trampoline
-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: @code{Access},
-@code{Unrestricted_Access}, or @code{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.
-Trampolines are also quite slow at run time.
+@sp 1
+@cartouche
+@noindent
+@strong{30}. The mechanisms for creating an environment and for adding
+and replacing compilation units. See 10.1.4(3).
+@end cartouche
+@noindent
+See separate section on compilation model.
-On many targets, trampolines have been largely eliminated. Look at the
-version of system.ads for your target --- if it has
-Always_Compatible_Rep equal to False, then trampolines are largely
-eliminated. In particular, a trampoline is built for the following
-features: @code{Address} of a nested subprogram;
-@code{Access} or @code{Unrestricted_Access} of a nested subprogram,
-but only if pragma Favor_Top_Level applies, or the access type has a
-foreign-language convention; primitive operations of nested tagged
-types.
+@sp 1
+@cartouche
+@noindent
+@strong{31}. The manner of explicitly assigning library units to a
+partition. See 10.2(2).
+@end cartouche
+@noindent
+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.
-@item No_Implicit_Loops
-@findex No_Implicit_Loops
-This restriction ensures that the generated code does not contain any
-implicit @code{for} loops, either by modifying
-the generated code where possible,
-or by rejecting any construct that would otherwise generate an implicit
-@code{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.
+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 @option{-z} and @option{-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 @ref{The GNAT Make Program gnatmake,,, gnat_ugn,
+@value{EDITION} User's Guide}.
-@item No_Initialize_Scalars
-@findex 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.
+@sp 1
+@cartouche
+@noindent
+@strong{32}. The implementation-defined means, if any, of specifying
+which compilation units are needed by a given compilation unit. See
+10.2(2).
+@end cartouche
+@noindent
+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.
-@item No_Local_Protected_Objects
-@findex No_Local_Protected_Objects
-This restriction ensures at compile time that protected objects are
-only declared at the library level.
+@sp 1
+@cartouche
+@noindent
+@strong{33}. The manner of designating the main subprogram of a
+partition. See 10.2(7).
+@end cartouche
+@noindent
+The main program is designated by providing the name of the
+corresponding @file{ALI} file as the input parameter to the binder.
-@item No_Protected_Type_Allocators
-@findex No_Protected_Type_Allocators
-This restriction ensures at compile time that there are no allocator
-expressions that attempt to allocate protected objects.
+@sp 1
+@cartouche
+@noindent
+@strong{34}. The order of elaboration of @code{library_items}. See
+10.2(18).
+@end cartouche
+@noindent
+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.
-@item No_Relative_Delay
-@findex No_Relative_Delay
-This restriction ensures at compile time that there are no delay relative
-statements and prevents expressions such as @code{delay 1.23;} from appearing
-in source code.
+@sp 1
+@cartouche
+@noindent
+@strong{35}. Parameter passing and function return for the main
+subprogram. See 10.2(21).
+@end cartouche
+@noindent
+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 @code{Ada.Command_Line.Set_Exit_Status}).
-@item No_Requeue_Statements
-@findex No_Requeue_Statements
-This restriction ensures at compile time that no requeue statements are
-permitted and prevents keyword @code{requeue} from being used in source code.
+@sp 1
+@cartouche
+@noindent
+@strong{36}. The mechanisms for building and running partitions. See
+10.2(24).
+@end cartouche
+@noindent
+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.
-@item No_Secondary_Stack
-@findex 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.
+@sp 1
+@cartouche
+@noindent
+@strong{37}. The details of program execution, including program
+termination. See 10.2(25).
+@end cartouche
+@noindent
+See separate section on compilation model.
-@item No_Select_Statements
-@findex No_Select_Statements
-This restriction ensures at compile time no select statements of any kind
-are permitted, that is the keyword @code{select} may not appear.
-This is one of the restrictions of the Ravenscar
-profile for limited tasking (see also pragma @code{Profile (Ravenscar)}).
+@sp 1
+@cartouche
+@noindent
+@strong{38}. The semantics of any non-active partitions supported by the
+implementation. See 10.2(28).
+@end cartouche
+@noindent
+Passive partitions are supported on targets where shared memory is
+provided by the operating system. See the GLADE reference manual for
+further details.
-@item No_Standard_Storage_Pools
-@findex 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.
+@sp 1
+@cartouche
+@noindent
+@strong{39}. The information returned by @code{Exception_Message}. See
+11.4.1(10).
+@end cartouche
+@noindent
+Exception message returns the null string unless a specific message has
+been passed by the program.
-@item No_Stream_Optimizations
-@findex No_Stream_Optimizations
-This restriction affects the performance of stream operations on types
-@code{String}, @code{Wide_String} and @code{Wide_Wide_String}. By default, the
-compiler uses block reads and writes when manipulating @code{String} objects
-due to their supperior performance. When this restriction is in effect, the
-compiler performs all IO operations on a per-character basis.
+@sp 1
+@cartouche
+@noindent
+@strong{40}. The result of @code{Exceptions.Exception_Name} for types
+declared within an unnamed @code{block_statement}. See 11.4.1(12).
+@end cartouche
+@noindent
+Blocks have implementation defined names of the form @code{B@var{nnn}}
+where @var{nnn} is an integer.
-@item No_Streams
-@findex No_Streams
-This restriction ensures at compile/bind time that there are no
-stream objects created and no use of stream attributes.
-This restriction does not forbid dependences on the package
-@code{Ada.Streams}. So it is permissible to with
-@code{Ada.Streams} (or another package that does so itself)
-as long as no actual stream objects are created and no
-stream attributes are used.
+@sp 1
+@cartouche
+@noindent
+@strong{41}. The information returned by
+@code{Exception_Information}. See 11.4.1(13).
+@end cartouche
+@noindent
+@code{Exception_Information} returns a string in the following format:
-Note that the use of restriction allows optimization of tagged types,
-since they do not need to worry about dispatching stream operations.
-To take maximum advantage of this space-saving optimization, any
-unit declaring a tagged type should be compiled with the restriction,
-though this is not required.
+@smallexample
+@emph{Exception_Name:} nnnnn
+@emph{Message:} mmmmm
+@emph{PID:} ppp
+@emph{Call stack traceback locations:}
+0xhhhh 0xhhhh 0xhhhh ... 0xhhh
+@end smallexample
-@item No_Task_Attributes_Package
-@findex No_Task_Attributes_Package
-This restriction ensures at compile time that there are no implicit or
-explicit dependencies on the package @code{Ada.Task_Attributes}.
+@noindent
+where
-@item No_Task_Termination
-@findex No_Task_Termination
-This restriction ensures at compile time that no terminate alternatives
-appear in any task body.
+@itemize @bullet
+@item
+@code{nnnn} is the fully qualified name of the exception in all upper
+case letters. This line is always present.
-@item No_Tasking
-@findex No_Tasking
-This restriction prevents the declaration of tasks or task types throughout
-the partition. It is similar in effect to the use of @code{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.
+@item
+@code{mmmm} is the message (this line present only if message is non-null)
-@item Static_Priorities
-@findex Static_Priorities
-This restriction ensures at compile time that all priority expressions
-are static, and that there are no dependencies on the package
-@code{Ada.Dynamic_Priorities}.
+@item
+@code{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.
-@item Static_Storage_Size
-@findex Static_Storage_Size
-This restriction ensures at compile time that any expression appearing
-in a Storage_Size pragma or attribute definition clause is static.
+@item
+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.
+@end itemize
-@end table
+@noindent
+The line terminator sequence at the end of each line, including
+the last line is a single @code{LF} character (@code{16#0A#}).
+@sp 1
+@cartouche
@noindent
-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.
+@strong{42}. Implementation-defined check names. See 11.5(27).
+@end cartouche
+@noindent
+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).
-@table @code
+In addition, a user program can add implementation-defined check names
+by means of the pragma Check_Name.
-@item No_Elaboration_Code
-@findex 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 @code{Preelaborate}. There are cases in which pragma
-@code{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 @code{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.
+@sp 1
+@cartouche
+@noindent
+@strong{43}. The interpretation of each aspect of representation. See
+13.1(20).
+@end cartouche
+@noindent
+See separate section on data representations.
-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 @code{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.
+@sp 1
+@cartouche
+@noindent
+@strong{44}. Any restrictions placed upon representation items. See
+13.1(20).
+@end cartouche
+@noindent
+See separate section on data representations.
-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:
+@sp 1
+@cartouche
+@noindent
+@strong{45}. The meaning of @code{Size} for indefinite subtypes. See
+13.3(48).
+@end cartouche
+@noindent
+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.
-@smallexample
- Val : constant Integer := X;
-@end smallexample
+@sp 1
+@cartouche
+@noindent
+@strong{46}. The default external representation for a type tag. See
+13.3(75).
+@end cartouche
+@noindent
+The default external representation for a type tag is the fully expanded
+name of the type in upper case letters.
+@sp 1
+@cartouche
@noindent
-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.
+@strong{47}. What determines whether a compilation unit is the same in
+two different partitions. See 13.3(76).
+@end cartouche
+@noindent
+A compilation unit is the same in two different partitions if and only
+if it derives from the same source file.
-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.
+@sp 1
+@cartouche
+@noindent
+@strong{48}. Implementation-defined components. See 13.5.1(15).
+@end cartouche
+@noindent
+The only implementation defined component is the tag for a tagged type,
+which contains a pointer to the dispatching table.
-@item No_Entry_Queue
-@findex 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.
+@sp 1
+@cartouche
+@noindent
+@strong{49}. If @code{Word_Size} = @code{Storage_Unit}, the default bit
+ordering. See 13.5.3(5).
+@end cartouche
+@noindent
+@code{Word_Size} (32) is not the same as @code{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.
-@item No_Implementation_Attributes
-@findex 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.
+@sp 1
+@cartouche
+@noindent
+@strong{50}. The contents of the visible part of package @code{System}
+and its language-defined children. See 13.7(2).
+@end cartouche
+@noindent
+See the definition of these packages in files @file{system.ads} and
+@file{s-stoele.ads}.
-@item No_Implementation_Pragmas
-@findex 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.
+@sp 1
+@cartouche
+@noindent
+@strong{51}. The contents of the visible part of package
+@code{System.Machine_Code}, and the meaning of
+@code{code_statements}. See 13.8(7).
+@end cartouche
+@noindent
+See the definition and documentation in file @file{s-maccod.ads}.
-@item No_Implementation_Restrictions
-@findex No_Implementation_Restrictions
-This restriction checks at compile time that no GNAT-defined restriction
-identifiers (other than @code{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.
+@sp 1
+@cartouche
+@noindent
+@strong{52}. The effect of unchecked conversion. See 13.9(11).
+@end cartouche
+@noindent
+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
-@item No_Implicit_Aliasing
-@findex No_Implicit_Aliasing
-This restriction, which is not required to be partition-wide consistent,
-requires an explicit aliased keyword for an object to which 'Access,
-'Unchecked_Access, or 'Address is applied, and forbids entirely the use of
-the 'Unrestricted_Access attribute for objects. Note: the reason that
-Unrestricted_Access is forbidden is that it would require the prefix
-to be aliased, and in such cases, it can always be replaced by
-the standard attribute Unchecked_Access which is preferable.
+@sp 1
+@cartouche
+@noindent
+@strong{53}. The semantics of operations on invalid representations.
+See 13.9.2(10-11).
+@end cartouche
+@noindent
+For assignments and other operations where the use of invalid values cannot
+result in erroneous behavior, the compiler ignores the possibility of invalid
+values. An exception is raised at the point where an invalid value would
+result in erroneous behavior. For example executing:
-@item No_Wide_Characters
-@findex No_Wide_Characters
-This restriction ensures at compile time that no uses of the types
-@code{Wide_Character} or @code{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 @code{Character}.
+@smallexample @c ada
+procedure invalidvals is
+ X : Integer := -1;
+ Y : Natural range 1 .. 10;
+ for Y'Address use X'Address;
+ Z : Natural range 1 .. 10;
+ A : array (Natural range 1 .. 10) of Integer;
+begin
+ Z := Y; -- no exception
+ A (Z) := 3; -- exception raised;
+end;
+@end smallexample
-@item SPARK
-@findex SPARK
-This restriction checks at compile time that some constructs forbidden in
-SPARK are not present. The SPARK version used as a reference is the same as
-the Ada mode for the unit, so a unit compiled in Ada 95 mode with SPARK
-restrictions will be checked for constructs forbidden in SPARK 95.
-Error messages related to SPARK restriction have the form:
+@noindent
+As indicated, an exception is raised on the array assignment, but not
+on the simple assignment of the invalid negative value from Y to Z.
-@smallexample
-violation of restriction "Spark" at <file>
- <error message>
-@end smallexample
+@sp 1
+@cartouche
+@noindent
+@strong{53}. The manner of choosing a storage pool for an access type
+when @code{Storage_Pool} is not specified for the type. See 13.11(17).
+@end cartouche
+@noindent
+There are 3 different standard pools used by the compiler when
+@code{Storage_Pool} is not specified depending whether the type is local
+to a subprogram or defined at the library level and whether
+@code{Storage_Size}is specified or not. See documentation in the runtime
+library units @code{System.Pool_Global}, @code{System.Pool_Size} and
+@code{System.Pool_Local} in files @file{s-poosiz.ads},
+@file{s-pooglo.ads} and @file{s-pooloc.ads} for full details on the
+default pools used.
-This is not a replacement for the semantic checks performed by the
-SPARK Examiner tool, as the compiler only deals currently with code,
-not at all with SPARK annotations and does not guarantee catching all
-cases of constructs forbidden by SPARK.
+@sp 1
+@cartouche
+@noindent
+@strong{54}. Whether or not the implementation provides user-accessible
+names for the standard pool type(s). See 13.11(17).
+@end cartouche
+@noindent
-Thus it may well be the case that code which
-passes the compiler in SPARK mode is rejected by the SPARK Examiner,
-e.g. due to the different visibility rules of the Examiner based on
-SPARK @code{inherit} annotations.
+See documentation in the sources of the run time mentioned in paragraph
+@strong{53} . All these pools are accessible by means of @code{with}'ing
+these units.
-This restriction can be useful in providing an initial filter for
-code developed using SPARK, or in examining legacy code to see how far
-it is from meeting SPARK restrictions.
+@sp 1
+@cartouche
+@noindent
+@strong{55}. The meaning of @code{Storage_Size}. See 13.11(18).
+@end cartouche
+@noindent
+@code{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.
-@end table
+@sp 1
+@cartouche
+@noindent
+@strong{56}. Implementation-defined aspects of storage pools. See
+13.11(22).
+@end cartouche
+@noindent
+See documentation in the sources of the run time mentioned in paragraph
+@strong{53} for details on GNAT-defined aspects of storage pools.
+
+@sp 1
+@cartouche
+@noindent
+@strong{57}. The set of restrictions allowed in a pragma
+@code{Restrictions}. See 13.12(7).
+@end cartouche
+@noindent
+@xref{Implementation Defined Restrictions}.
@sp 1
@cartouche
@sp 1
@cartouche
@noindent
-@strong{100}. Implementation defined task dispatching. See D.2.2(18).
+@strong{100}. Implementation-defined task dispatching. See D.2.2(18).
@end cartouche
@noindent
@c SGI info:
projects / platform / upstream / gcc.git / commitdiff