This is gnat_rm.info, produced by makeinfo version 7.1 from gnat_rm.texi. GNAT Reference Manual , Dec 21, 2023 AdaCore Copyright © 2008-2024, Free Software Foundation INFO-DIR-SECTION GNU Ada Tools START-INFO-DIR-ENTRY * gnat_rm: (gnat_rm.info). gnat_rm END-INFO-DIR-ENTRY Generated by Sphinx 5.3.0.  File: gnat_rm.info, Node: Pragma Unreferenced_Objects, Next: Pragma Unreserve_All_Interrupts, Prev: Pragma Unreferenced, Up: Implementation Defined Pragmas 2.191 Pragma Unreferenced_Objects ================================= Syntax: pragma Unreferenced_Objects (local_subtype_NAME {, local_subtype_NAME}); This pragma signals that for the types or subtypes whose names are listed, objects which are declared with one of these types or subtypes may not be referenced, and if no references appear, no warnings are given. This is particularly useful for objects which are declared solely for their initialization and finalization effect. Such variables are sometimes referred to as RAII variables (Resource Acquisition Is Initialization). Using this pragma on the relevant type (most typically a limited controlled type), the compiler will automatically suppress unwanted warnings about these variables not being referenced.  File: gnat_rm.info, Node: Pragma Unreserve_All_Interrupts, Next: Pragma Unsuppress, Prev: Pragma Unreferenced_Objects, Up: Implementation Defined Pragmas 2.192 Pragma Unreserve_All_Interrupts ===================================== Syntax: pragma Unreserve_All_Interrupts; Normally certain interrupts are reserved to the implementation. Any attempt to attach an interrupt causes Program_Error to be raised, as described in RM C.3.2(22). A typical example is the ‘SIGINT’ interrupt used in many systems for a ‘Ctrl-C’ interrupt. Normally this interrupt is reserved to the implementation, so that ‘Ctrl-C’ can be used to interrupt execution. If the pragma ‘Unreserve_All_Interrupts’ appears anywhere in any unit in a program, then all such interrupts are unreserved. This allows the program to handle these interrupts, but disables their standard functions. For example, if this pragma is used, then pressing ‘Ctrl-C’ will not automatically interrupt execution. However, a program can then handle the ‘SIGINT’ interrupt as it chooses. For a full list of the interrupts handled in a specific implementation, see the source code for the spec of ‘Ada.Interrupts.Names’ in file ‘a-intnam.ads’. This is a target dependent file that contains the list of interrupts recognized for a given target. The documentation in this file also specifies what interrupts are affected by the use of the ‘Unreserve_All_Interrupts’ pragma. For a more general facility for controlling what interrupts can be handled, see pragma ‘Interrupt_State’, which subsumes the functionality of the ‘Unreserve_All_Interrupts’ pragma.  File: gnat_rm.info, Node: Pragma Unsuppress, Next: Pragma Unused, Prev: Pragma Unreserve_All_Interrupts, Up: Implementation Defined Pragmas 2.193 Pragma Unsuppress ======================= Syntax: pragma Unsuppress (IDENTIFIER [, [On =>] NAME]); This pragma undoes the effect of a previous pragma ‘Suppress’. If there is no corresponding pragma ‘Suppress’ in effect, it has no effect. The range of the effect is the same as for pragma ‘Suppress’. The meaning of the arguments is identical to that used in pragma ‘Suppress’. One important application is to ensure that checks are on in cases where code depends on the checks for its correct functioning, so that the code will compile correctly even if the compiler switches are set to suppress checks. For example, in a program that depends on external names of tagged types and wants to ensure that the duplicated tag check occurs even if all run-time checks are suppressed by a compiler switch, the following configuration pragma will ensure this test is not suppressed: pragma Unsuppress (Duplicated_Tag_Check); This pragma is standard in Ada 2005. It is available in all earlier versions of Ada as an implementation-defined pragma. Note that in addition to the checks defined in the Ada RM, GNAT recognizes a number of implementation-defined check names. See the description of pragma ‘Suppress’ for full details.  File: gnat_rm.info, Node: Pragma Unused, Next: Pragma Use_VADS_Size, Prev: Pragma Unsuppress, Up: Implementation Defined Pragmas 2.194 Pragma Unused =================== Syntax: pragma Unused (LOCAL_NAME {, LOCAL_NAME}); This pragma signals that the assignable entities (variables, ‘out’ parameters, and ‘in out’ parameters) whose names are listed deliberately do not get assigned or referenced in the current source unit after the occurrence of the pragma in the current source unit. This suppresses warnings about the entities that are unreferenced and/or not assigned, and, in addition, a warning will be generated if one of these entities gets assigned or subsequently referenced in the same unit as the pragma (in the corresponding body or one of its subunits). This is particularly useful for clearly signaling that a particular parameter is not modified or referenced, even though the spec suggests that it might be. For the variable case, warnings are never given for unreferenced variables whose name contains one of the substrings ‘DISCARD, DUMMY, IGNORE, JUNK, UNUSED’ in any casing. Such names are typically to be used in cases where such warnings are expected. Thus it is never necessary to use ‘pragma Unused’ for such variables, though it is harmless to do so.  File: gnat_rm.info, Node: Pragma Use_VADS_Size, Next: Pragma Validity_Checks, Prev: Pragma Unused, Up: Implementation Defined Pragmas 2.195 Pragma Use_VADS_Size ========================== Syntax: pragma Use_VADS_Size; This is a configuration pragma. In a unit to which it applies, any use of the ‘Size attribute is automatically interpreted as a use of the ‘VADS_Size attribute. Note that this may result in incorrect semantic processing of valid Ada 95 or Ada 2005 programs. This is intended to aid in the handling of existing code which depends on the interpretation of Size as implemented in the VADS compiler. See description of the VADS_Size attribute for further details.  File: gnat_rm.info, Node: Pragma Validity_Checks, Next: Pragma Volatile, Prev: Pragma Use_VADS_Size, Up: Implementation Defined Pragmas 2.196 Pragma Validity_Checks ============================ Syntax: pragma Validity_Checks (string_LITERAL | ALL_CHECKS | On | Off); This pragma is used in conjunction with compiler switches to control the built-in validity checking provided by GNAT. The compiler switches, if set provide an initial setting for the switches, and this pragma may be used to modify these settings, or the settings may be provided entirely by the use of the pragma. This pragma can be used anywhere that a pragma is legal, including use as a configuration pragma (including use in the ‘gnat.adc’ file). The form with a string literal specifies which validity options are to be activated. The validity checks are first set to include only the default reference manual settings, and then a string of letters in the string specifies the exact set of options required. The form of this string is exactly as described for the '-gnatVx' compiler switch (see the GNAT User’s Guide for details). For example the following two methods can be used to enable validity checking for mode ‘in’ and ‘in out’ subprogram parameters: * pragma Validity_Checks ("im"); * $ gcc -c -gnatVim ... The form ALL_CHECKS activates all standard checks (its use is equivalent to the use of the ‘gnatVa’ switch). The forms with ‘Off’ and ‘On’ can be used to temporarily disable validity checks as shown in the following example: pragma Validity_Checks ("c"); -- validity checks for copies pragma Validity_Checks (Off); -- turn off validity checks A := B; -- B will not be validity checked pragma Validity_Checks (On); -- turn validity checks back on A := C; -- C will be validity checked  File: gnat_rm.info, Node: Pragma Volatile, Next: Pragma Volatile_Full_Access, Prev: Pragma Validity_Checks, Up: Implementation Defined Pragmas 2.197 Pragma Volatile ===================== Syntax: pragma Volatile (LOCAL_NAME); This pragma is defined by the Ada Reference Manual, and the GNAT implementation is fully conformant with this definition. The reason it is mentioned in this section is that a pragma of the same name was supplied in some Ada 83 compilers, including DEC Ada 83. The Ada 95 / Ada 2005 implementation of pragma Volatile is upwards compatible with the implementation in DEC Ada 83.  File: gnat_rm.info, Node: Pragma Volatile_Full_Access, Next: Pragma Volatile_Function, Prev: Pragma Volatile, Up: Implementation Defined Pragmas 2.198 Pragma Volatile_Full_Access ================================= Syntax: pragma Volatile_Full_Access (LOCAL_NAME); This is similar in effect to pragma Volatile, except that any reference to the object is guaranteed to be done only with instructions that read or write all the bits of the object. Furthermore, if the object is of a composite type, then any reference to a subcomponent of the object is guaranteed to read and/or write all the bits of the object. The intention is that this be suitable for use with memory-mapped I/O devices on some machines. Note that there are two important respects in which this is different from ‘pragma Atomic’. First a reference to a ‘Volatile_Full_Access’ object is not a sequential action in the RM 9.10 sense and, therefore, does not create a synchronization point. Second, in the case of ‘pragma Atomic’, there is no guarantee that all the bits will be accessed if the reference is not to the whole object; the compiler is allowed (and generally will) access only part of the object in this case.  File: gnat_rm.info, Node: Pragma Volatile_Function, Next: Pragma Warning_As_Error, Prev: Pragma Volatile_Full_Access, Up: Implementation Defined Pragmas 2.199 Pragma Volatile_Function ============================== Syntax: pragma Volatile_Function [ (static_boolean_EXPRESSION) ]; For the semantics of this pragma, see the entry for aspect ‘Volatile_Function’ in the SPARK 2014 Reference Manual, section 7.1.2.  File: gnat_rm.info, Node: Pragma Warning_As_Error, Next: Pragma Warnings, Prev: Pragma Volatile_Function, Up: Implementation Defined Pragmas 2.200 Pragma Warning_As_Error ============================= Syntax: pragma Warning_As_Error (static_string_EXPRESSION); This configuration pragma allows the programmer to specify a set of warnings that will be treated as errors. Any warning that matches the pattern given by the pragma argument will be treated as an error. This gives more precise control than -gnatwe, which treats warnings as errors. This pragma can apply to regular warnings (messages enabled by -gnatw) and to style warnings (messages that start with “(style)”, enabled by -gnaty). The pattern may contain asterisks, which match zero or more characters in the message. For example, you can use ‘pragma Warning_As_Error ("bits of*unused")’ to treat the warning message ‘warning: 960 bits of "a" unused’ as an error. All characters other than asterisk are treated as literal characters in the match. The match is case insensitive; for example XYZ matches xyz. Note that the pattern matches if it occurs anywhere within the warning message string (it is not necessary to put an asterisk at the start and the end of the message, since this is implied). Another possibility for the static_string_EXPRESSION which works whether or not error tags are enabled ('-gnatw.d') is to use a single '-gnatw' tag string, enclosed in brackets, as shown in the example below, to treat one category of warnings as errors. Note that if you want to treat multiple categories of warnings as errors, you can use multiple pragma Warning_As_Error. The above use of patterns to match the message applies only to warning messages generated by the front end. This pragma can also be applied to warnings provided by the back end and mentioned in *note Pragma Warnings: 122. By using a single full '-Wxxx' switch in the pragma, such warnings can also be treated as errors. The pragma can appear either in a global configuration pragma file (e.g. ‘gnat.adc’), or at the start of a file. Given a global configuration pragma file containing: pragma Warning_As_Error ("[-gnatwj]"); which will treat all obsolescent feature warnings as errors, the following program compiles as shown (compile options here are '-gnatwa.d -gnatl -gnatj55'). 1. pragma Warning_As_Error ("*never assigned*"); 2. function Warnerr return String is 3. X : Integer; | >>> error: variable "X" is never read and never assigned [-gnatwv] [warning-as-error] 4. Y : Integer; | >>> warning: variable "Y" is assigned but never read [-gnatwu] 5. begin 6. Y := 0; 7. return %ABC%; | >>> error: use of "%" is an obsolescent feature (RM J.2(4)), use """ instead [-gnatwj] [warning-as-error] 8. end; 8 lines: No errors, 3 warnings (2 treated as errors) Note that this pragma does not affect the set of warnings issued in any way, it merely changes the effect of a matching warning if one is produced as a result of other warnings options. As shown in this example, if the pragma results in a warning being treated as an error, the tag is changed from “warning:” to “error:” and the string “[warning-as-error]” is appended to the end of the message.  File: gnat_rm.info, Node: Pragma Warnings, Next: Pragma Weak_External, Prev: Pragma Warning_As_Error, Up: Implementation Defined Pragmas 2.201 Pragma Warnings ===================== Syntax: pragma Warnings ([TOOL_NAME,] DETAILS [, REASON]); DETAILS ::= On | Off DETAILS ::= On | Off, local_NAME DETAILS ::= static_string_EXPRESSION DETAILS ::= On | Off, static_string_EXPRESSION TOOL_NAME ::= GNAT | GNATprove REASON ::= Reason => STRING_LITERAL {& STRING_LITERAL} Note: in Ada 83 mode, a string literal may be used in place of a static string expression (which does not exist in Ada 83). Note if the second argument of ‘DETAILS’ is a ‘local_NAME’ then the second form is always understood. If the intention is to use the fourth form, then you can write ‘NAME & ""’ to force the interpretation as a 'static_string_EXPRESSION'. Note: if the first argument is a valid ‘TOOL_NAME’, it will be interpreted that way. The use of the ‘TOOL_NAME’ argument is relevant only to users of SPARK and GNATprove, see last part of this section for details. Normally warnings are enabled, with the output being controlled by the command line switch. Warnings (‘Off’) turns off generation of warnings until a Warnings (‘On’) is encountered or the end of the current unit. If generation of warnings is turned off using this pragma, then some or all of the warning messages are suppressed, regardless of the setting of the command line switches. The ‘Reason’ parameter may optionally appear as the last argument in any of the forms of this pragma. It is intended purely for the purposes of documenting the reason for the ‘Warnings’ pragma. The compiler will check that the argument is a static string but otherwise ignore this argument. Other tools may provide specialized processing for this string. The form with a single argument (or two arguments if Reason present), where the first argument is ‘ON’ or ‘OFF’ may be used as a configuration pragma. If the ‘LOCAL_NAME’ parameter is present, warnings are suppressed for the specified entity. This suppression is effective from the point where it occurs till the end of the extended scope of the variable (similar to the scope of ‘Suppress’). This form cannot be used as a configuration pragma. In the case where the first argument is other than ‘ON’ or ‘OFF’, the third form with a single static_string_EXPRESSION argument (and possible reason) provides more precise control over which warnings are active. The string is a list of letters specifying which warnings are to be activated and which deactivated. The code for these letters is the same as the string used in the command line switch controlling warnings. For a brief summary, use the gnatmake command with no arguments, which will generate usage information containing the list of warnings switches supported. For full details see the section on ‘Warning Message Control’ in the ‘GNAT User’s Guide’. This form can also be used as a configuration pragma. The warnings controlled by the ‘-gnatw’ switch are generated by the front end of the compiler. The GCC back end can provide additional warnings and they are controlled by the ‘-W’ switch. Such warnings can be identified by the appearance of a string of the form ‘[-W{xxx}]’ in the message which designates the ‘-W`xxx'’ switch that controls the message. The form with a single 'static_string_EXPRESSION' argument also works for these warnings, but the string must be a single full ‘-W`xxx'’ switch in this case. The above reference lists a few examples of these additional warnings. The specified warnings will be in effect until the end of the program or another pragma ‘Warnings’ is encountered. The effect of the pragma is cumulative. Initially the set of warnings is the standard default set as possibly modified by compiler switches. Then each pragma Warning modifies this set of warnings as specified. This form of the pragma may also be used as a configuration pragma. The fourth form, with an ‘On|Off’ parameter and a string, is used to control individual messages, based on their text. The string argument is a pattern that is used to match against the text of individual warning messages (not including the initial “warning: ” tag). The pattern may contain asterisks, which match zero or more characters in the message. For example, you can use ‘pragma Warnings (Off, "bits of*unused")’ to suppress the warning message ‘warning: 960 bits of "a" unused’. No other regular expression notations are permitted. All characters other than asterisk in these three specific cases are treated as literal characters in the match. The match is case insensitive, for example XYZ matches xyz. Note that the pattern matches if it occurs anywhere within the warning message string (it is not necessary to put an asterisk at the start and the end of the message, since this is implied). The above use of patterns to match the message applies only to warning messages generated by the front end. This form of the pragma with a string argument can also be used to control warnings provided by the back end and mentioned above. By using a single full ‘-W`xxx'’ switch in the pragma, such warnings can be turned on and off. There are two ways to use the pragma in this form. The OFF form can be used as a configuration pragma. The effect is to suppress all warnings (if any) that match the pattern string throughout the compilation (or match the -W switch in the back end case). The second usage is to suppress a warning locally, and in this case, two pragmas must appear in sequence: pragma Warnings (Off, Pattern); ... code where given warning is to be suppressed pragma Warnings (On, Pattern); In this usage, the pattern string must match in the Off and On pragmas, and (if '-gnatw.w' is given) at least one matching warning must be suppressed. Note: if the ON form is not found, then the effect of the OFF form extends until the end of the file (pragma Warnings is purely textual, so its effect does not stop at the end of the enclosing scope). Note: to write a string that will match any warning, use the string ‘"***"’. It will not work to use a single asterisk or two asterisks since this looks like an operator name. This form with three asterisks is similar in effect to specifying ‘pragma Warnings (Off)’ except (if ‘-gnatw.w’ is given) that a matching ‘pragma Warnings (On, "***")’ will be required. This can be helpful in avoiding forgetting to turn warnings back on. Note: the debug flag ‘-gnatd.i’ can be used to cause the compiler to entirely ignore all WARNINGS pragmas. This can be useful in checking whether obsolete pragmas in existing programs are hiding real problems. Note: pragma Warnings does not affect the processing of style messages. See separate entry for pragma Style_Checks for control of style messages. Users of the formal verification tool GNATprove for the SPARK subset of Ada may use the version of the pragma with a ‘TOOL_NAME’ parameter. If present, ‘TOOL_NAME’ is the name of a tool, currently either ‘GNAT’ for the compiler or ‘GNATprove’ for the formal verification tool. A given tool only takes into account pragma Warnings that do not specify a tool name, or that specify the matching tool name. This makes it possible to disable warnings selectively for each tool, and as a consequence to detect useless pragma Warnings with switch ‘-gnatw.w’.  File: gnat_rm.info, Node: Pragma Weak_External, Next: Pragma Wide_Character_Encoding, Prev: Pragma Warnings, Up: Implementation Defined Pragmas 2.202 Pragma Weak_External ========================== Syntax: pragma Weak_External ([Entity =>] LOCAL_NAME); ‘LOCAL_NAME’ must refer to an object that is declared at the library level. This pragma specifies that the given entity should be marked as a weak symbol for the linker. It is equivalent to ‘__attribute__((weak))’ in GNU C and causes ‘LOCAL_NAME’ to be emitted as a weak symbol instead of a regular symbol, that is to say a symbol that does not have to be resolved by the linker if used in conjunction with a pragma Import. When a weak symbol is not resolved by the linker, its address is set to zero. This is useful in writing interfaces to external modules that may or may not be linked in the final executable, for example depending on configuration settings. If a program references at run time an entity to which this pragma has been applied, and the corresponding symbol was not resolved at link time, then the execution of the program is erroneous. It is not erroneous to take the Address of such an entity, for example to guard potential references, as shown in the example below. Some file formats do not support weak symbols so not all target machines support this pragma. -- Example of the use of pragma Weak_External package External_Module is key : Integer; pragma Import (C, key); pragma Weak_External (key); function Present return boolean; end External_Module; with System; use System; package body External_Module is function Present return boolean is begin return key'Address /= System.Null_Address; end Present; end External_Module;  File: gnat_rm.info, Node: Pragma Wide_Character_Encoding, Prev: Pragma Weak_External, Up: Implementation Defined Pragmas 2.203 Pragma Wide_Character_Encoding ==================================== Syntax: pragma Wide_Character_Encoding (IDENTIFIER | CHARACTER_LITERAL); This pragma specifies the wide character encoding to be used in program source text appearing subsequently. It is a configuration pragma, but may also be used at any point that a pragma is allowed, and it is permissible to have more than one such pragma in a file, allowing multiple encodings to appear within the same file. However, note that the pragma cannot immediately precede the relevant wide character, because then the previous encoding will still be in effect, causing “illegal character” errors. The argument can be an identifier or a character literal. In the identifier case, it is one of ‘HEX’, ‘UPPER’, ‘SHIFT_JIS’, ‘EUC’, ‘UTF8’, or ‘BRACKETS’. In the character literal case it is correspondingly one of the characters ‘h’, ‘u’, ‘s’, ‘e’, ‘8’, or ‘b’. Note that when the pragma is used within a file, it affects only the encoding within that file, and does not affect withed units, specs, or subunits.  File: gnat_rm.info, Node: Implementation Defined Aspects, Next: Implementation Defined Attributes, Prev: Implementation Defined Pragmas, Up: Top 3 Implementation Defined Aspects ******************************** Ada defines (throughout the Ada 2012 reference manual, summarized in Annex K) a set of aspects that can be specified for certain entities. These language defined aspects are implemented in GNAT in Ada 2012 mode and work as described in the Ada 2012 Reference Manual. In addition, Ada 2012 allows implementations to define additional aspects whose meaning is defined by the implementation. GNAT provides a number of these implementation-defined aspects which can be used to extend and enhance the functionality of the compiler. This section of the GNAT reference manual describes these additional aspects. Note that any program using these aspects may not be portable to other compilers (although GNAT implements this set of aspects on all platforms). Therefore if portability to other compilers is an important consideration, you should minimize the use of these aspects. Note that for many of these aspects, the effect is essentially similar to the use of a pragma or attribute specification with the same name applied to the entity. For example, if we write: type R is range 1 .. 100 with Value_Size => 10; then the effect is the same as: type R is range 1 .. 100; for R'Value_Size use 10; and if we write: type R is new Integer with Shared => True; then the effect is the same as: type R is new Integer; pragma Shared (R); In the documentation below, such cases are simply marked as being boolean aspects equivalent to the corresponding pragma or attribute definition clause. * Menu: * Aspect Abstract_State:: * Aspect Always_Terminates:: * Aspect Annotate:: * Aspect Async_Readers:: * Aspect Async_Writers:: * Aspect Constant_After_Elaboration:: * Aspect Contract_Cases:: * Aspect Depends:: * Aspect Default_Initial_Condition:: * Aspect Dimension:: * Aspect Dimension_System:: * Aspect Disable_Controlled:: * Aspect Effective_Reads:: * Aspect Effective_Writes:: * Aspect Extensions_Visible:: * Aspect Favor_Top_Level:: * Aspect Ghost:: * Aspect Ghost_Predicate:: * Aspect Global:: * Aspect Initial_Condition:: * Aspect Initializes:: * Aspect Inline_Always:: * Aspect Invariant:: * Aspect Invariant’Class:: * Aspect Iterable:: * Aspect Linker_Section:: * Aspect Local_Restrictions:: * Aspect Lock_Free:: * Aspect Max_Queue_Length:: * Aspect No_Caching:: * Aspect No_Elaboration_Code_All:: * Aspect No_Inline:: * Aspect No_Tagged_Streams:: * Aspect No_Task_Parts:: * Aspect Object_Size:: * Aspect Obsolescent:: * Aspect Part_Of:: * Aspect Persistent_BSS:: * Aspect Predicate:: * Aspect Pure_Function:: * Aspect Refined_Depends:: * Aspect Refined_Global:: * Aspect Refined_Post:: * Aspect Refined_State:: * Aspect Relaxed_Initialization:: * Aspect Remote_Access_Type:: * Aspect Secondary_Stack_Size:: * Aspect Scalar_Storage_Order:: * Aspect Shared:: * Aspect Side_Effects:: * Aspect Simple_Storage_Pool:: * Aspect Simple_Storage_Pool_Type:: * Aspect SPARK_Mode:: * Aspect Suppress_Debug_Info:: * Aspect Suppress_Initialization:: * Aspect Test_Case:: * Aspect Thread_Local_Storage:: * Aspect Universal_Aliasing:: * Aspect Unmodified:: * Aspect Unreferenced:: * Aspect Unreferenced_Objects:: * Aspect User_Aspect:: * Aspect Value_Size:: * Aspect Volatile_Full_Access:: * Aspect Volatile_Function:: * Aspect Warnings::  File: gnat_rm.info, Node: Aspect Abstract_State, Next: Aspect Always_Terminates, Up: Implementation Defined Aspects 3.1 Aspect Abstract_State ========================= This aspect is equivalent to *note pragma Abstract_State: 1e.  File: gnat_rm.info, Node: Aspect Always_Terminates, Next: Aspect Annotate, Prev: Aspect Abstract_State, Up: Implementation Defined Aspects 3.2 Aspect Always_Terminates ============================ This boolean aspect is equivalent to *note pragma Always_Terminates: 29.  File: gnat_rm.info, Node: Aspect Annotate, Next: Aspect Async_Readers, Prev: Aspect Always_Terminates, Up: Implementation Defined Aspects 3.3 Aspect Annotate =================== There are three forms of this aspect (where ID is an identifier, and ARG is a general expression), corresponding to *note pragma Annotate: 2b. 'Annotate => ID' Equivalent to ‘pragma Annotate (ID, Entity => Name);’ 'Annotate => (ID)' Equivalent to ‘pragma Annotate (ID, Entity => Name);’ 'Annotate => (ID ,ID {, ARG})' Equivalent to ‘pragma Annotate (ID, ID {, ARG}, Entity => Name);’  File: gnat_rm.info, Node: Aspect Async_Readers, Next: Aspect Async_Writers, Prev: Aspect Annotate, Up: Implementation Defined Aspects 3.4 Aspect Async_Readers ======================== This boolean aspect is equivalent to *note pragma Async_Readers: 32.  File: gnat_rm.info, Node: Aspect Async_Writers, Next: Aspect Constant_After_Elaboration, Prev: Aspect Async_Readers, Up: Implementation Defined Aspects 3.5 Aspect Async_Writers ======================== This boolean aspect is equivalent to *note pragma Async_Writers: 34.  File: gnat_rm.info, Node: Aspect Constant_After_Elaboration, Next: Aspect Contract_Cases, Prev: Aspect Async_Writers, Up: Implementation Defined Aspects 3.6 Aspect Constant_After_Elaboration ===================================== This aspect is equivalent to *note pragma Constant_After_Elaboration: 44.  File: gnat_rm.info, Node: Aspect Contract_Cases, Next: Aspect Depends, Prev: Aspect Constant_After_Elaboration, Up: Implementation Defined Aspects 3.7 Aspect Contract_Cases ========================= This aspect is equivalent to *note pragma Contract_Cases: 46, the sequence of clauses being enclosed in parentheses so that syntactically it is an aggregate.  File: gnat_rm.info, Node: Aspect Depends, Next: Aspect Default_Initial_Condition, Prev: Aspect Contract_Cases, Up: Implementation Defined Aspects 3.8 Aspect Depends ================== This aspect is equivalent to *note pragma Depends: 56.  File: gnat_rm.info, Node: Aspect Default_Initial_Condition, Next: Aspect Dimension, Prev: Aspect Depends, Up: Implementation Defined Aspects 3.9 Aspect Default_Initial_Condition ==================================== This aspect is equivalent to *note pragma Default_Initial_Condition: 52.  File: gnat_rm.info, Node: Aspect Dimension, Next: Aspect Dimension_System, Prev: Aspect Default_Initial_Condition, Up: Implementation Defined Aspects 3.10 Aspect Dimension ===================== The ‘Dimension’ aspect is used to specify the dimensions of a given subtype of a dimensioned numeric type. The aspect also specifies a symbol used when doing formatted output of dimensioned quantities. The syntax is: with Dimension => ([Symbol =>] SYMBOL, DIMENSION_VALUE {, DIMENSION_Value}) SYMBOL ::= STRING_LITERAL | CHARACTER_LITERAL DIMENSION_VALUE ::= RATIONAL | others => RATIONAL | DISCRETE_CHOICE_LIST => RATIONAL RATIONAL ::= [-] NUMERIC_LITERAL [/ NUMERIC_LITERAL] This aspect can only be applied to a subtype whose parent type has a ‘Dimension_System’ aspect. The aspect must specify values for all dimensions of the system. The rational values are the powers of the corresponding dimensions that are used by the compiler to verify that physical (numeric) computations are dimensionally consistent. For example, the computation of a force must result in dimensions (L => 1, M => 1, T => -2). For further examples of the usage of this aspect, see package ‘System.Dim.Mks’. Note that when the dimensioned type is an integer type, then any dimension value must be an integer literal.  File: gnat_rm.info, Node: Aspect Dimension_System, Next: Aspect Disable_Controlled, Prev: Aspect Dimension, Up: Implementation Defined Aspects 3.11 Aspect Dimension_System ============================ The ‘Dimension_System’ aspect is used to define a system of dimensions that will be used in subsequent subtype declarations with ‘Dimension’ aspects that reference this system. The syntax is: with Dimension_System => (DIMENSION {, DIMENSION}); DIMENSION ::= ([Unit_Name =>] IDENTIFIER, [Unit_Symbol =>] SYMBOL, [Dim_Symbol =>] SYMBOL) SYMBOL ::= CHARACTER_LITERAL | STRING_LITERAL This aspect is applied to a type, which must be a numeric derived type (typically a floating-point type), that will represent values within the dimension system. Each ‘DIMENSION’ corresponds to one particular dimension. A maximum of 7 dimensions may be specified. ‘Unit_Name’ is the name of the dimension (for example ‘Meter’). ‘Unit_Symbol’ is the shorthand used for quantities of this dimension (for example ‘m’ for ‘Meter’). ‘Dim_Symbol’ gives the identification within the dimension system (typically this is a single letter, e.g. ‘L’ standing for length for unit name ‘Meter’). The ‘Unit_Symbol’ is used in formatted output of dimensioned quantities. The ‘Dim_Symbol’ is used in error messages when numeric operations have inconsistent dimensions. GNAT provides the standard definition of the International MKS system in the run-time package ‘System.Dim.Mks’. You can easily define similar packages for cgs units or British units, and define conversion factors between values in different systems. The MKS system is characterized by the following aspect: type Mks_Type is new Long_Long_Float with Dimension_System => ( (Unit_Name => Meter, Unit_Symbol => 'm', Dim_Symbol => 'L'), (Unit_Name => Kilogram, Unit_Symbol => "kg", Dim_Symbol => 'M'), (Unit_Name => Second, Unit_Symbol => 's', Dim_Symbol => 'T'), (Unit_Name => Ampere, Unit_Symbol => 'A', Dim_Symbol => 'I'), (Unit_Name => Kelvin, Unit_Symbol => 'K', Dim_Symbol => '@'), (Unit_Name => Mole, Unit_Symbol => "mol", Dim_Symbol => 'N'), (Unit_Name => Candela, Unit_Symbol => "cd", Dim_Symbol => 'J')); Note that in the above type definition, we use the ‘at’ symbol (‘@’) to represent a theta character (avoiding the use of extended Latin-1 characters in this context). See section ‘Performing Dimensionality Analysis in GNAT’ in the GNAT Users Guide for detailed examples of use of the dimension system.  File: gnat_rm.info, Node: Aspect Disable_Controlled, Next: Aspect Effective_Reads, Prev: Aspect Dimension_System, Up: Implementation Defined Aspects 3.12 Aspect Disable_Controlled ============================== The aspect ‘Disable_Controlled’ is defined for controlled record types. If active, this aspect causes suppression of all related calls to ‘Initialize’, ‘Adjust’, and ‘Finalize’. The intended use is for conditional compilation, where for example you might want a record to be controlled or not depending on whether some run-time check is enabled or suppressed.  File: gnat_rm.info, Node: Aspect Effective_Reads, Next: Aspect Effective_Writes, Prev: Aspect Disable_Controlled, Up: Implementation Defined Aspects 3.13 Aspect Effective_Reads =========================== This aspect is equivalent to *note pragma Effective_Reads: 5b.  File: gnat_rm.info, Node: Aspect Effective_Writes, Next: Aspect Extensions_Visible, Prev: Aspect Effective_Reads, Up: Implementation Defined Aspects 3.14 Aspect Effective_Writes ============================ This aspect is equivalent to *note pragma Effective_Writes: 5d.  File: gnat_rm.info, Node: Aspect Extensions_Visible, Next: Aspect Favor_Top_Level, Prev: Aspect Effective_Writes, Up: Implementation Defined Aspects 3.15 Aspect Extensions_Visible ============================== This aspect is equivalent to *note pragma Extensions_Visible: 6b.  File: gnat_rm.info, Node: Aspect Favor_Top_Level, Next: Aspect Ghost, Prev: Aspect Extensions_Visible, Up: Implementation Defined Aspects 3.16 Aspect Favor_Top_Level =========================== This boolean aspect is equivalent to *note pragma Favor_Top_Level: 70.  File: gnat_rm.info, Node: Aspect Ghost, Next: Aspect Ghost_Predicate, Prev: Aspect Favor_Top_Level, Up: Implementation Defined Aspects 3.17 Aspect Ghost ================= This aspect is equivalent to *note pragma Ghost: 74.  File: gnat_rm.info, Node: Aspect Ghost_Predicate, Next: Aspect Global, Prev: Aspect Ghost, Up: Implementation Defined Aspects 3.18 Aspect Ghost_Predicate =========================== This aspect introduces a subtype predicate that can reference ghost entities. The subtype cannot appear as a subtype_mark in a membership test. For the detailed semantics of this aspect, see the entry for subtype predicates in the SPARK Reference Manual, section 3.2.4.  File: gnat_rm.info, Node: Aspect Global, Next: Aspect Initial_Condition, Prev: Aspect Ghost_Predicate, Up: Implementation Defined Aspects 3.19 Aspect Global ================== This aspect is equivalent to *note pragma Global: 76.  File: gnat_rm.info, Node: Aspect Initial_Condition, Next: Aspect Initializes, Prev: Aspect Global, Up: Implementation Defined Aspects 3.20 Aspect Initial_Condition ============================= This aspect is equivalent to *note pragma Initial_Condition: 83.  File: gnat_rm.info, Node: Aspect Initializes, Next: Aspect Inline_Always, Prev: Aspect Initial_Condition, Up: Implementation Defined Aspects 3.21 Aspect Initializes ======================= This aspect is equivalent to *note pragma Initializes: 86.  File: gnat_rm.info, Node: Aspect Inline_Always, Next: Aspect Invariant, Prev: Aspect Initializes, Up: Implementation Defined Aspects 3.22 Aspect Inline_Always ========================= This boolean aspect is equivalent to *note pragma Inline_Always: 88.  File: gnat_rm.info, Node: Aspect Invariant, Next: Aspect Invariant’Class, Prev: Aspect Inline_Always, Up: Implementation Defined Aspects 3.23 Aspect Invariant ===================== This aspect is equivalent to *note pragma Invariant: 8f. It is a synonym for the language defined aspect ‘Type_Invariant’ except that it is separately controllable using pragma ‘Assertion_Policy’.  File: gnat_rm.info, Node: Aspect Invariant’Class, Next: Aspect Iterable, Prev: Aspect Invariant, Up: Implementation Defined Aspects 3.24 Aspect Invariant’Class =========================== This aspect is equivalent to *note pragma Type_Invariant_Class: 108. It is a synonym for the language defined aspect ‘Type_Invariant'Class’ except that it is separately controllable using pragma ‘Assertion_Policy’.  File: gnat_rm.info, Node: Aspect Iterable, Next: Aspect Linker_Section, Prev: Aspect Invariant’Class, Up: Implementation Defined Aspects 3.25 Aspect Iterable ==================== This aspect provides a light-weight mechanism for loops and quantified expressions over container types, without the overhead imposed by the tampering checks of standard Ada 2012 iterators. The value of the aspect is an aggregate with six named components, of which the last three are optional: ‘First’, ‘Next’, ‘Has_Element’, ‘Element’, ‘Last’, and ‘Previous’. When only the first three components are specified, only the ‘for .. in’ form of iteration over cursors is available. When ‘Element’ is specified, both this form and the ‘for .. of’ form of iteration over elements are available. If the last two components are specified, reverse iterations over the container can be specified (analogous to what can be done over predefined containers that support the ‘Reverse_Iterator’ interface). The following is a typical example of use: type List is private with Iterable => (First => First_Cursor, Next => Advance, Has_Element => Cursor_Has_Element [,Element => Get_Element] [,Last => Last_Cursor] [,Previous => Retreat]); * The values of ‘First’ and ‘Last’ are primitive operations of the container type that return a ‘Cursor’, which must be a type declared in the container package or visible from it. For example: function First_Cursor (Cont : Container) return Cursor; function Last_Cursor (Cont : Container) return Cursor; * The values of ‘Next’ and ‘Previous’ are primitive operations of the container type that take both a container and a cursor and yield a cursor. For example: function Advance (Cont : Container; Position : Cursor) return Cursor; function Retreat (Cont : Container; Position : Cursor) return Cursor; * The value of ‘Has_Element’ is a primitive operation of the container type that takes both a container and a cursor and yields a boolean. For example: function Cursor_Has_Element (Cont : Container; Position : Cursor) return Boolean; * The value of ‘Element’ is a primitive operation of the container type that takes both a container and a cursor and yields an ‘Element_Type’, which must be a type declared in the container package or visible from it. For example: function Get_Element (Cont : Container; Position : Cursor) return Element_Type; This aspect is used in the GNAT-defined formal container packages.  File: gnat_rm.info, Node: Aspect Linker_Section, Next: Aspect Local_Restrictions, Prev: Aspect Iterable, Up: Implementation Defined Aspects 3.26 Aspect Linker_Section ========================== This aspect is equivalent to *note pragma Linker_Section: 97.  File: gnat_rm.info, Node: Aspect Local_Restrictions, Next: Aspect Lock_Free, Prev: Aspect Linker_Section, Up: Implementation Defined Aspects 3.27 Aspect Local_Restrictions ============================== This aspect may be specified for a subprogram (and for other declarations as described below). It is used to specify that a particular subprogram does not violate one or more local restrictions, nor can it call a subprogram that is not subject to the same requirement. Positional aggregate syntax (with parentheses, not square brackets) may be used to specify more than one local restriction, as in procedure Do_Something with Local_Restrictions => (Some_Restriction, Another_Restriction); Parentheses are currently required even in the case of specifying a single local restriction (this requirement may be relaxed in the future). Supported local restrictions currently include (only) No_Heap_Allocations and No_Secondary_Stack. No_Secondary_Stack corresponds to the GNAT-defined (global) restriction of the same name. No_Heap_Allocations corresponds to the conjunction of the Ada-defined restrictions No_Allocators and No_Implicit_Heap_Allocations. Additional requirements are imposed in order to ensure that restriction violations cannot be achieved via overriding dispatching operations, calling through an access-to-subprogram value, calling a generic formal subprogram, or calling through a subprogram renaming. For a dispatching operation, an overrider must be subject to (at least) the same restrictions as the overridden inherited subprogram; similarly, the actual subprogram corresponding to a generic formal subprogram in an instantiation must be subject to (at least) the same restrictions as the formal subprogram. A call through an access-to-subprogram value is conservatively assumed to violate all local restrictions; tasking-related constructs (notably entry calls) are treated similarly. A renaming-as-body is treated like a subprogram body containing a call to the renamed subprogram. The Local_Restrictions aspect can be specified for a package specification, in which case the aspect specification also applies to all eligible entities declared with the package. This includes types. Default initialization of an object of a given type is treated like a call to an implicitly-declared initialization subprogram. Such a “call” is subject to the same local restriction checks as any other call. If a type is subject to a local restriction, then any violations of that restriction within the default initialization expressions (if any) of the type are rejected. This may include “calls” to the default initialization subprograms of other types. Local_Restrictions aspect specifications are additive (for example, in the case of a declaration that occurs within nested packages that each have a Local_Restrictions specification).  File: gnat_rm.info, Node: Aspect Lock_Free, Next: Aspect Max_Queue_Length, Prev: Aspect Local_Restrictions, Up: Implementation Defined Aspects 3.28 Aspect Lock_Free ===================== This boolean aspect is equivalent to *note pragma Lock_Free: 99.  File: gnat_rm.info, Node: Aspect Max_Queue_Length, Next: Aspect No_Caching, Prev: Aspect Lock_Free, Up: Implementation Defined Aspects 3.29 Aspect Max_Queue_Length ============================ This aspect is equivalent to *note pragma Max_Queue_Length: a1.  File: gnat_rm.info, Node: Aspect No_Caching, Next: Aspect No_Elaboration_Code_All, Prev: Aspect Max_Queue_Length, Up: Implementation Defined Aspects 3.30 Aspect No_Caching ====================== This boolean aspect is equivalent to *note pragma No_Caching: a4.  File: gnat_rm.info, Node: Aspect No_Elaboration_Code_All, Next: Aspect No_Inline, Prev: Aspect No_Caching, Up: Implementation Defined Aspects 3.31 Aspect No_Elaboration_Code_All =================================== This aspect is equivalent to *note pragma No_Elaboration_Code_All: a7. for a program unit.  File: gnat_rm.info, Node: Aspect No_Inline, Next: Aspect No_Tagged_Streams, Prev: Aspect No_Elaboration_Code_All, Up: Implementation Defined Aspects 3.32 Aspect No_Inline ===================== This boolean aspect is equivalent to *note pragma No_Inline: aa.  File: gnat_rm.info, Node: Aspect No_Tagged_Streams, Next: Aspect No_Task_Parts, Prev: Aspect No_Inline, Up: Implementation Defined Aspects 3.33 Aspect No_Tagged_Streams ============================= This aspect is equivalent to *note pragma No_Tagged_Streams: ae. with an argument specifying a root tagged type (thus this aspect can only be applied to such a type).  File: gnat_rm.info, Node: Aspect No_Task_Parts, Next: Aspect Object_Size, Prev: Aspect No_Tagged_Streams, Up: Implementation Defined Aspects 3.34 Aspect No_Task_Parts ========================= Applies to a type. If True, requires that the type and any descendants do not have any task parts. The rules for this aspect are the same as for the language-defined No_Controlled_Parts aspect (see RM-H.4.1), replacing “controlled” with “task”. If No_Task_Parts is True for a type T, then the compiler can optimize away certain tasking-related code that would otherwise be needed for T’Class, because descendants of T might contain tasks.  File: gnat_rm.info, Node: Aspect Object_Size, Next: Aspect Obsolescent, Prev: Aspect No_Task_Parts, Up: Implementation Defined Aspects 3.35 Aspect Object_Size ======================= This aspect is equivalent to *note attribute Object_Size: 14c.  File: gnat_rm.info, Node: Aspect Obsolescent, Next: Aspect Part_Of, Prev: Aspect Object_Size, Up: Implementation Defined Aspects 3.36 Aspect Obsolescent ======================= This aspect is equivalent to *note pragma Obsolescent: b1. Note that the evaluation of this aspect happens at the point of occurrence, it is not delayed until the freeze point.  File: gnat_rm.info, Node: Aspect Part_Of, Next: Aspect Persistent_BSS, Prev: Aspect Obsolescent, Up: Implementation Defined Aspects 3.37 Aspect Part_Of =================== This aspect is equivalent to *note pragma Part_Of: b7.  File: gnat_rm.info, Node: Aspect Persistent_BSS, Next: Aspect Predicate, Prev: Aspect Part_Of, Up: Implementation Defined Aspects 3.38 Aspect Persistent_BSS ========================== This boolean aspect is equivalent to *note pragma Persistent_BSS: bb.  File: gnat_rm.info, Node: Aspect Predicate, Next: Aspect Pure_Function, Prev: Aspect Persistent_BSS, Up: Implementation Defined Aspects 3.39 Aspect Predicate ===================== This aspect is equivalent to *note pragma Predicate: c2. It is thus similar to the language defined aspects ‘Dynamic_Predicate’ and ‘Static_Predicate’ except that whether the resulting predicate is static or dynamic is controlled by the form of the expression. It is also separately controllable using pragma ‘Assertion_Policy’.  File: gnat_rm.info, Node: Aspect Pure_Function, Next: Aspect Refined_Depends, Prev: Aspect Predicate, Up: Implementation Defined Aspects 3.40 Aspect Pure_Function ========================= This boolean aspect is equivalent to *note pragma Pure_Function: ce.  File: gnat_rm.info, Node: Aspect Refined_Depends, Next: Aspect Refined_Global, Prev: Aspect Pure_Function, Up: Implementation Defined Aspects 3.41 Aspect Refined_Depends =========================== This aspect is equivalent to *note pragma Refined_Depends: d2.  File: gnat_rm.info, Node: Aspect Refined_Global, Next: Aspect Refined_Post, Prev: Aspect Refined_Depends, Up: Implementation Defined Aspects 3.42 Aspect Refined_Global ========================== This aspect is equivalent to *note pragma Refined_Global: d4.  File: gnat_rm.info, Node: Aspect Refined_Post, Next: Aspect Refined_State, Prev: Aspect Refined_Global, Up: Implementation Defined Aspects 3.43 Aspect Refined_Post ======================== This aspect is equivalent to *note pragma Refined_Post: d6.  File: gnat_rm.info, Node: Aspect Refined_State, Next: Aspect Relaxed_Initialization, Prev: Aspect Refined_Post, Up: Implementation Defined Aspects 3.44 Aspect Refined_State ========================= This aspect is equivalent to *note pragma Refined_State: d8.  File: gnat_rm.info, Node: Aspect Relaxed_Initialization, Next: Aspect Remote_Access_Type, Prev: Aspect Refined_State, Up: Implementation Defined Aspects 3.45 Aspect Relaxed_Initialization ================================== For the syntax and semantics of this aspect, see the SPARK 2014 Reference Manual, section 6.10.  File: gnat_rm.info, Node: Aspect Remote_Access_Type, Next: Aspect Secondary_Stack_Size, Prev: Aspect Relaxed_Initialization, Up: Implementation Defined Aspects 3.46 Aspect Remote_Access_Type ============================== This aspect is equivalent to *note pragma Remote_Access_Type: db.  File: gnat_rm.info, Node: Aspect Secondary_Stack_Size, Next: Aspect Scalar_Storage_Order, Prev: Aspect Remote_Access_Type, Up: Implementation Defined Aspects 3.47 Aspect Secondary_Stack_Size ================================ This aspect is equivalent to *note pragma Secondary_Stack_Size: e1.  File: gnat_rm.info, Node: Aspect Scalar_Storage_Order, Next: Aspect Shared, Prev: Aspect Secondary_Stack_Size, Up: Implementation Defined Aspects 3.48 Aspect Scalar_Storage_Order ================================ This aspect is equivalent to a *note attribute Scalar_Storage_Order: 15a.  File: gnat_rm.info, Node: Aspect Shared, Next: Aspect Side_Effects, Prev: Aspect Scalar_Storage_Order, Up: Implementation Defined Aspects 3.49 Aspect Shared ================== This boolean aspect is equivalent to *note pragma Shared: e4. and is thus a synonym for aspect ‘Atomic’.  File: gnat_rm.info, Node: Aspect Side_Effects, Next: Aspect Simple_Storage_Pool, Prev: Aspect Shared, Up: Implementation Defined Aspects 3.50 Aspect Side_Effects ======================== This aspect is equivalent to *note pragma Side_Effects: e8.  File: gnat_rm.info, Node: Aspect Simple_Storage_Pool, Next: Aspect Simple_Storage_Pool_Type, Prev: Aspect Side_Effects, Up: Implementation Defined Aspects 3.51 Aspect Simple_Storage_Pool =============================== This aspect is equivalent to *note attribute Simple_Storage_Pool: eb.  File: gnat_rm.info, Node: Aspect Simple_Storage_Pool_Type, Next: Aspect SPARK_Mode, Prev: Aspect Simple_Storage_Pool, Up: Implementation Defined Aspects 3.52 Aspect Simple_Storage_Pool_Type ==================================== This boolean aspect is equivalent to *note pragma Simple_Storage_Pool_Type: ea.  File: gnat_rm.info, Node: Aspect SPARK_Mode, Next: Aspect Suppress_Debug_Info, Prev: Aspect Simple_Storage_Pool_Type, Up: Implementation Defined Aspects 3.53 Aspect SPARK_Mode ====================== This aspect is equivalent to *note pragma SPARK_Mode: f2. and may be specified for either or both of the specification and body of a subprogram or package.  File: gnat_rm.info, Node: Aspect Suppress_Debug_Info, Next: Aspect Suppress_Initialization, Prev: Aspect SPARK_Mode, Up: Implementation Defined Aspects 3.54 Aspect Suppress_Debug_Info =============================== This boolean aspect is equivalent to *note pragma Suppress_Debug_Info: fa.  File: gnat_rm.info, Node: Aspect Suppress_Initialization, Next: Aspect Test_Case, Prev: Aspect Suppress_Debug_Info, Up: Implementation Defined Aspects 3.55 Aspect Suppress_Initialization =================================== This boolean aspect is equivalent to *note pragma Suppress_Initialization: fd.  File: gnat_rm.info, Node: Aspect Test_Case, Next: Aspect Thread_Local_Storage, Prev: Aspect Suppress_Initialization, Up: Implementation Defined Aspects 3.56 Aspect Test_Case ===================== This aspect is equivalent to *note pragma Test_Case: 101.  File: gnat_rm.info, Node: Aspect Thread_Local_Storage, Next: Aspect Universal_Aliasing, Prev: Aspect Test_Case, Up: Implementation Defined Aspects 3.57 Aspect Thread_Local_Storage ================================ This boolean aspect is equivalent to *note pragma Thread_Local_Storage: 103.  File: gnat_rm.info, Node: Aspect Universal_Aliasing, Next: Aspect Unmodified, Prev: Aspect Thread_Local_Storage, Up: Implementation Defined Aspects 3.58 Aspect Universal_Aliasing ============================== This boolean aspect is equivalent to *note pragma Universal_Aliasing: 10e.  File: gnat_rm.info, Node: Aspect Unmodified, Next: Aspect Unreferenced, Prev: Aspect Universal_Aliasing, Up: Implementation Defined Aspects 3.59 Aspect Unmodified ====================== This boolean aspect is equivalent to *note pragma Unmodified: 110.  File: gnat_rm.info, Node: Aspect Unreferenced, Next: Aspect Unreferenced_Objects, Prev: Aspect Unmodified, Up: Implementation Defined Aspects 3.60 Aspect Unreferenced ======================== This boolean aspect is equivalent to *note pragma Unreferenced: 112. When using the ‘-gnat2022’ switch, this aspect is also supported on formal parameters, which is in particular the only form possible for expression functions.  File: gnat_rm.info, Node: Aspect Unreferenced_Objects, Next: Aspect User_Aspect, Prev: Aspect Unreferenced, Up: Implementation Defined Aspects 3.61 Aspect Unreferenced_Objects ================================ This boolean aspect is equivalent to *note pragma Unreferenced_Objects: 114.  File: gnat_rm.info, Node: Aspect User_Aspect, Next: Aspect Value_Size, Prev: Aspect Unreferenced_Objects, Up: Implementation Defined Aspects 3.62 Aspect User_Aspect ======================= This aspect takes an argument that is the name of an aspect defined by a User_Aspect_Definition configuration pragma. A User_Aspect aspect specification is semantically equivalent to replicating the set of aspect specifications associated with the named pragma-defined aspect.  File: gnat_rm.info, Node: Aspect Value_Size, Next: Aspect Volatile_Full_Access, Prev: Aspect User_Aspect, Up: Implementation Defined Aspects 3.63 Aspect Value_Size ====================== This aspect is equivalent to *note attribute Value_Size: 16a.  File: gnat_rm.info, Node: Aspect Volatile_Full_Access, Next: Aspect Volatile_Function, Prev: Aspect Value_Size, Up: Implementation Defined Aspects 3.64 Aspect Volatile_Full_Access ================================ This boolean aspect is equivalent to *note pragma Volatile_Full_Access: 11e.  File: gnat_rm.info, Node: Aspect Volatile_Function, Next: Aspect Warnings, Prev: Aspect Volatile_Full_Access, Up: Implementation Defined Aspects 3.65 Aspect Volatile_Function ============================= This boolean aspect is equivalent to *note pragma Volatile_Function: 120.  File: gnat_rm.info, Node: Aspect Warnings, Prev: Aspect Volatile_Function, Up: Implementation Defined Aspects 3.66 Aspect Warnings ==================== This aspect is equivalent to the two argument form of *note pragma Warnings: 122, where the first argument is ‘ON’ or ‘OFF’ and the second argument is the entity.  File: gnat_rm.info, Node: Implementation Defined Attributes, Next: Standard and Implementation Defined Restrictions, Prev: Implementation Defined Aspects, Up: Top 4 Implementation Defined Attributes *********************************** Ada defines (throughout the Ada reference manual, summarized in Annex K), a set of attributes that provide useful additional functionality in all areas of the language. These language defined attributes are implemented in GNAT and work as described in the Ada Reference Manual. In addition, Ada allows implementations to define additional attributes whose meaning is defined by the implementation. GNAT provides a number of these implementation-dependent attributes which can be used to extend and enhance the functionality of the compiler. This section of the GNAT reference manual describes these additional attributes. It also describes additional implementation-dependent features of standard language-defined attributes. Note that any program using these attributes may not be portable to other compilers (although GNAT implements this set of attributes on all platforms). Therefore if portability to other compilers is an important consideration, you should minimize the use of these attributes. * Menu: * Attribute Abort_Signal:: * Attribute Address_Size:: * Attribute Asm_Input:: * Attribute Asm_Output:: * Attribute Atomic_Always_Lock_Free:: * Attribute Bit:: * Attribute Bit_Position:: * Attribute Code_Address:: * Attribute Compiler_Version:: * Attribute Constrained:: * Attribute Default_Bit_Order:: * Attribute Default_Scalar_Storage_Order:: * Attribute Deref:: * Attribute Descriptor_Size:: * Attribute Elaborated:: * Attribute Elab_Body:: * Attribute Elab_Spec:: * Attribute Elab_Subp_Body:: * Attribute Emax:: * Attribute Enabled:: * Attribute Enum_Rep:: * Attribute Enum_Val:: * Attribute Epsilon:: * Attribute Fast_Math:: * Attribute Finalization_Size:: * Attribute Fixed_Value:: * Attribute From_Any:: * Attribute Has_Access_Values:: * Attribute Has_Discriminants:: * Attribute Has_Tagged_Values:: * Attribute Img:: * Attribute Initialized:: * Attribute Integer_Value:: * Attribute Invalid_Value:: * Attribute Iterable:: * Attribute Large:: * Attribute Library_Level:: * Attribute Loop_Entry:: * Attribute Machine_Size:: * Attribute Mantissa:: * Attribute Maximum_Alignment:: * Attribute Max_Integer_Size:: * Attribute Mechanism_Code:: * Attribute Null_Parameter:: * Attribute Object_Size:: * Attribute Old:: * Attribute Passed_By_Reference:: * Attribute Pool_Address:: * Attribute Range_Length:: * Attribute Restriction_Set:: * Attribute Result:: * Attribute Safe_Emax:: * Attribute Safe_Large:: * Attribute Safe_Small:: * Attribute Scalar_Storage_Order:: * Attribute Simple_Storage_Pool:: * Attribute Small:: * Attribute Small_Denominator:: * Attribute Small_Numerator:: * Attribute Storage_Unit:: * Attribute Stub_Type:: * Attribute System_Allocator_Alignment:: * Attribute Target_Name:: * Attribute To_Address:: * Attribute To_Any:: * Attribute Type_Class:: * Attribute Type_Key:: * Attribute TypeCode:: * Attribute Unconstrained_Array:: * Attribute Universal_Literal_String:: * Attribute Unrestricted_Access:: * Attribute Update:: * Attribute Valid_Value:: * Attribute Valid_Scalars:: * Attribute VADS_Size:: * Attribute Value_Size:: * Attribute Wchar_T_Size:: * Attribute Word_Size::  File: gnat_rm.info, Node: Attribute Abort_Signal, Next: Attribute Address_Size, Up: Implementation Defined Attributes 4.1 Attribute Abort_Signal ========================== ‘Standard'Abort_Signal’ (‘Standard’ is the only allowed prefix) provides the entity for the special exception used to signal task abort or asynchronous transfer of control. Normally this attribute should only be used in the tasking runtime (it is highly peculiar, and completely outside the normal semantics of Ada, for a user program to intercept the abort exception).  File: gnat_rm.info, Node: Attribute Address_Size, Next: Attribute Asm_Input, Prev: Attribute Abort_Signal, Up: Implementation Defined Attributes 4.2 Attribute Address_Size ========================== ‘Standard'Address_Size’ (‘Standard’ is the only allowed prefix) is a static constant giving the number of bits in an ‘Address’. It is the same value as System.Address’Size, but has the advantage of being static, while a direct reference to System.Address’Size is nonstatic because Address is a private type.  File: gnat_rm.info, Node: Attribute Asm_Input, Next: Attribute Asm_Output, Prev: Attribute Address_Size, Up: Implementation Defined Attributes 4.3 Attribute Asm_Input ======================= The ‘Asm_Input’ attribute denotes a function that takes two parameters. The first is a string, the second is an expression of the type designated by the prefix. The first (string) argument is required to be a static expression, and is the constraint for the parameter, (e.g., what kind of register is required). The second argument is the value to be used as the input argument. The possible values for the constant are the same as those used in the RTL, and are dependent on the configuration file used to built the GCC back end. *note Machine Code Insertions: 173.  File: gnat_rm.info, Node: Attribute Asm_Output, Next: Attribute Atomic_Always_Lock_Free, Prev: Attribute Asm_Input, Up: Implementation Defined Attributes 4.4 Attribute Asm_Output ======================== The ‘Asm_Output’ attribute denotes a function that takes two parameters. The first is a string, the second is the name of a variable of the type designated by the attribute prefix. The first (string) argument is required to be a static expression and designates the constraint for the parameter (e.g., what kind of register is required). The second argument is the variable to be updated with the result. The possible values for constraint are the same as those used in the RTL, and are dependent on the configuration file used to build the GCC back end. If there are no output operands, then this argument may either be omitted, or explicitly given as ‘No_Output_Operands’. *note Machine Code Insertions: 173.  File: gnat_rm.info, Node: Attribute Atomic_Always_Lock_Free, Next: Attribute Bit, Prev: Attribute Asm_Output, Up: Implementation Defined Attributes 4.5 Attribute Atomic_Always_Lock_Free ===================================== The prefix of the ‘Atomic_Always_Lock_Free’ attribute is a type. The result is a Boolean value which is True if the type has discriminants, and False otherwise. The result indicate whether atomic operations are supported by the target for the given type.  File: gnat_rm.info, Node: Attribute Bit, Next: Attribute Bit_Position, Prev: Attribute Atomic_Always_Lock_Free, Up: Implementation Defined Attributes 4.6 Attribute Bit ================= ‘obj'Bit’, where ‘obj’ is any object, yields the bit offset within the storage unit (byte) that contains the first bit of storage allocated for the object. The value of this attribute is of the type 'universal_integer' and is always a nonnegative number smaller than ‘System.Storage_Unit’. For an object that is a variable or a constant allocated in a register, the value is zero. (The use of this attribute does not force the allocation of a variable to memory). For an object that is a formal parameter, this attribute applies to either the matching actual parameter or to a copy of the matching actual parameter. For an access object the value is zero. Note that ‘obj.all'Bit’ is subject to an ‘Access_Check’ for the designated object. Similarly for a record component ‘X.C'Bit’ is subject to a discriminant check and ‘X(I).Bit’ and ‘X(I1..I2)'Bit’ are subject to index checks. This attribute is designed to be compatible with the DEC Ada 83 definition and implementation of the ‘Bit’ attribute.  File: gnat_rm.info, Node: Attribute Bit_Position, Next: Attribute Code_Address, Prev: Attribute Bit, Up: Implementation Defined Attributes 4.7 Attribute Bit_Position ========================== ‘R.C'Bit_Position’, where ‘R’ is a record object and ‘C’ is one of the fields of the record type, yields the bit offset within the record contains the first bit of storage allocated for the object. The value of this attribute is of the type 'universal_integer'. The value depends only on the field ‘C’ and is independent of the alignment of the containing record ‘R’.  File: gnat_rm.info, Node: Attribute Code_Address, Next: Attribute Compiler_Version, Prev: Attribute Bit_Position, Up: Implementation Defined Attributes 4.8 Attribute Code_Address ========================== The ‘'Address’ attribute may be applied to subprograms in Ada 95 and Ada 2005, but the intended effect seems to be to provide an address value which can be used to call the subprogram by means of an address clause as in the following example: procedure K is ... procedure L; for L'Address use K'Address; pragma Import (Ada, L); A call to ‘L’ is then expected to result in a call to ‘K’. In Ada 83, where there were no access-to-subprogram values, this was a common work-around for getting the effect of an indirect call. GNAT implements the above use of ‘Address’ and the technique illustrated by the example code works correctly. However, for some purposes, it is useful to have the address of the start of the generated code for the subprogram. On some architectures, this is not necessarily the same as the ‘Address’ value described above. For example, the ‘Address’ value may reference a subprogram descriptor rather than the subprogram itself. The ‘'Code_Address’ attribute, which can only be applied to subprogram entities, always returns the address of the start of the generated code of the specified subprogram, which may or may not be the same value as is returned by the corresponding ‘'Address’ attribute.  File: gnat_rm.info, Node: Attribute Compiler_Version, Next: Attribute Constrained, Prev: Attribute Code_Address, Up: Implementation Defined Attributes 4.9 Attribute Compiler_Version ============================== ‘Standard'Compiler_Version’ (‘Standard’ is the only allowed prefix) yields a static string identifying the version of the compiler being used to compile the unit containing the attribute reference.  File: gnat_rm.info, Node: Attribute Constrained, Next: Attribute Default_Bit_Order, Prev: Attribute Compiler_Version, Up: Implementation Defined Attributes 4.10 Attribute Constrained ========================== In addition to the usage of this attribute in the Ada RM, GNAT also permits the use of the ‘'Constrained’ attribute in a generic template for any type, including types without discriminants. The value of this attribute in the generic instance when applied to a scalar type or a record type without discriminants is always ‘True’. This usage is compatible with older Ada compilers, including notably DEC Ada.  File: gnat_rm.info, Node: Attribute Default_Bit_Order, Next: Attribute Default_Scalar_Storage_Order, Prev: Attribute Constrained, Up: Implementation Defined Attributes 4.11 Attribute Default_Bit_Order ================================ ‘Standard'Default_Bit_Order’ (‘Standard’ is the only allowed prefix), provides the value ‘System.Default_Bit_Order’ as a ‘Pos’ value (0 for ‘High_Order_First’, 1 for ‘Low_Order_First’). This is used to construct the definition of ‘Default_Bit_Order’ in package ‘System’.  File: gnat_rm.info, Node: Attribute Default_Scalar_Storage_Order, Next: Attribute Deref, Prev: Attribute Default_Bit_Order, Up: Implementation Defined Attributes 4.12 Attribute Default_Scalar_Storage_Order =========================================== ‘Standard'Default_Scalar_Storage_Order’ (‘Standard’ is the only allowed prefix), provides the current value of the default scalar storage order (as specified using pragma ‘Default_Scalar_Storage_Order’, or equal to ‘Default_Bit_Order’ if unspecified) as a ‘System.Bit_Order’ value. This is a static attribute.  File: gnat_rm.info, Node: Attribute Deref, Next: Attribute Descriptor_Size, Prev: Attribute Default_Scalar_Storage_Order, Up: Implementation Defined Attributes 4.13 Attribute Deref ==================== The attribute ‘typ'Deref(expr)’ where ‘expr’ is of type ‘System.Address’ yields the variable of type ‘typ’ that is located at the given address. It is similar to ‘(totyp (expr).all)’, where ‘totyp’ is an unchecked conversion from address to a named access-to-‘typ’ type, except that it yields a variable, so it can be used on the left side of an assignment.  File: gnat_rm.info, Node: Attribute Descriptor_Size, Next: Attribute Elaborated, Prev: Attribute Deref, Up: Implementation Defined Attributes 4.14 Attribute Descriptor_Size ============================== Nonstatic attribute ‘Descriptor_Size’ returns the size in bits of the descriptor allocated for a type. The result is non-zero only for unconstrained array types and the returned value is of type universal integer. In GNAT, an array descriptor contains bounds information and is located immediately before the first element of the array. type Unconstr_Array is array (Short_Short_Integer range <>) of Positive; Put_Line ("Descriptor size = " & Unconstr_Array'Descriptor_Size'Img); The attribute takes into account any padding due to the alignment of the component type. In the example above, the descriptor contains two values of type ‘Short_Short_Integer’ representing the low and high bound. But, since ‘Positive’ has an alignment of 4, the size of the descriptor is ‘2 * Short_Short_Integer'Size’ rounded up to the next multiple of 32, which yields a size of 32 bits, i.e. including 16 bits of padding.  File: gnat_rm.info, Node: Attribute Elaborated, Next: Attribute Elab_Body, Prev: Attribute Descriptor_Size, Up: Implementation Defined Attributes 4.15 Attribute Elaborated ========================= The prefix of the ‘'Elaborated’ attribute must be a unit name. The value is a Boolean which indicates whether or not the given unit has been elaborated. This attribute is primarily intended for internal use by the generated code for dynamic elaboration checking, but it can also be used in user programs. The value will always be True once elaboration of all units has been completed. An exception is for units which need no elaboration, the value is always False for such units.  File: gnat_rm.info, Node: Attribute Elab_Body, Next: Attribute Elab_Spec, Prev: Attribute Elaborated, Up: Implementation Defined Attributes 4.16 Attribute Elab_Body ======================== This attribute can only be applied to a program unit name. It returns the entity for the corresponding elaboration procedure for elaborating the body of the referenced unit. This is used in the main generated elaboration procedure by the binder and is not normally used in any other context. However, there may be specialized situations in which it is useful to be able to call this elaboration procedure from Ada code, e.g., if it is necessary to do selective re-elaboration to fix some error.  File: gnat_rm.info, Node: Attribute Elab_Spec, Next: Attribute Elab_Subp_Body, Prev: Attribute Elab_Body, Up: Implementation Defined Attributes 4.17 Attribute Elab_Spec ======================== This attribute can only be applied to a program unit name. It returns the entity for the corresponding elaboration procedure for elaborating the spec of the referenced unit. This is used in the main generated elaboration procedure by the binder and is not normally used in any other context. However, there may be specialized situations in which it is useful to be able to call this elaboration procedure from Ada code, e.g., if it is necessary to do selective re-elaboration to fix some error.  File: gnat_rm.info, Node: Attribute Elab_Subp_Body, Next: Attribute Emax, Prev: Attribute Elab_Spec, Up: Implementation Defined Attributes 4.18 Attribute Elab_Subp_Body ============================= This attribute can only be applied to a library level subprogram name and is only allowed in CodePeer mode. It returns the entity for the corresponding elaboration procedure for elaborating the body of the referenced subprogram unit. This is used in the main generated elaboration procedure by the binder in CodePeer mode only and is unrecognized otherwise.  File: gnat_rm.info, Node: Attribute Emax, Next: Attribute Enabled, Prev: Attribute Elab_Subp_Body, Up: Implementation Defined Attributes 4.19 Attribute Emax =================== The ‘Emax’ attribute is provided for compatibility with Ada 83. See the Ada 83 reference manual for an exact description of the semantics of this attribute.  File: gnat_rm.info, Node: Attribute Enabled, Next: Attribute Enum_Rep, Prev: Attribute Emax, Up: Implementation Defined Attributes 4.20 Attribute Enabled ====================== The ‘Enabled’ attribute allows an application program to check at compile time to see if the designated check is currently enabled. The prefix is a simple identifier, referencing any predefined check name (other than ‘All_Checks’) or a check name introduced by pragma Check_Name. If no argument is given for the attribute, the check is for the general state of the check, if an argument is given, then it is an entity name, and the check indicates whether an ‘Suppress’ or ‘Unsuppress’ has been given naming the entity (if not, then the argument is ignored). Note that instantiations inherit the check status at the point of the instantiation, so a useful idiom is to have a library package that introduces a check name with ‘pragma Check_Name’, and then contains generic packages or subprograms which use the ‘Enabled’ attribute to see if the check is enabled. A user of this package can then issue a ‘pragma Suppress’ or ‘pragma Unsuppress’ before instantiating the package or subprogram, controlling whether the check will be present.  File: gnat_rm.info, Node: Attribute Enum_Rep, Next: Attribute Enum_Val, Prev: Attribute Enabled, Up: Implementation Defined Attributes 4.21 Attribute Enum_Rep ======================= Note that this attribute is now standard in Ada 202x and is available as an implementation defined attribute for earlier Ada versions. For every enumeration subtype ‘S’, ‘S'Enum_Rep’ denotes a function with the following spec: function S'Enum_Rep (Arg : S'Base) return ; It is also allowable to apply ‘Enum_Rep’ directly to an object of an enumeration type or to a non-overloaded enumeration literal. In this case ‘S'Enum_Rep’ is equivalent to ‘typ'Enum_Rep(S)’ where ‘typ’ is the type of the enumeration literal or object. The function returns the representation value for the given enumeration value. This will be equal to value of the ‘Pos’ attribute in the absence of an enumeration representation clause. This is a static attribute (i.e., the result is static if the argument is static). ‘S'Enum_Rep’ can also be used with integer types and objects, in which case it simply returns the integer value. The reason for this is to allow it to be used for ‘(<>)’ discrete formal arguments in a generic unit that can be instantiated with either enumeration types or integer types. Note that if ‘Enum_Rep’ is used on a modular type whose upper bound exceeds the upper bound of the largest signed integer type, and the argument is a variable, so that the universal integer calculation is done at run time, then the call to ‘Enum_Rep’ may raise ‘Constraint_Error’.  File: gnat_rm.info, Node: Attribute Enum_Val, Next: Attribute Epsilon, Prev: Attribute Enum_Rep, Up: Implementation Defined Attributes 4.22 Attribute Enum_Val ======================= Note that this attribute is now standard in Ada 202x and is available as an implementation defined attribute for earlier Ada versions. For every enumeration subtype ‘S’, ‘S'Enum_Val’ denotes a function with the following spec: function S'Enum_Val (Arg : ) return S'Base; The function returns the enumeration value whose representation matches the argument, or raises Constraint_Error if no enumeration literal of the type has the matching value. This will be equal to value of the ‘Val’ attribute in the absence of an enumeration representation clause. This is a static attribute (i.e., the result is static if the argument is static).  File: gnat_rm.info, Node: Attribute Epsilon, Next: Attribute Fast_Math, Prev: Attribute Enum_Val, Up: Implementation Defined Attributes 4.23 Attribute Epsilon ====================== The ‘Epsilon’ attribute is provided for compatibility with Ada 83. See the Ada 83 reference manual for an exact description of the semantics of this attribute.  File: gnat_rm.info, Node: Attribute Fast_Math, Next: Attribute Finalization_Size, Prev: Attribute Epsilon, Up: Implementation Defined Attributes 4.24 Attribute Fast_Math ======================== ‘Standard'Fast_Math’ (‘Standard’ is the only allowed prefix) yields a static Boolean value that is True if pragma ‘Fast_Math’ is active, and False otherwise.  File: gnat_rm.info, Node: Attribute Finalization_Size, Next: Attribute Fixed_Value, Prev: Attribute Fast_Math, Up: Implementation Defined Attributes 4.25 Attribute Finalization_Size ================================ The prefix of attribute ‘Finalization_Size’ must be an object or a non-class-wide type. This attribute returns the size of any hidden data reserved by the compiler to handle finalization-related actions. The type of the attribute is 'universal_integer'. ‘Finalization_Size’ yields a value of zero for a type with no controlled parts, an object whose type has no controlled parts, or an object of a class-wide type whose tag denotes a type with no controlled parts. Note that only heap-allocated objects contain finalization data.  File: gnat_rm.info, Node: Attribute Fixed_Value, Next: Attribute From_Any, Prev: Attribute Finalization_Size, Up: Implementation Defined Attributes 4.26 Attribute Fixed_Value ========================== For every fixed-point type ‘S’, ‘S'Fixed_Value’ denotes a function with the following specification: function S'Fixed_Value (Arg : ) return S; The value returned is the fixed-point value ‘V’ such that: V = Arg * S'Small The effect is thus similar to first converting the argument to the integer type used to represent ‘S’, and then doing an unchecked conversion to the fixed-point type. The difference is that there are full range checks, to ensure that the result is in range. This attribute is primarily intended for use in implementation of the input-output functions for fixed-point values.  File: gnat_rm.info, Node: Attribute From_Any, Next: Attribute Has_Access_Values, Prev: Attribute Fixed_Value, Up: Implementation Defined Attributes 4.27 Attribute From_Any ======================= This internal attribute is used for the generation of remote subprogram stubs in the context of the Distributed Systems Annex.  File: gnat_rm.info, Node: Attribute Has_Access_Values, Next: Attribute Has_Discriminants, Prev: Attribute From_Any, Up: Implementation Defined Attributes 4.28 Attribute Has_Access_Values ================================ The prefix of the ‘Has_Access_Values’ attribute is a type. The result is a Boolean value which is True if the is an access type, or is a composite type with a component (at any nesting depth) that is an access type, and is False otherwise. The intended use of this attribute is in conjunction with generic definitions. If the attribute is applied to a generic private type, it indicates whether or not the corresponding actual type has access values.  File: gnat_rm.info, Node: Attribute Has_Discriminants, Next: Attribute Has_Tagged_Values, Prev: Attribute Has_Access_Values, Up: Implementation Defined Attributes 4.29 Attribute Has_Discriminants ================================ The prefix of the ‘Has_Discriminants’ attribute is a type. The result is a Boolean value which is True if the type has discriminants, and False otherwise. The intended use of this attribute is in conjunction with generic definitions. If the attribute is applied to a generic private type, it indicates whether or not the corresponding actual type has discriminants.  File: gnat_rm.info, Node: Attribute Has_Tagged_Values, Next: Attribute Img, Prev: Attribute Has_Discriminants, Up: Implementation Defined Attributes 4.30 Attribute Has_Tagged_Values ================================ The prefix of the ‘Has_Tagged_Values’ attribute is a type. The result is a Boolean value which is True if the type is a composite type (array or record) that is either a tagged type or has a subcomponent that is tagged, and is False otherwise. The intended use of this attribute is in conjunction with generic definitions. If the attribute is applied to a generic private type, it indicates whether or not the corresponding actual type has access values.  File: gnat_rm.info, Node: Attribute Img, Next: Attribute Initialized, Prev: Attribute Has_Tagged_Values, Up: Implementation Defined Attributes 4.31 Attribute Img ================== The ‘Img’ attribute differs from ‘Image’ in that, while both can be applied directly to an object, ‘Img’ cannot be applied to types. Example usage of the attribute: Put_Line ("X = " & X'Img); which has the same meaning as the more verbose: Put_Line ("X = " & T'Image (X)); where ‘T’ is the (sub)type of the object ‘X’. Note that technically, in analogy to ‘Image’, ‘X'Img’ returns a parameterless function that returns the appropriate string when called. This means that ‘X'Img’ can be renamed as a function-returning-string, or used in an instantiation as a function parameter.  File: gnat_rm.info, Node: Attribute Initialized, Next: Attribute Integer_Value, Prev: Attribute Img, Up: Implementation Defined Attributes 4.32 Attribute Initialized ========================== For the syntax and semantics of this attribute, see the SPARK 2014 Reference Manual, section 6.10.  File: gnat_rm.info, Node: Attribute Integer_Value, Next: Attribute Invalid_Value, Prev: Attribute Initialized, Up: Implementation Defined Attributes 4.33 Attribute Integer_Value ============================ For every integer type ‘S’, ‘S'Integer_Value’ denotes a function with the following spec: function S'Integer_Value (Arg : ) return S; The value returned is the integer value ‘V’, such that: Arg = V * T'Small where ‘T’ is the type of ‘Arg’. The effect is thus similar to first doing an unchecked conversion from the fixed-point type to its corresponding implementation type, and then converting the result to the target integer type. The difference is that there are full range checks, to ensure that the result is in range. This attribute is primarily intended for use in implementation of the standard input-output functions for fixed-point values.  File: gnat_rm.info, Node: Attribute Invalid_Value, Next: Attribute Iterable, Prev: Attribute Integer_Value, Up: Implementation Defined Attributes 4.34 Attribute Invalid_Value ============================ For every scalar type S, S’Invalid_Value returns an undefined value of the type. If possible this value is an invalid representation for the type. The value returned is identical to the value used to initialize an otherwise uninitialized value of the type if pragma Initialize_Scalars is used, including the ability to modify the value with the binder -Sxx flag and relevant environment variables at run time.  File: gnat_rm.info, Node: Attribute Iterable, Next: Attribute Large, Prev: Attribute Invalid_Value, Up: Implementation Defined Attributes 4.35 Attribute Iterable ======================= Equivalent to Aspect Iterable.  File: gnat_rm.info, Node: Attribute Large, Next: Attribute Library_Level, Prev: Attribute Iterable, Up: Implementation Defined Attributes 4.36 Attribute Large ==================== The ‘Large’ attribute is provided for compatibility with Ada 83. See the Ada 83 reference manual for an exact description of the semantics of this attribute.  File: gnat_rm.info, Node: Attribute Library_Level, Next: Attribute Loop_Entry, Prev: Attribute Large, Up: Implementation Defined Attributes 4.37 Attribute Library_Level ============================ ‘P'Library_Level’, where P is an entity name, returns a Boolean value which is True if the entity is declared at the library level, and False otherwise. Note that within a generic instantiation, the name of the generic unit denotes the instance, which means that this attribute can be used to test if a generic is instantiated at the library level, as shown in this example: generic ... package Gen is pragma Compile_Time_Error (not Gen'Library_Level, "Gen can only be instantiated at library level"); ... end Gen;  File: gnat_rm.info, Node: Attribute Loop_Entry, Next: Attribute Machine_Size, Prev: Attribute Library_Level, Up: Implementation Defined Attributes 4.38 Attribute Loop_Entry ========================= Syntax: X'Loop_Entry [(loop_name)] The ‘Loop_Entry’ attribute is used to refer to the value that an expression had upon entry to a given loop in much the same way that the ‘Old’ attribute in a subprogram postcondition can be used to refer to the value an expression had upon entry to the subprogram. The relevant loop is either identified by the given loop name, or it is the innermost enclosing loop when no loop name is given. A ‘Loop_Entry’ attribute can only occur within an ‘Assert’, ‘Assert_And_Cut’, ‘Assume’, ‘Loop_Variant’ or ‘Loop_Invariant’ pragma. In addition, such a pragma must be one of the items in the sequence of statements of a loop body, or nested inside block statements that appear in the sequence of statements of a loop body. A common use of ‘Loop_Entry’ is to compare the current value of objects with their initial value at loop entry, in a ‘Loop_Invariant’ pragma. The effect of using ‘X'Loop_Entry’ is the same as declaring a constant initialized with the initial value of ‘X’ at loop entry. This copy is not performed if the loop is not entered, or if the corresponding pragmas are ignored or disabled.  File: gnat_rm.info, Node: Attribute Machine_Size, Next: Attribute Mantissa, Prev: Attribute Loop_Entry, Up: Implementation Defined Attributes 4.39 Attribute Machine_Size =========================== This attribute is identical to the ‘Object_Size’ attribute. It is provided for compatibility with the DEC Ada 83 attribute of this name.  File: gnat_rm.info, Node: Attribute Mantissa, Next: Attribute Maximum_Alignment, Prev: Attribute Machine_Size, Up: Implementation Defined Attributes 4.40 Attribute Mantissa ======================= The ‘Mantissa’ attribute is provided for compatibility with Ada 83. See the Ada 83 reference manual for an exact description of the semantics of this attribute.  File: gnat_rm.info, Node: Attribute Maximum_Alignment, Next: Attribute Max_Integer_Size, Prev: Attribute Mantissa, Up: Implementation Defined Attributes 4.41 Attribute Maximum_Alignment ================================ ‘Standard'Maximum_Alignment’ (‘Standard’ is the only allowed prefix) provides the maximum useful alignment value for the target. This is a static value that can be used to specify the alignment for an object, guaranteeing that it is properly aligned in all cases.  File: gnat_rm.info, Node: Attribute Max_Integer_Size, Next: Attribute Mechanism_Code, Prev: Attribute Maximum_Alignment, Up: Implementation Defined Attributes 4.42 Attribute Max_Integer_Size =============================== ‘Standard'Max_Integer_Size’ (‘Standard’ is the only allowed prefix) provides the size of the largest supported integer type for the target. The result is a static constant.  File: gnat_rm.info, Node: Attribute Mechanism_Code, Next: Attribute Null_Parameter, Prev: Attribute Max_Integer_Size, Up: Implementation Defined Attributes 4.43 Attribute Mechanism_Code ============================= ‘func'Mechanism_Code’ yields an integer code for the mechanism used for the result of function ‘func’, and ‘subprog'Mechanism_Code (n)’ yields the mechanism used for formal parameter number 'n' (a static integer value, with 1 meaning the first parameter) of subprogram ‘subprog’. The code returned is: '1' by copy (value) '2' by reference  File: gnat_rm.info, Node: Attribute Null_Parameter, Next: Attribute Object_Size, Prev: Attribute Mechanism_Code, Up: Implementation Defined Attributes 4.44 Attribute Null_Parameter ============================= A reference ‘T'Null_Parameter’ denotes an imaginary object of type or subtype ‘T’ allocated at machine address zero. The attribute is allowed only as the default expression of a formal parameter, or as an actual expression of a subprogram call. In either case, the subprogram must be imported. The identity of the object is represented by the address zero in the argument list, independent of the passing mechanism (explicit or default). This capability is needed to specify that a zero address should be passed for a record or other composite object passed by reference. There is no way of indicating this without the ‘Null_Parameter’ attribute.  File: gnat_rm.info, Node: Attribute Object_Size, Next: Attribute Old, Prev: Attribute Null_Parameter, Up: Implementation Defined Attributes 4.45 Attribute Object_Size ========================== The size of an object is not necessarily the same as the size of the type of an object. This is because by default object sizes are increased to be a multiple of the alignment of the object. For example, ‘Natural'Size’ is 31, but by default objects of type ‘Natural’ will have a size of 32 bits. Similarly, a record containing an integer and a character: type Rec is record I : Integer; C : Character; end record; will have a size of 40 (that is ‘Rec'Size’ will be 40). The alignment will be 4, because of the integer field, and so the default size of record objects for this type will be 64 (8 bytes). If the alignment of the above record is specified to be 1, then the object size will be 40 (5 bytes). This is true by default, and also an object size of 40 can be explicitly specified in this case. A consequence of this capability is that different object sizes can be given to subtypes that would otherwise be considered in Ada to be statically matching. But it makes no sense to consider such subtypes as statically matching. Consequently, GNAT adds a rule to the static matching rules that requires object sizes to match. Consider this example: 1. procedure BadAVConvert is 2. type R is new Integer; 3. subtype R1 is R range 1 .. 10; 4. subtype R2 is R range 1 .. 10; 5. for R1'Object_Size use 8; 6. for R2'Object_Size use 16; 7. type R1P is access all R1; 8. type R2P is access all R2; 9. R1PV : R1P := new R1'(4); 10. R2PV : R2P; 11. begin 12. R2PV := R2P (R1PV); | >>> target designated subtype not compatible with type "R1" defined at line 3 13. end; In the absence of lines 5 and 6, types ‘R1’ and ‘R2’ statically match and hence the conversion on line 12 is legal. But since lines 5 and 6 cause the object sizes to differ, GNAT considers that types ‘R1’ and ‘R2’ are not statically matching, and line 12 generates the diagnostic shown above. Similar additional checks are performed in other contexts requiring statically matching subtypes.  File: gnat_rm.info, Node: Attribute Old, Next: Attribute Passed_By_Reference, Prev: Attribute Object_Size, Up: Implementation Defined Attributes 4.46 Attribute Old ================== In addition to the usage of ‘Old’ defined in the Ada 2012 RM (usage within ‘Post’ aspect), GNAT also permits the use of this attribute in implementation defined pragmas ‘Postcondition’, ‘Contract_Cases’ and ‘Test_Case’. Also usages of ‘Old’ which would be illegal according to the Ada 2012 RM definition are allowed under control of implementation defined pragma ‘Unevaluated_Use_Of_Old’.  File: gnat_rm.info, Node: Attribute Passed_By_Reference, Next: Attribute Pool_Address, Prev: Attribute Old, Up: Implementation Defined Attributes 4.47 Attribute Passed_By_Reference ================================== ‘typ'Passed_By_Reference’ for any subtype ‘typ’ returns a value of type ‘Boolean’ value that is ‘True’ if the type is normally passed by reference and ‘False’ if the type is normally passed by copy in calls. For scalar types, the result is always ‘False’ and is static. For non-scalar types, the result is nonstatic.  File: gnat_rm.info, Node: Attribute Pool_Address, Next: Attribute Range_Length, Prev: Attribute Passed_By_Reference, Up: Implementation Defined Attributes 4.48 Attribute Pool_Address =========================== ‘X'Pool_Address’ for any object ‘X’ returns the address of X within its storage pool. This is the same as ‘X'Address’, except that for an unconstrained array whose bounds are allocated just before the first component, ‘X'Pool_Address’ returns the address of those bounds, whereas ‘X'Address’ returns the address of the first component. Here, we are interpreting ‘storage pool’ broadly to mean ‘wherever the object is allocated’, which could be a user-defined storage pool, the global heap, on the stack, or in a static memory area. For an object created by ‘new’, ‘Ptr.all'Pool_Address’ is what is passed to ‘Allocate’ and returned from ‘Deallocate’.  File: gnat_rm.info, Node: Attribute Range_Length, Next: Attribute Restriction_Set, Prev: Attribute Pool_Address, Up: Implementation Defined Attributes 4.49 Attribute Range_Length =========================== ‘typ'Range_Length’ for any discrete type ‘typ’ yields the number of values represented by the subtype (zero for a null range). The result is static for static subtypes. ‘Range_Length’ applied to the index subtype of a one dimensional array always gives the same result as ‘Length’ applied to the array itself.  File: gnat_rm.info, Node: Attribute Restriction_Set, Next: Attribute Result, Prev: Attribute Range_Length, Up: Implementation Defined Attributes 4.50 Attribute Restriction_Set ============================== This attribute allows compile time testing of restrictions that are currently in effect. It is primarily intended for specializing code in the run-time based on restrictions that are active (e.g. don’t need to save fpt registers if restriction No_Floating_Point is known to be in effect), but can be used anywhere. There are two forms: System'Restriction_Set (partition_boolean_restriction_NAME) System'Restriction_Set (No_Dependence => library_unit_NAME); In the case of the first form, the only restriction names allowed are parameterless restrictions that are checked for consistency at bind time. For a complete list see the subtype ‘System.Rident.Partition_Boolean_Restrictions’. The result returned is True if the restriction is known to be in effect, and False if the restriction is known not to be in effect. An important guarantee is that the value of a Restriction_Set attribute is known to be consistent throughout all the code of a partition. This is trivially achieved if the entire partition is compiled with a consistent set of restriction pragmas. However, the compilation model does not require this. It is possible to compile one set of units with one set of pragmas, and another set of units with another set of pragmas. It is even possible to compile a spec with one set of pragmas, and then WITH the same spec with a different set of pragmas. Inconsistencies in the actual use of the restriction are checked at bind time. In order to achieve the guarantee of consistency for the Restriction_Set pragma, we consider that a use of the pragma that yields False is equivalent to a violation of the restriction. So for example if you write if System'Restriction_Set (No_Floating_Point) then ... else ... end if; And the result is False, so that the else branch is executed, you can assume that this restriction is not set for any unit in the partition. This is checked by considering this use of the restriction pragma to be a violation of the restriction No_Floating_Point. This means that no other unit can attempt to set this restriction (if some unit does attempt to set it, the binder will refuse to bind the partition). Technical note: The restriction name and the unit name are intepreted entirely syntactically, as in the corresponding Restrictions pragma, they are not analyzed semantically, so they do not have a type.  File: gnat_rm.info, Node: Attribute Result, Next: Attribute Safe_Emax, Prev: Attribute Restriction_Set, Up: Implementation Defined Attributes 4.51 Attribute Result ===================== ‘function'Result’ can only be used with in a Postcondition pragma for a function. The prefix must be the name of the corresponding function. This is used to refer to the result of the function in the postcondition expression. For a further discussion of the use of this attribute and examples of its use, see the description of pragma Postcondition.  File: gnat_rm.info, Node: Attribute Safe_Emax, Next: Attribute Safe_Large, Prev: Attribute Result, Up: Implementation Defined Attributes 4.52 Attribute Safe_Emax ======================== The ‘Safe_Emax’ attribute is provided for compatibility with Ada 83. See the Ada 83 reference manual for an exact description of the semantics of this attribute.  File: gnat_rm.info, Node: Attribute Safe_Large, Next: Attribute Safe_Small, Prev: Attribute Safe_Emax, Up: Implementation Defined Attributes 4.53 Attribute Safe_Large ========================= The ‘Safe_Large’ attribute is provided for compatibility with Ada 83. See the Ada 83 reference manual for an exact description of the semantics of this attribute.  File: gnat_rm.info, Node: Attribute Safe_Small, Next: Attribute Scalar_Storage_Order, Prev: Attribute Safe_Large, Up: Implementation Defined Attributes 4.54 Attribute Safe_Small ========================= The ‘Safe_Small’ attribute is provided for compatibility with Ada 83. See the Ada 83 reference manual for an exact description of the semantics of this attribute.  File: gnat_rm.info, Node: Attribute Scalar_Storage_Order, Next: Attribute Simple_Storage_Pool, Prev: Attribute Safe_Small, Up: Implementation Defined Attributes 4.55 Attribute Scalar_Storage_Order =================================== For every array or record type ‘S’, the representation attribute ‘Scalar_Storage_Order’ denotes the order in which storage elements that make up scalar components are ordered within S. The value given must be a static expression of type System.Bit_Order. The following is an example of the use of this feature: -- Component type definitions subtype Yr_Type is Natural range 0 .. 127; subtype Mo_Type is Natural range 1 .. 12; subtype Da_Type is Natural range 1 .. 31; -- Record declaration type Date is record Years_Since_1980 : Yr_Type; Month : Mo_Type; Day_Of_Month : Da_Type; end record; -- Record representation clause for Date use record Years_Since_1980 at 0 range 0 .. 6; Month at 0 range 7 .. 10; Day_Of_Month at 0 range 11 .. 15; end record; -- Attribute definition clauses for Date'Bit_Order use System.High_Order_First; for Date'Scalar_Storage_Order use System.High_Order_First; -- If Scalar_Storage_Order is specified, it must be consistent with -- Bit_Order, so it's best to always define the latter explicitly if -- the former is used. Other properties are as for the standard representation attribute ‘Bit_Order’ defined by Ada RM 13.5.3(4). The default is ‘System.Default_Bit_Order’. For a record type ‘T’, if ‘T'Scalar_Storage_Order’ is specified explicitly, it shall be equal to ‘T'Bit_Order’. Note: this means that if a ‘Scalar_Storage_Order’ attribute definition clause is not confirming, then the type’s ‘Bit_Order’ shall be specified explicitly and set to the same value. Derived types inherit an explicitly set scalar storage order from their parent types. This may be overridden for the derived type by giving an explicit scalar storage order for it. However, for a record extension, the derived type must have the same scalar storage order as the parent type. A component of a record type that is itself a record or an array and that does not start and end on a byte boundary must have have the same scalar storage order as the record type. A component of a bit-packed array type that is itself a record or an array must have the same scalar storage order as the array type. No component of a type that has an explicit ‘Scalar_Storage_Order’ attribute definition may be aliased. A confirming ‘Scalar_Storage_Order’ attribute definition clause (i.e. with a value equal to ‘System.Default_Bit_Order’) has no effect. If the opposite storage order is specified, then whenever the value of a scalar component of an object of type ‘S’ is read, the storage elements of the enclosing machine scalar are first reversed (before retrieving the component value, possibly applying some shift and mask operatings on the enclosing machine scalar), and the opposite operation is done for writes. In that case, the restrictions set forth in 13.5.1(10.3/2) for scalar components are relaxed. Instead, the following rules apply: * the underlying storage elements are those at positions ‘(position + first_bit / storage_element_size) .. (position + (last_bit + storage_element_size - 1) / storage_element_size)’ * the sequence of underlying storage elements shall have a size no greater than the largest machine scalar * the enclosing machine scalar is defined as the smallest machine scalar starting at a position no greater than ‘position + first_bit / storage_element_size’ and covering storage elements at least up to ‘position + (last_bit + storage_element_size - 1) / storage_element_size’ * the position of the component is interpreted relative to that machine scalar. If no scalar storage order is specified for a type (either directly, or by inheritance in the case of a derived type), then the default is normally the native ordering of the target, but this default can be overridden using pragma ‘Default_Scalar_Storage_Order’. If a component of ‘T’ is itself of a record or array type, the specfied ‘Scalar_Storage_Order’ does 'not' apply to that nested type: an explicit attribute definition clause must be provided for the component type as well if desired. Representation changes that explicitly or implicitly toggle the scalar storage order are not supported and may result in erroneous execution of the program, except when performed by means of an instance of ‘Ada.Unchecked_Conversion’. In particular, overlays are not supported and a warning is given for them: type Rec_LE is record I : Integer; end record; for Rec_LE use record I at 0 range 0 .. 31; end record; for Rec_LE'Bit_Order use System.Low_Order_First; for Rec_LE'Scalar_Storage_Order use System.Low_Order_First; type Rec_BE is record I : Integer; end record; for Rec_BE use record I at 0 range 0 .. 31; end record; for Rec_BE'Bit_Order use System.High_Order_First; for Rec_BE'Scalar_Storage_Order use System.High_Order_First; R_LE : Rec_LE; R_BE : Rec_BE; for R_BE'Address use R_LE'Address; ‘warning: overlay changes scalar storage order [enabled by default]’ In most cases, such representation changes ought to be replaced by an instantiation of a function or procedure provided by ‘GNAT.Byte_Swapping’. Note that the scalar storage order only affects the in-memory data representation. It has no effect on the representation used by stream attributes. Note that debuggers may be unable to display the correct value of scalar components of a type for which the opposite storage order is specified.  File: gnat_rm.info, Node: Attribute Simple_Storage_Pool, Next: Attribute Small, Prev: Attribute Scalar_Storage_Order, Up: Implementation Defined Attributes 4.56 Attribute Simple_Storage_Pool ================================== For every nonformal, nonderived access-to-object type ‘Acc’, the representation attribute ‘Simple_Storage_Pool’ may be specified via an attribute_definition_clause (or by specifying the equivalent aspect): My_Pool : My_Simple_Storage_Pool_Type; type Acc is access My_Data_Type; for Acc'Simple_Storage_Pool use My_Pool; The name given in an attribute_definition_clause for the ‘Simple_Storage_Pool’ attribute shall denote a variable of a ‘simple storage pool type’ (see pragma ‘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 ‘Storage_Pool’ and ‘Simple_Storage_Pool’ for the same access type. If the ‘Simple_Storage_Pool’ attribute has been specified for an access type, then applying the ‘Storage_Pool’ attribute to the type is flagged with a warning and its evaluation raises the exception ‘Program_Error’. If the Simple_Storage_Pool attribute has been specified for an access type ‘S’, then the evaluation of the attribute ‘S'Storage_Size’ returns the result of calling ‘Storage_Size (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 ‘S’ has a specified simple storage pool of type ‘SSP’, then the evaluation of an allocator for that access type calls the primitive ‘Allocate’ procedure for type ‘SSP’, passing ‘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 ‘S’ has a specified simple storage pool of type ‘SSP’, then a call to an instance of the ‘Ada.Unchecked_Deallocation’ for that access type invokes the primitive ‘Deallocate’ procedure for type ‘SSP’, passing ‘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'.  File: gnat_rm.info, Node: Attribute Small, Next: Attribute Small_Denominator, Prev: Attribute Simple_Storage_Pool, Up: Implementation Defined Attributes 4.57 Attribute Small ==================== The ‘Small’ attribute is defined in Ada 95 (and Ada 2005) only for fixed-point types. GNAT also allows this attribute to be applied to floating-point types for compatibility with Ada 83. See the Ada 83 reference manual for an exact description of the semantics of this attribute when applied to floating-point types.  File: gnat_rm.info, Node: Attribute Small_Denominator, Next: Attribute Small_Numerator, Prev: Attribute Small, Up: Implementation Defined Attributes 4.58 Attribute Small_Denominator ================================ ‘typ'Small_Denominator’ for any fixed-point subtype ‘typ’ yields the denominator in the representation of ‘typ'Small’ as a rational number with coprime factors (i.e. as an irreducible fraction).  File: gnat_rm.info, Node: Attribute Small_Numerator, Next: Attribute Storage_Unit, Prev: Attribute Small_Denominator, Up: Implementation Defined Attributes 4.59 Attribute Small_Numerator ============================== ‘typ'Small_Numerator’ for any fixed-point subtype ‘typ’ yields the numerator in the representation of ‘typ'Small’ as a rational number with coprime factors (i.e. as an irreducible fraction).  File: gnat_rm.info, Node: Attribute Storage_Unit, Next: Attribute Stub_Type, Prev: Attribute Small_Numerator, Up: Implementation Defined Attributes 4.60 Attribute Storage_Unit =========================== ‘Standard'Storage_Unit’ (‘Standard’ is the only allowed prefix) provides the same value as ‘System.Storage_Unit’.  File: gnat_rm.info, Node: Attribute Stub_Type, Next: Attribute System_Allocator_Alignment, Prev: Attribute Storage_Unit, Up: Implementation Defined Attributes 4.61 Attribute Stub_Type ======================== The GNAT implementation of remote access-to-classwide types is organized as described in AARM section E.4 (20.t): a value of an RACW type (designating a remote object) is represented as a normal access value, pointing to a “stub” object which in turn contains the necessary information to contact the designated remote object. A call on any dispatching operation of such a stub object does the remote call, if necessary, using the information in the stub object to locate the target partition, etc. For a prefix ‘T’ that denotes a remote access-to-classwide type, ‘T'Stub_Type’ denotes the type of the corresponding stub objects. By construction, the layout of ‘T'Stub_Type’ is identical to that of type ‘RACW_Stub_Type’ declared in the internal implementation-defined unit ‘System.Partition_Interface’. Use of this attribute will create an implicit dependency on this unit.  File: gnat_rm.info, Node: Attribute System_Allocator_Alignment, Next: Attribute Target_Name, Prev: Attribute Stub_Type, Up: Implementation Defined Attributes 4.62 Attribute System_Allocator_Alignment ========================================= ‘Standard'System_Allocator_Alignment’ (‘Standard’ is the only allowed prefix) provides the observable guaranteed to be honored by the system allocator (malloc). This is a static value that can be used in user storage pools based on malloc either to reject allocation with alignment too large or to enable a realignment circuitry if the alignment request is larger than this value.  File: gnat_rm.info, Node: Attribute Target_Name, Next: Attribute To_Address, Prev: Attribute System_Allocator_Alignment, Up: Implementation Defined Attributes 4.63 Attribute Target_Name ========================== ‘Standard'Target_Name’ (‘Standard’ is the only allowed prefix) provides a static string value that identifies the target for the current compilation. For GCC implementations, this is the standard gcc target name without the terminating slash (for example, GNAT 5.0 on windows yields “i586-pc-mingw32msv”).  File: gnat_rm.info, Node: Attribute To_Address, Next: Attribute To_Any, Prev: Attribute Target_Name, Up: Implementation Defined Attributes 4.64 Attribute To_Address ========================= The ‘System'To_Address’ (‘System’ is the only allowed prefix) denotes a function identical to ‘System.Storage_Elements.To_Address’ except that it is a static attribute. This means that if its argument is a static expression, then the result of the attribute is a static expression. This means that such an expression can be used in contexts (e.g., preelaborable packages) which require a static expression and where the function call could not be used (since the function call is always nonstatic, even if its argument is static). The argument must be in the range -(2**(m-1)) .. 2**m-1, where m is the memory size (typically 32 or 64). Negative values are intepreted in a modular manner (e.g., -1 means the same as 16#FFFF_FFFF# on a 32 bits machine).  File: gnat_rm.info, Node: Attribute To_Any, Next: Attribute Type_Class, Prev: Attribute To_Address, Up: Implementation Defined Attributes 4.65 Attribute To_Any ===================== This internal attribute is used for the generation of remote subprogram stubs in the context of the Distributed Systems Annex.  File: gnat_rm.info, Node: Attribute Type_Class, Next: Attribute Type_Key, Prev: Attribute To_Any, Up: Implementation Defined Attributes 4.66 Attribute Type_Class ========================= ‘typ'Type_Class’ for any type or subtype ‘typ’ yields the value of the type class for the full type of ‘typ’. If ‘typ’ is a generic formal type, the value is the value for the corresponding actual subtype. The value of this attribute is of type ‘System.Aux_DEC.Type_Class’, which has the following definition: type Type_Class is (Type_Class_Enumeration, Type_Class_Integer, Type_Class_Fixed_Point, Type_Class_Floating_Point, Type_Class_Array, Type_Class_Record, Type_Class_Access, Type_Class_Task, Type_Class_Address); Protected types yield the value ‘Type_Class_Task’, which thus applies to all concurrent types. This attribute is designed to be compatible with the DEC Ada 83 attribute of the same name.  File: gnat_rm.info, Node: Attribute Type_Key, Next: Attribute TypeCode, Prev: Attribute Type_Class, Up: Implementation Defined Attributes 4.67 Attribute Type_Key ======================= The ‘Type_Key’ attribute is applicable to a type or subtype and yields a value of type Standard.String containing encoded information about the type or subtype. This provides improved compatibility with other implementations that support this attribute.  File: gnat_rm.info, Node: Attribute TypeCode, Next: Attribute Unconstrained_Array, Prev: Attribute Type_Key, Up: Implementation Defined Attributes 4.68 Attribute TypeCode ======================= This internal attribute is used for the generation of remote subprogram stubs in the context of the Distributed Systems Annex.  File: gnat_rm.info, Node: Attribute Unconstrained_Array, Next: Attribute Universal_Literal_String, Prev: Attribute TypeCode, Up: Implementation Defined Attributes 4.69 Attribute Unconstrained_Array ================================== The ‘Unconstrained_Array’ attribute can be used with a prefix that denotes any type or subtype. It is a static attribute that yields ‘True’ if the prefix designates an unconstrained array, and ‘False’ otherwise. In a generic instance, the result is still static, and yields the result of applying this test to the generic actual.  File: gnat_rm.info, Node: Attribute Universal_Literal_String, Next: Attribute Unrestricted_Access, Prev: Attribute Unconstrained_Array, Up: Implementation Defined Attributes 4.70 Attribute Universal_Literal_String ======================================= The prefix of ‘Universal_Literal_String’ must be a named number. The static result is the string consisting of the characters of the number as defined in the original source. This allows the user program to access the actual text of named numbers without intermediate conversions and without the need to enclose the strings in quotes (which would preclude their use as numbers). For example, the following program prints the first 50 digits of pi: with Text_IO; use Text_IO; with Ada.Numerics; procedure Pi is begin Put (Ada.Numerics.Pi'Universal_Literal_String); end;  File: gnat_rm.info, Node: Attribute Unrestricted_Access, Next: Attribute Update, Prev: Attribute Universal_Literal_String, Up: Implementation Defined Attributes 4.71 Attribute Unrestricted_Access ================================== The ‘Unrestricted_Access’ attribute is similar to ‘Access’ except that all accessibility and aliased view checks are omitted. This is a user-beware attribute. For objects, it is similar to ‘Address’, for which it is a desirable replacement where the value desired is an access type. In other words, its effect is similar to first applying the ‘Address’ attribute and then doing an unchecked conversion to a desired access type. For subprograms, ‘P'Unrestricted_Access’ may be used where ‘P'Access’ would be illegal, to construct a value of a less-nested named access type that designates a more-nested subprogram. This value may be used in indirect calls, so long as the more-nested subprogram still exists; once the subprogram containing it has returned, such calls are erroneous. For example: package body P is type Less_Nested is not null access procedure; Global : Less_Nested; procedure P1 is begin Global.all; end P1; procedure P2 is Local_Var : Integer; procedure More_Nested is begin ... Local_Var ... end More_Nested; begin Global := More_Nested'Unrestricted_Access; P1; end P2; end P; When P1 is called from P2, the call via Global is OK, but if P1 were called after P2 returns, it would be an erroneous use of a dangling pointer. For objects, it is possible to use ‘Unrestricted_Access’ for any type. However, if the result is of an access-to-unconstrained array subtype, then the resulting pointer has the same scope as the context of the attribute, and must not be returned to some enclosing scope. For instance, if a function uses ‘Unrestricted_Access’ to create an access-to-unconstrained-array and returns that value to the caller, the result will involve dangling pointers. In addition, it is only valid to create pointers to unconstrained arrays using this attribute if the pointer has the normal default ‘fat’ representation where a pointer has two components, one points to the array and one points to the bounds. If a size clause is used to force ‘thin’ representation for a pointer to unconstrained where there is only space for a single pointer, then the resulting pointer is not usable. In the simple case where a direct use of Unrestricted_Access attempts to make a thin pointer for a non-aliased object, the compiler will reject the use as illegal, as shown in the following example: with System; use System; procedure SliceUA2 is type A is access all String; for A'Size use Standard'Address_Size; procedure P (Arg : A) is begin null; end P; X : String := "hello world!"; X2 : aliased String := "hello world!"; AV : A := X'Unrestricted_Access; -- ERROR | >>> illegal use of Unrestricted_Access attribute >>> attempt to generate thin pointer to unaliased object begin P (X'Unrestricted_Access); -- ERROR | >>> illegal use of Unrestricted_Access attribute >>> attempt to generate thin pointer to unaliased object P (X(7 .. 12)'Unrestricted_Access); -- ERROR | >>> illegal use of Unrestricted_Access attribute >>> attempt to generate thin pointer to unaliased object P (X2'Unrestricted_Access); -- OK end; but other cases cannot be detected by the compiler, and are considered to be erroneous. Consider the following example: with System; use System; with System; use System; procedure SliceUA is type AF is access all String; type A is access all String; for A'Size use Standard'Address_Size; procedure P (Arg : A) is begin if Arg'Length /= 6 then raise Program_Error; end if; end P; X : String := "hello world!"; Y : AF := X (7 .. 12)'Unrestricted_Access; begin P (A (Y)); end; A normal unconstrained array value or a constrained array object marked as aliased has the bounds in memory just before the array, so a thin pointer can retrieve both the data and the bounds. But in this case, the non-aliased object ‘X’ does not have the bounds before the string. If the size clause for type ‘A’ were not present, then the pointer would be a fat pointer, where one component is a pointer to the bounds, and all would be well. But with the size clause present, the conversion from fat pointer to thin pointer in the call loses the bounds, and so this is erroneous, and the program likely raises a ‘Program_Error’ exception. In general, it is advisable to completely avoid mixing the use of thin pointers and the use of ‘Unrestricted_Access’ where the designated type is an unconstrained array. The use of thin pointers should be restricted to cases of porting legacy code that implicitly assumes the size of pointers, and such code should not in any case be using this attribute. Another erroneous situation arises if the attribute is applied to a constant. The resulting pointer can be used to access the constant, but the effect of trying to modify a constant in this manner is not well-defined. Consider this example: P : constant Integer := 4; type R is access all Integer; RV : R := P'Unrestricted_Access; .. RV.all := 3; Here we attempt to modify the constant P from 4 to 3, but the compiler may or may not notice this attempt, and subsequent references to P may yield either the value 3 or the value 4 or the assignment may blow up if the compiler decides to put P in read-only memory. One particular case where ‘Unrestricted_Access’ can be used in this way is to modify the value of an ‘in’ parameter: procedure K (S : in String) is type R is access all Character; RV : R := S (3)'Unrestricted_Access; begin RV.all := 'a'; end; In general this is a risky approach. It may appear to “work” but such uses of ‘Unrestricted_Access’ are potentially non-portable, even from one version of GNAT to another, so are best avoided if possible.  File: gnat_rm.info, Node: Attribute Update, Next: Attribute Valid_Value, Prev: Attribute Unrestricted_Access, Up: Implementation Defined Attributes 4.72 Attribute Update ===================== The ‘Update’ attribute creates a copy of an array or record value with one or more modified components. The syntax is: PREFIX'Update ( RECORD_COMPONENT_ASSOCIATION_LIST ) PREFIX'Update ( ARRAY_COMPONENT_ASSOCIATION {, ARRAY_COMPONENT_ASSOCIATION } ) PREFIX'Update ( MULTIDIMENSIONAL_ARRAY_COMPONENT_ASSOCIATION {, MULTIDIMENSIONAL_ARRAY_COMPONENT_ASSOCIATION } ) MULTIDIMENSIONAL_ARRAY_COMPONENT_ASSOCIATION ::= INDEX_EXPRESSION_LIST_LIST => EXPRESSION INDEX_EXPRESSION_LIST_LIST ::= INDEX_EXPRESSION_LIST {| INDEX_EXPRESSION_LIST } INDEX_EXPRESSION_LIST ::= ( EXPRESSION {, EXPRESSION } ) where ‘PREFIX’ is the name of an array or record object, the association list in parentheses does not contain an ‘others’ choice and the box symbol ‘<>’ may not appear in any expression. The effect is to yield a copy of the array or record value which is unchanged apart from the components mentioned in the association list, which are changed to the indicated value. The original value of the array or record value is not affected. For example: type Arr is Array (1 .. 5) of Integer; ... Avar1 : Arr := (1,2,3,4,5); Avar2 : Arr := Avar1'Update (2 => 10, 3 .. 4 => 20); yields a value for ‘Avar2’ of 1,10,20,20,5 with ‘Avar1’ begin unmodified. Similarly: type Rec is A, B, C : Integer; ... Rvar1 : Rec := (A => 1, B => 2, C => 3); Rvar2 : Rec := Rvar1'Update (B => 20); yields a value for ‘Rvar2’ of (A => 1, B => 20, C => 3), with ‘Rvar1’ being unmodifed. Note that the value of the attribute reference is computed completely before it is used. This means that if you write: Avar1 := Avar1'Update (1 => 10, 2 => Function_Call); then the value of ‘Avar1’ is not modified if ‘Function_Call’ raises an exception, unlike the effect of a series of direct assignments to elements of ‘Avar1’. In general this requires that two extra complete copies of the object are required, which should be kept in mind when considering efficiency. The ‘Update’ attribute cannot be applied to prefixes of a limited type, and cannot reference discriminants in the case of a record type. The accessibility level of an Update attribute result object is defined as for an aggregate. In the record case, no component can be mentioned more than once. In the array case, two overlapping ranges can appear in the association list, in which case the modifications are processed left to right. Multi-dimensional arrays can be modified, as shown by this example: A : array (1 .. 10, 1 .. 10) of Integer; .. A := A'Update ((1, 2) => 20, (3, 4) => 30); which changes element (1,2) to 20 and (3,4) to 30.  File: gnat_rm.info, Node: Attribute Valid_Value, Next: Attribute Valid_Scalars, Prev: Attribute Update, Up: Implementation Defined Attributes 4.73 Attribute Valid_Value ========================== The ‘'Valid_Value’ attribute is defined for enumeration types other than those in package Standard. This attribute is a function that takes a String, and returns Boolean. ‘T'Valid_Value (S)’ returns True if and only if ‘T'Value (S)’ would not raise Constraint_Error.  File: gnat_rm.info, Node: Attribute Valid_Scalars, Next: Attribute VADS_Size, Prev: Attribute Valid_Value, Up: Implementation Defined Attributes 4.74 Attribute Valid_Scalars ============================ The ‘'Valid_Scalars’ attribute is intended to make it easier to check the validity of scalar subcomponents of composite objects. The attribute is defined for any prefix ‘P’ which denotes an object. Prefix ‘P’ can be any type except for tagged private or ‘Unchecked_Union’ types. The value of the attribute is of type ‘Boolean’. ‘P'Valid_Scalars’ yields ‘True’ if and only if the evaluation of ‘C'Valid’ yields ‘True’ for every scalar subcomponent ‘C’ of ‘P’, or if ‘P’ has no scalar subcomponents. Attribute ‘'Valid_Scalars’ is equivalent to attribute ‘'Valid’ for scalar types. It is not specified in what order the subcomponents are checked, nor whether any more are checked after any one of them is determined to be invalid. If the prefix ‘P’ is of a class-wide type ‘T'Class’ (where ‘T’ is the associated specific type), or if the prefix ‘P’ is of a specific tagged type ‘T’, then only the subcomponents of ‘T’ are checked; in other words, components of extensions of ‘T’ are not checked even if ‘T'Class (P)'Tag /= T'Tag’. The compiler will issue a warning if it can be determined at compile time that the prefix of the attribute has no scalar subcomponents. Note: ‘Valid_Scalars’ can generate a lot of code, especially in the case of a large variant record. If the attribute is called in many places in the same program applied to objects of the same type, it can reduce program size to write a function with a single use of the attribute, and then call that function from multiple places.  File: gnat_rm.info, Node: Attribute VADS_Size, Next: Attribute Value_Size, Prev: Attribute Valid_Scalars, Up: Implementation Defined Attributes 4.75 Attribute VADS_Size ======================== The ‘'VADS_Size’ attribute is intended to make it easier to port legacy code which relies on the semantics of ‘'Size’ as implemented by the VADS Ada 83 compiler. GNAT makes a best effort at duplicating the same semantic interpretation. In particular, ‘'VADS_Size’ applied to a predefined or other primitive type with no Size clause yields the Object_Size (for example, ‘Natural'Size’ is 32 rather than 31 on typical machines). In addition ‘'VADS_Size’ applied to an object gives the result that would be obtained by applying the attribute to the corresponding type.  File: gnat_rm.info, Node: Attribute Value_Size, Next: Attribute Wchar_T_Size, Prev: Attribute VADS_Size, Up: Implementation Defined Attributes 4.76 Attribute Value_Size ========================= ‘type'Value_Size’ is the number of bits required to represent a value of the given subtype. It is the same as ‘type'Size’, but, unlike ‘Size’, may be set for non-first subtypes.  File: gnat_rm.info, Node: Attribute Wchar_T_Size, Next: Attribute Word_Size, Prev: Attribute Value_Size, Up: Implementation Defined Attributes 4.77 Attribute Wchar_T_Size =========================== ‘Standard'Wchar_T_Size’ (‘Standard’ is the only allowed prefix) provides the size in bits of the C ‘wchar_t’ type primarily for constructing the definition of this type in package ‘Interfaces.C’. The result is a static constant.  File: gnat_rm.info, Node: Attribute Word_Size, Prev: Attribute Wchar_T_Size, Up: Implementation Defined Attributes 4.78 Attribute Word_Size ======================== ‘Standard'Word_Size’ (‘Standard’ is the only allowed prefix) provides the value ‘System.Word_Size’. The result is a static constant.  File: gnat_rm.info, Node: Standard and Implementation Defined Restrictions, Next: Implementation Advice, Prev: Implementation Defined Attributes, Up: Top 5 Standard and Implementation Defined Restrictions ************************************************** All Ada Reference Manual-defined Restriction identifiers are implemented: * language-defined restrictions (see 13.12.1) * tasking restrictions (see D.7) * high integrity restrictions (see H.4) GNAT implements additional restriction identifiers. All restrictions, whether language defined or GNAT-specific, are listed in the following. * Menu: * Partition-Wide Restrictions:: * Program Unit Level Restrictions::  File: gnat_rm.info, Node: Partition-Wide Restrictions, Next: Program Unit Level Restrictions, Up: Standard and Implementation Defined Restrictions 5.1 Partition-Wide Restrictions =============================== 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). * 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_Asynchronous_Control:: * 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_Protected_Object_Allocations:: * No_Implicit_Task_Allocations:: * No_Initialize_Scalars:: * No_IO:: * No_Local_Allocators:: * No_Local_Protected_Objects:: * No_Local_Tagged_Types:: * No_Local_Timing_Events:: * No_Long_Long_Integers:: * No_Multiple_Elaboration:: * No_Nested_Finalization:: * No_Protected_Type_Allocators:: * No_Protected_Types:: * No_Recursion:: * No_Reentrancy:: * 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_Tagged_Type_Registration:: * No_Task_Allocators:: * No_Task_At_Interrupt_Priority:: * No_Task_Attributes_Package:: * No_Task_Hierarchy:: * No_Task_Termination:: * No_Tasking:: * No_Terminate_Alternatives:: * No_Unchecked_Access:: * No_Unchecked_Conversion:: * No_Unchecked_Deallocation:: * No_Use_Of_Attribute:: * No_Use_Of_Entity:: * No_Use_Of_Pragma:: * Pure_Barriers:: * Simple_Barriers:: * Static_Priorities:: * Static_Storage_Size::  File: gnat_rm.info, Node: Immediate_Reclamation, Next: Max_Asynchronous_Select_Nesting, Up: Partition-Wide Restrictions 5.1.1 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.  File: gnat_rm.info, Node: Max_Asynchronous_Select_Nesting, Next: Max_Entry_Queue_Length, Prev: Immediate_Reclamation, Up: Partition-Wide Restrictions 5.1.2 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.  File: gnat_rm.info, Node: Max_Entry_Queue_Length, Next: Max_Protected_Entries, Prev: Max_Asynchronous_Select_Nesting, Up: Partition-Wide Restrictions 5.1.3 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. The restriction ‘Max_Entry_Queue_Depth’ is recognized as a synonym for ‘Max_Entry_Queue_Length’. This is retained for historical compatibility purposes (and a warning will be generated for its use if warnings on obsolescent features are activated).  File: gnat_rm.info, Node: Max_Protected_Entries, Next: Max_Select_Alternatives, Prev: Max_Entry_Queue_Length, Up: Partition-Wide Restrictions 5.1.4 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.  File: gnat_rm.info, Node: Max_Select_Alternatives, Next: Max_Storage_At_Blocking, Prev: Max_Protected_Entries, Up: Partition-Wide Restrictions 5.1.5 Max_Select_Alternatives ----------------------------- [RM D.7] Specifies the maximum number of alternatives in a selective accept.  File: gnat_rm.info, Node: Max_Storage_At_Blocking, Next: Max_Task_Entries, Prev: Max_Select_Alternatives, Up: Partition-Wide Restrictions 5.1.6 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.  File: gnat_rm.info, Node: Max_Task_Entries, Next: Max_Tasks, Prev: Max_Storage_At_Blocking, Up: Partition-Wide Restrictions 5.1.7 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.  File: gnat_rm.info, Node: Max_Tasks, Next: No_Abort_Statements, Prev: Max_Task_Entries, Up: Partition-Wide Restrictions 5.1.8 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.  File: gnat_rm.info, Node: No_Abort_Statements, Next: No_Access_Parameter_Allocators, Prev: Max_Tasks, Up: Partition-Wide Restrictions 5.1.9 No_Abort_Statements ------------------------- [RM D.7] There are no abort_statements, and there are no calls to Task_Identification.Abort_Task.  File: gnat_rm.info, Node: No_Access_Parameter_Allocators, Next: No_Access_Subprograms, Prev: No_Abort_Statements, Up: Partition-Wide Restrictions 5.1.10 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.  File: gnat_rm.info, Node: No_Access_Subprograms, Next: No_Allocators, Prev: No_Access_Parameter_Allocators, Up: Partition-Wide Restrictions 5.1.11 No_Access_Subprograms ---------------------------- [RM H.4] This restriction ensures at compile time that there are no declarations of access-to-subprogram types.  File: gnat_rm.info, Node: No_Allocators, Next: No_Anonymous_Allocators, Prev: No_Access_Subprograms, Up: Partition-Wide Restrictions 5.1.12 No_Allocators -------------------- [RM H.4] This restriction ensures at compile time that there are no occurrences of an allocator.  File: gnat_rm.info, Node: No_Anonymous_Allocators, Next: No_Asynchronous_Control, Prev: No_Allocators, Up: Partition-Wide Restrictions 5.1.13 No_Anonymous_Allocators ------------------------------ [RM H.4] This restriction ensures at compile time that there are no occurrences of an allocator of anonymous access type.  File: gnat_rm.info, Node: No_Asynchronous_Control, Next: No_Calendar, Prev: No_Anonymous_Allocators, Up: Partition-Wide Restrictions 5.1.14 No_Asynchronous_Control ------------------------------ [RM J.13] This restriction ensures at compile time that there are no semantic dependences on the predefined package Asynchronous_Task_Control.  File: gnat_rm.info, Node: No_Calendar, Next: No_Coextensions, Prev: No_Asynchronous_Control, Up: Partition-Wide Restrictions 5.1.15 No_Calendar ------------------ [GNAT] This restriction ensures at compile time that there are no semantic dependences on package Calendar.  File: gnat_rm.info, Node: No_Coextensions, Next: No_Default_Initialization, Prev: No_Calendar, Up: Partition-Wide Restrictions 5.1.16 No_Coextensions ---------------------- [RM H.4] This restriction ensures at compile time that there are no coextensions. See 3.10.2.  File: gnat_rm.info, Node: No_Default_Initialization, Next: No_Delay, Prev: No_Coextensions, Up: Partition-Wide Restrictions 5.1.17 No_Default_Initialization -------------------------------- [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).  File: gnat_rm.info, Node: No_Delay, Next: No_Dependence, Prev: No_Default_Initialization, Up: Partition-Wide Restrictions 5.1.18 No_Delay --------------- [RM H.4] This restriction ensures at compile time that there are no delay statements and no semantic dependences on package Calendar.  File: gnat_rm.info, Node: No_Dependence, Next: No_Direct_Boolean_Operators, Prev: No_Delay, Up: Partition-Wide Restrictions 5.1.19 No_Dependence -------------------- [RM 13.12.1] This restriction ensures at compile time that there are no dependences on a library unit. For GNAT, this includes implicit implementation dependences on units of the runtime library that are created by the compiler to support specific constructs of the language. Here are some examples: * ‘System.Arith_64’: 64-bit arithmetics for 32-bit platforms, * ‘System.Arith_128’: 128-bit arithmetics for 64-bit platforms, * ‘System.Memory’: heap memory allocation routines, * ‘System.Memory_Compare’: memory comparison routine (aka ‘memcmp’ for C), * ‘System.Memory_Copy’: memory copy routine (aka ‘memcpy’ for C), * ‘System.Memory_Move’: memoy move routine (aka ‘memmove’ for C), * ‘System.Memory_Set’: memory set routine (aka ‘memset’ for C), * ‘System.Stack_Checking[.Operations]’: stack checking without MMU, * ‘System.GCC’: support routines from the GCC library.  File: gnat_rm.info, Node: No_Direct_Boolean_Operators, Next: No_Dispatch, Prev: No_Dependence, Up: Partition-Wide Restrictions 5.1.20 No_Direct_Boolean_Operators ---------------------------------- [GNAT] This restriction ensures that no logical operators (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.  File: gnat_rm.info, Node: No_Dispatch, Next: No_Dispatching_Calls, Prev: No_Direct_Boolean_Operators, Up: Partition-Wide Restrictions 5.1.21 No_Dispatch ------------------ [RM H.4] This restriction ensures at compile time that there are no occurrences of ‘T'Class’, for any (tagged) subtype ‘T’.  File: gnat_rm.info, Node: No_Dispatching_Calls, Next: No_Dynamic_Attachment, Prev: No_Dispatch, Up: Partition-Wide Restrictions 5.1.22 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 ‘No_Dispatch’ except that it is a bit less restrictive in that it allows all classwide constructs that do not imply dispatching. The following example indicates constructs that violate this restriction. package Pkg is type T is tagged record Data : Natural; end record; procedure P (X : T); type DT is new T with record More_Data : Natural; end record; procedure Q (X : DT); end Pkg; with Pkg; use Pkg; procedure Example is procedure Test (O : T'Class) is N : Natural := O'Size; -- Error: Dispatching call C : T'Class := O; -- Error: implicit Dispatching Call begin if O in DT'Class then -- OK : Membership test Q (DT (O)); -- OK : Type conversion plus direct call else P (O); -- Error: Dispatching call end if; end Test; Obj : DT; begin P (Obj); -- OK : Direct call P (T (Obj)); -- OK : Type conversion plus direct call P (T'Class (Obj)); -- Error: Dispatching call Test (Obj); -- OK : Type conversion if Obj in T'Class then -- OK : Membership test null; end if; end Example;  File: gnat_rm.info, Node: No_Dynamic_Attachment, Next: No_Dynamic_Priorities, Prev: No_Dispatching_Calls, Up: Partition-Wide Restrictions 5.1.23 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). The restriction ‘No_Dynamic_Interrupts’ is recognized as a synonym for ‘No_Dynamic_Attachment’. This is retained for historical compatibility purposes (and a warning will be generated for its use if warnings on obsolescent features are activated).  File: gnat_rm.info, Node: No_Dynamic_Priorities, Next: No_Entry_Calls_In_Elaboration_Code, Prev: No_Dynamic_Attachment, Up: Partition-Wide Restrictions 5.1.24 No_Dynamic_Priorities ---------------------------- [RM D.7] There are no semantic dependencies on the package Dynamic_Priorities.  File: gnat_rm.info, Node: No_Entry_Calls_In_Elaboration_Code, Next: No_Enumeration_Maps, Prev: No_Dynamic_Priorities, Up: Partition-Wide Restrictions 5.1.25 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.  File: gnat_rm.info, Node: No_Enumeration_Maps, Next: No_Exception_Handlers, Prev: No_Entry_Calls_In_Elaboration_Code, Up: Partition-Wide Restrictions 5.1.26 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).  File: gnat_rm.info, Node: No_Exception_Handlers, Next: No_Exception_Propagation, Prev: No_Enumeration_Maps, Up: Partition-Wide Restrictions 5.1.27 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: procedure Last_Chance_Handler (Source_Location : System.Address; Line : Integer); pragma Export (C, Last_Chance_Handler, "__gnat_last_chance_handler"); The parameter is a C null-terminated string representing a message to be associated with the exception (typically the source location of the raise statement generated by the compiler). The Line parameter when nonzero represents the line number in the source program where the raise occurs.  File: gnat_rm.info, Node: No_Exception_Propagation, Next: No_Exception_Registration, Prev: No_Exception_Handlers, Up: Partition-Wide Restrictions 5.1.28 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.  File: gnat_rm.info, Node: No_Exception_Registration, Next: No_Exceptions, Prev: No_Exception_Propagation, Up: Partition-Wide Restrictions 5.1.29 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 restriction is active, the generated code is simplified by omitting the otherwise-required global registration of exceptions when they are declared.  File: gnat_rm.info, Node: No_Exceptions, Next: No_Finalization, Prev: No_Exception_Registration, Up: Partition-Wide Restrictions 5.1.30 No_Exceptions -------------------- [RM H.4] This restriction ensures at compile time that there are no raise statements and no exception handlers and also suppresses the generation of language-defined run-time checks.  File: gnat_rm.info, Node: No_Finalization, Next: No_Fixed_Point, Prev: No_Exceptions, Up: Partition-Wide Restrictions 5.1.31 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: * ‘Ada.Finalization.Controlled’ * ‘Ada.Finalization.Limited_Controlled’ * Derivations from ‘Controlled’ or ‘Limited_Controlled’ * Class-wide types * Protected types * Task types * Array and record types with controlled components 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.  File: gnat_rm.info, Node: No_Fixed_Point, Next: No_Floating_Point, Prev: No_Finalization, Up: Partition-Wide Restrictions 5.1.32 No_Fixed_Point --------------------- [RM H.4] This restriction ensures at compile time that there are no occurrences of fixed point types and operations.  File: gnat_rm.info, Node: No_Floating_Point, Next: No_Implicit_Conditionals, Prev: No_Fixed_Point, Up: Partition-Wide Restrictions 5.1.33 No_Floating_Point ------------------------ [RM H.4] This restriction ensures at compile time that there are no occurrences of floating point types and operations.  File: gnat_rm.info, Node: No_Implicit_Conditionals, Next: No_Implicit_Dynamic_Code, Prev: No_Floating_Point, Up: Partition-Wide Restrictions 5.1.34 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.  File: gnat_rm.info, Node: No_Implicit_Dynamic_Code, Next: No_Implicit_Heap_Allocations, Prev: No_Implicit_Conditionals, Up: Partition-Wide Restrictions 5.1.35 No_Implicit_Dynamic_Code ------------------------------- [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: ‘Access’, ‘Unrestricted_Access’, or ‘Address’ of a nested subprogram; nested task bodies; primitive operations of nested tagged types. Trampolines do not work on machines that prevent execution of stack data. For example, on windows systems, enabling DEP (data execution protection) will cause trampolines to raise an exception. 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: ‘Address’ of a nested subprogram; ‘Access’ or ‘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.  File: gnat_rm.info, Node: No_Implicit_Heap_Allocations, Next: No_Implicit_Protected_Object_Allocations, Prev: No_Implicit_Dynamic_Code, Up: Partition-Wide Restrictions 5.1.36 No_Implicit_Heap_Allocations ----------------------------------- [RM D.7] No constructs are allowed to cause implicit heap allocation.  File: gnat_rm.info, Node: No_Implicit_Protected_Object_Allocations, Next: No_Implicit_Task_Allocations, Prev: No_Implicit_Heap_Allocations, Up: Partition-Wide Restrictions 5.1.37 No_Implicit_Protected_Object_Allocations ----------------------------------------------- [GNAT] No constructs are allowed to cause implicit heap allocation of a protected object.  File: gnat_rm.info, Node: No_Implicit_Task_Allocations, Next: No_Initialize_Scalars, Prev: No_Implicit_Protected_Object_Allocations, Up: Partition-Wide Restrictions 5.1.38 No_Implicit_Task_Allocations ----------------------------------- [GNAT] No constructs are allowed to cause implicit heap allocation of a task.  File: gnat_rm.info, Node: No_Initialize_Scalars, Next: No_IO, Prev: No_Implicit_Task_Allocations, Up: Partition-Wide Restrictions 5.1.39 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.  File: gnat_rm.info, Node: No_IO, Next: No_Local_Allocators, Prev: No_Initialize_Scalars, Up: Partition-Wide Restrictions 5.1.40 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.  File: gnat_rm.info, Node: No_Local_Allocators, Next: No_Local_Protected_Objects, Prev: No_IO, Up: Partition-Wide Restrictions 5.1.41 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.  File: gnat_rm.info, Node: No_Local_Protected_Objects, Next: No_Local_Tagged_Types, Prev: No_Local_Allocators, Up: Partition-Wide Restrictions 5.1.42 No_Local_Protected_Objects --------------------------------- [RM D.7] This restriction ensures at compile time that protected objects are only declared at the library level.  File: gnat_rm.info, Node: No_Local_Tagged_Types, Next: No_Local_Timing_Events, Prev: No_Local_Protected_Objects, Up: Partition-Wide Restrictions 5.1.43 No_Local_Tagged_Types ---------------------------- [GNAT] This restriction ensures at compile time that tagged types are only declared at the library level.  File: gnat_rm.info, Node: No_Local_Timing_Events, Next: No_Long_Long_Integers, Prev: No_Local_Tagged_Types, Up: Partition-Wide Restrictions 5.1.44 No_Local_Timing_Events ----------------------------- [RM D.7] All objects of type Ada.Real_Time.Timing_Events.Timing_Event are declared at the library level.  File: gnat_rm.info, Node: No_Long_Long_Integers, Next: No_Multiple_Elaboration, Prev: No_Local_Timing_Events, Up: Partition-Wide Restrictions 5.1.45 No_Long_Long_Integers ---------------------------- [GNAT] This partition-wide restriction forbids any explicit reference to type Standard.Long_Long_Integer, and also forbids declaring range types whose implicit base type is Long_Long_Integer, and modular types whose size exceeds Long_Integer’Size.  File: gnat_rm.info, Node: No_Multiple_Elaboration, Next: No_Nested_Finalization, Prev: No_Long_Long_Integers, Up: Partition-Wide Restrictions 5.1.46 No_Multiple_Elaboration ------------------------------ [GNAT] When this restriction is active and the static elaboration model is used, and -fpreserve-control-flow is not used, the compiler is allowed to suppress the elaboration counter normally associated with the unit, even if the unit has elaboration code. This counter is typically used to check for access before elaboration and to control multiple elaboration attempts. If the restriction is used, then the situations in which multiple elaboration is possible, including non-Ada main programs and Stand Alone libraries, are not permitted and will be diagnosed by the binder.  File: gnat_rm.info, Node: No_Nested_Finalization, Next: No_Protected_Type_Allocators, Prev: No_Multiple_Elaboration, Up: Partition-Wide Restrictions 5.1.47 No_Nested_Finalization ----------------------------- [RM D.7] All objects requiring finalization are declared at the library level.  File: gnat_rm.info, Node: No_Protected_Type_Allocators, Next: No_Protected_Types, Prev: No_Nested_Finalization, Up: Partition-Wide Restrictions 5.1.48 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.  File: gnat_rm.info, Node: No_Protected_Types, Next: No_Recursion, Prev: No_Protected_Type_Allocators, Up: Partition-Wide Restrictions 5.1.49 No_Protected_Types ------------------------- [RM H.4] This restriction ensures at compile time that there are no declarations of protected types or protected objects.  File: gnat_rm.info, Node: No_Recursion, Next: No_Reentrancy, Prev: No_Protected_Types, Up: Partition-Wide Restrictions 5.1.50 No_Recursion ------------------- [RM H.4] A program execution is erroneous if a subprogram is invoked as part of its execution.  File: gnat_rm.info, Node: No_Reentrancy, Next: No_Relative_Delay, Prev: No_Recursion, Up: Partition-Wide Restrictions 5.1.51 No_Reentrancy -------------------- [RM H.4] A program execution is erroneous if a subprogram is executed by two tasks at the same time.  File: gnat_rm.info, Node: No_Relative_Delay, Next: No_Requeue_Statements, Prev: No_Reentrancy, Up: Partition-Wide Restrictions 5.1.52 No_Relative_Delay ------------------------ [RM D.7] This restriction ensures at compile time that there are no delay relative statements and prevents expressions such as ‘delay 1.23;’ from appearing in source code.  File: gnat_rm.info, Node: No_Requeue_Statements, Next: No_Secondary_Stack, Prev: No_Relative_Delay, Up: Partition-Wide Restrictions 5.1.53 No_Requeue_Statements ---------------------------- [RM D.7] This restriction ensures at compile time that no requeue statements are permitted and prevents keyword ‘requeue’ from being used in source code. The restriction ‘No_Requeue’ is recognized as a synonym for ‘No_Requeue_Statements’. This is retained for historical compatibility purposes (and a warning will be generated for its use if warnings on oNobsolescent features are activated).  File: gnat_rm.info, Node: No_Secondary_Stack, Next: No_Select_Statements, Prev: No_Requeue_Statements, Up: Partition-Wide Restrictions 5.1.54 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. Suppresses the allocation of secondary stacks for tasks (excluding the environment task) at run time.  File: gnat_rm.info, Node: No_Select_Statements, Next: No_Specific_Termination_Handlers, Prev: No_Secondary_Stack, Up: Partition-Wide Restrictions 5.1.55 No_Select_Statements --------------------------- [RM D.7] This restriction ensures at compile time no select statements of any kind are permitted, that is the keyword ‘select’ may not appear.  File: gnat_rm.info, Node: No_Specific_Termination_Handlers, Next: No_Specification_of_Aspect, Prev: No_Select_Statements, Up: Partition-Wide Restrictions 5.1.56 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.  File: gnat_rm.info, Node: No_Specification_of_Aspect, Next: No_Standard_Allocators_After_Elaboration, Prev: No_Specific_Termination_Handlers, Up: Partition-Wide Restrictions 5.1.57 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.  File: gnat_rm.info, Node: No_Standard_Allocators_After_Elaboration, Next: No_Standard_Storage_Pools, Prev: No_Specification_of_Aspect, Up: Partition-Wide Restrictions 5.1.58 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.  File: gnat_rm.info, Node: No_Standard_Storage_Pools, Next: No_Stream_Optimizations, Prev: No_Standard_Allocators_After_Elaboration, Up: Partition-Wide Restrictions 5.1.59 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.  File: gnat_rm.info, Node: No_Stream_Optimizations, Next: No_Streams, Prev: No_Standard_Storage_Pools, Up: Partition-Wide Restrictions 5.1.60 No_Stream_Optimizations ------------------------------ [GNAT] This restriction affects the performance of stream operations on types ‘String’, ‘Wide_String’ and ‘Wide_Wide_String’. By default, the compiler uses block reads and writes when manipulating ‘String’ objects due to their superior performance. When this restriction is in effect, the compiler performs all IO operations on a per-character basis.  File: gnat_rm.info, Node: No_Streams, Next: No_Tagged_Type_Registration, Prev: No_Stream_Optimizations, Up: Partition-Wide Restrictions 5.1.61 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 ‘Ada.Streams’. So it is permissible to with ‘Ada.Streams’ (or another package that does so itself) as long as no actual stream objects are created 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.  File: gnat_rm.info, Node: No_Tagged_Type_Registration, Next: No_Task_Allocators, Prev: No_Streams, Up: Partition-Wide Restrictions 5.1.62 No_Tagged_Type_Registration ---------------------------------- [GNAT] If this restriction is active, then class-wide streaming attributes are not supported. In addition, the subprograms in Ada.Tags are not supported. If this restriction is active, the generated code is simplified by omitting the otherwise-required global registration of tagged types when they are declared. This restriction may be necessary in order to also apply the No_Elaboration_Code restriction.  File: gnat_rm.info, Node: No_Task_Allocators, Next: No_Task_At_Interrupt_Priority, Prev: No_Tagged_Type_Registration, Up: Partition-Wide Restrictions 5.1.63 No_Task_Allocators ------------------------- [RM D.7] There are no allocators for task types or types containing task subcomponents.  File: gnat_rm.info, Node: No_Task_At_Interrupt_Priority, Next: No_Task_Attributes_Package, Prev: No_Task_Allocators, Up: Partition-Wide Restrictions 5.1.64 No_Task_At_Interrupt_Priority ------------------------------------ [GNAT] This restriction ensures at compile time that there is no Interrupt_Priority aspect or pragma for a task or a task type. As a consequence, the tasks are always created with a priority below that an interrupt priority.  File: gnat_rm.info, Node: No_Task_Attributes_Package, Next: No_Task_Hierarchy, Prev: No_Task_At_Interrupt_Priority, Up: Partition-Wide Restrictions 5.1.65 No_Task_Attributes_Package --------------------------------- [GNAT] This restriction ensures at compile time that there are no implicit or explicit dependencies on the package ‘Ada.Task_Attributes’. The restriction ‘No_Task_Attributes’ is recognized as a synonym for ‘No_Task_Attributes_Package’. This is retained for historical compatibility purposes (and a warning will be generated for its use if warnings on obsolescent features are activated).  File: gnat_rm.info, Node: No_Task_Hierarchy, Next: No_Task_Termination, Prev: No_Task_Attributes_Package, Up: Partition-Wide Restrictions 5.1.66 No_Task_Hierarchy ------------------------ [RM D.7] All (non-environment) tasks depend directly on the environment task of the partition.  File: gnat_rm.info, Node: No_Task_Termination, Next: No_Tasking, Prev: No_Task_Hierarchy, Up: Partition-Wide Restrictions 5.1.67 No_Task_Termination -------------------------- [RM D.7] Tasks that terminate are erroneous.  File: gnat_rm.info, Node: No_Tasking, Next: No_Terminate_Alternatives, Prev: No_Task_Termination, Up: Partition-Wide Restrictions 5.1.68 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 ‘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.  File: gnat_rm.info, Node: No_Terminate_Alternatives, Next: No_Unchecked_Access, Prev: No_Tasking, Up: Partition-Wide Restrictions 5.1.69 No_Terminate_Alternatives -------------------------------- [RM D.7] There are no selective accepts with terminate alternatives.  File: gnat_rm.info, Node: No_Unchecked_Access, Next: No_Unchecked_Conversion, Prev: No_Terminate_Alternatives, Up: Partition-Wide Restrictions 5.1.70 No_Unchecked_Access -------------------------- [RM H.4] This restriction ensures at compile time that there are no occurrences of the Unchecked_Access attribute.  File: gnat_rm.info, Node: No_Unchecked_Conversion, Next: No_Unchecked_Deallocation, Prev: No_Unchecked_Access, Up: Partition-Wide Restrictions 5.1.71 No_Unchecked_Conversion ------------------------------ [RM J.13] This restriction ensures at compile time that there are no semantic dependences on the predefined generic function Unchecked_Conversion.  File: gnat_rm.info, Node: No_Unchecked_Deallocation, Next: No_Use_Of_Attribute, Prev: No_Unchecked_Conversion, Up: Partition-Wide Restrictions 5.1.72 No_Unchecked_Deallocation -------------------------------- [RM J.13] This restriction ensures at compile time that there are no semantic dependences on the predefined generic procedure Unchecked_Deallocation.  File: gnat_rm.info, Node: No_Use_Of_Attribute, Next: No_Use_Of_Entity, Prev: No_Unchecked_Deallocation, Up: Partition-Wide Restrictions 5.1.73 No_Use_Of_Attribute -------------------------- [RM 13.12.1] This is a standard Ada 2012 restriction that is GNAT defined in earlier versions of Ada.  File: gnat_rm.info, Node: No_Use_Of_Entity, Next: No_Use_Of_Pragma, Prev: No_Use_Of_Attribute, Up: Partition-Wide Restrictions 5.1.74 No_Use_Of_Entity ----------------------- [GNAT] This restriction ensures at compile time that there are no references to the entity given in the form No_Use_Of_Entity => Name where ‘Name’ is the fully qualified entity, for example No_Use_Of_Entity => Ada.Text_IO.Put_Line  File: gnat_rm.info, Node: No_Use_Of_Pragma, Next: Pure_Barriers, Prev: No_Use_Of_Entity, Up: Partition-Wide Restrictions 5.1.75 No_Use_Of_Pragma ----------------------- [RM 13.12.1] This is a standard Ada 2012 restriction that is GNAT defined in earlier versions of Ada.  File: gnat_rm.info, Node: Pure_Barriers, Next: Simple_Barriers, Prev: No_Use_Of_Pragma, Up: Partition-Wide Restrictions 5.1.76 Pure_Barriers -------------------- [GNAT] This restriction ensures at compile time that protected entry barriers are restricted to: * components of the protected object (excluding selection from dereferences), * constant declarations, * named numbers, * enumeration literals, * integer literals, * real literals, * character literals, * implicitly defined comparison operators, * uses of the Standard.”not” operator, * short-circuit operator, * the Count attribute This restriction is a relaxation of the Simple_Barriers restriction, but still ensures absence of side effects, exceptions, and recursion during the evaluation of the barriers.  File: gnat_rm.info, Node: Simple_Barriers, Next: Static_Priorities, Prev: Pure_Barriers, Up: Partition-Wide Restrictions 5.1.77 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. The restriction ‘Boolean_Entry_Barriers’ is recognized as a synonym for ‘Simple_Barriers’. This is retained for historical compatibility purposes (and a warning will be generated for its use if warnings on obsolescent features are activated).  File: gnat_rm.info, Node: Static_Priorities, Next: Static_Storage_Size, Prev: Simple_Barriers, Up: Partition-Wide Restrictions 5.1.78 Static_Priorities ------------------------ [GNAT] This restriction ensures at compile time that all priority expressions are static, and that there are no dependences on the package ‘Ada.Dynamic_Priorities’.  File: gnat_rm.info, Node: Static_Storage_Size, Prev: Static_Priorities, Up: Partition-Wide Restrictions 5.1.79 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.  File: gnat_rm.info, Node: Program Unit Level Restrictions, Prev: Partition-Wide Restrictions, Up: Standard and Implementation Defined Restrictions 5.2 Program Unit Level Restrictions =================================== 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_Dynamic_Accessibility_Checks:: * No_Dynamic_Sized_Objects:: * 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_Implicit_Loops:: * No_Obsolescent_Features:: * No_Wide_Characters:: * Static_Dispatch_Tables:: * SPARK_05::  File: gnat_rm.info, Node: No_Elaboration_Code, Next: No_Dynamic_Accessibility_Checks, Up: Program Unit Level Restrictions 5.2.1 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 ‘Preelaborate’. There are cases in which pragma ‘Preelaborate’ still permits code to be generated (e.g., code to initialize a large array to all zeroes), and there are cases of units which do not meet the requirements for pragma ‘Preelaborate’, but for which no elaboration code is generated. Generally, it is the case that preelaborable units will meet the restrictions, with the exception of large aggregates initialized with an others_clause, and exception declarations (which generate calls to a run-time registry procedure). This restriction is enforced on a unit by unit basis, it need not be obeyed consistently throughout a partition. In the case of aggregates with others, if the aggregate has a dynamic size, there is no way to eliminate the elaboration code (such dynamic bounds would be incompatible with ‘Preelaborate’ in any case). If the bounds are static, then use of this restriction actually modifies the code choice of the compiler to avoid generating a loop, and instead generate the aggregate statically if possible, no matter how many times the data for the others clause must be repeatedly generated. It is not possible to precisely document the constructs which are compatible with this restriction, since, unlike most other restrictions, this is not a restriction on the source code, but a restriction on the generated object code. For example, if the source contains a declaration: Val : constant Integer := X; where X is not a static constant, it may be possible, depending on complex optimization circuitry, for the compiler to figure out the value of X at compile time, in which case this initialization can be done by the loader, and requires no initialization code. It is not possible to document the precise conditions under which the optimizer can figure this out. Note that this the implementation of this restriction requires full code generation. If it is used in conjunction with “semantics only” checking, then some cases of violations may be missed. When this restriction is active, we are not requesting control-flow preservation with -fpreserve-control-flow, and the static elaboration model is used, the compiler is allowed to suppress the elaboration counter normally associated with the unit. This counter is typically used to check for access before elaboration and to control multiple elaboration attempts.  File: gnat_rm.info, Node: No_Dynamic_Accessibility_Checks, Next: No_Dynamic_Sized_Objects, Prev: No_Elaboration_Code, Up: Program Unit Level Restrictions 5.2.2 No_Dynamic_Accessibility_Checks ------------------------------------- [GNAT] No dynamic accessibility checks are generated when this restriction is in effect. Instead, dangling references are prevented via more conservative compile-time checking. More specifically, existing compile-time checks are enforced but with more conservative assumptions about the accessibility levels of the relevant entities. These conservative assumptions eliminate the need for dynamic accessibility checks. These new rules for computing (at compile-time) the accessibility level of an anonymous access type T are as follows: * If T is a function result type then, from the caller’s perspective, its level is that of the innermost master enclosing the function call. From the callee’s perspective, the level of parameters and local variables of the callee is statically deeper than the level of T. For any other accessibility level L such that the level of parameters and local variables of the callee is statically deeper than L, the level of T (from the callee’s perspective) is also statically deeper than L. * If T is the type of a formal parameter then, from the caller’s perspective, its level is at least as deep as that of the type of the corresponding actual parameter (whatever that actual parameter might be). From the callee’s perspective, the level of parameters and local variables of the callee is statically deeper than the level of T. * If T is the type of a discriminant then its level is that of the discriminated type. * If T is the type of a stand-alone object then its level is the level of the object. * In all other cases, the level of T is as defined by the existing rules of Ada.  File: gnat_rm.info, Node: No_Dynamic_Sized_Objects, Next: No_Entry_Queue, Prev: No_Dynamic_Accessibility_Checks, Up: Program Unit Level Restrictions 5.2.3 No_Dynamic_Sized_Objects ------------------------------ [GNAT] This restriction disallows certain constructs that might lead to the creation of dynamic-sized composite objects (or array or discriminated type). An array subtype indication is illegal if the bounds are not static or references to discriminants of an enclosing type. A discriminated subtype indication is illegal if the type has discriminant-dependent array components or a variant part, and the discriminants are not static. In addition, array and record aggregates are illegal in corresponding cases. Note that this restriction does not forbid access discriminants. It is often a good idea to combine this restriction with No_Secondary_Stack.  File: gnat_rm.info, Node: No_Entry_Queue, Next: No_Implementation_Aspect_Specifications, Prev: No_Dynamic_Sized_Objects, Up: Program Unit Level Restrictions 5.2.4 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.  File: gnat_rm.info, Node: No_Implementation_Aspect_Specifications, Next: No_Implementation_Attributes, Prev: No_Entry_Queue, Up: Program Unit Level Restrictions 5.2.5 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.  File: gnat_rm.info, Node: No_Implementation_Attributes, Next: No_Implementation_Identifiers, Prev: No_Implementation_Aspect_Specifications, Up: Program Unit Level Restrictions 5.2.6 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.  File: gnat_rm.info, Node: No_Implementation_Identifiers, Next: No_Implementation_Pragmas, Prev: No_Implementation_Attributes, Up: Program Unit Level Restrictions 5.2.7 No_Implementation_Identifiers ----------------------------------- [RM 13.12.1] This restriction checks at compile time that no implementation-defined identifiers (marked with pragma Implementation_Defined) occur within language-defined packages.  File: gnat_rm.info, Node: No_Implementation_Pragmas, Next: No_Implementation_Restrictions, Prev: No_Implementation_Identifiers, Up: Program Unit Level Restrictions 5.2.8 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.  File: gnat_rm.info, Node: No_Implementation_Restrictions, Next: No_Implementation_Units, Prev: No_Implementation_Pragmas, Up: Program Unit Level Restrictions 5.2.9 No_Implementation_Restrictions ------------------------------------ [GNAT] This restriction checks at compile time that no GNAT-defined restriction identifiers (other than ‘No_Implementation_Restrictions’ itself) are present. With this restriction, the only other restriction identifiers that can be used are those defined in the Ada Reference Manual.  File: gnat_rm.info, Node: No_Implementation_Units, Next: No_Implicit_Aliasing, Prev: No_Implementation_Restrictions, Up: Program Unit Level Restrictions 5.2.10 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.  File: gnat_rm.info, Node: No_Implicit_Aliasing, Next: No_Implicit_Loops, Prev: No_Implementation_Units, Up: Program Unit Level Restrictions 5.2.11 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.  File: gnat_rm.info, Node: No_Implicit_Loops, Next: No_Obsolescent_Features, Prev: No_Implicit_Aliasing, Up: Program Unit Level Restrictions 5.2.12 No_Implicit_Loops ------------------------ [GNAT] This restriction ensures that the generated code of the unit marked with this restriction does not contain any implicit ‘for’ loops, either by modifying the generated code where possible, or by rejecting any construct that would otherwise generate an implicit ‘for’ loop. If this restriction is active, it is possible to build large array aggregates with all static components without generating an intermediate temporary, and without generating a loop to initialize individual components. Otherwise, a loop is created for arrays larger than about 5000 scalar components. Note that if this restriction is set in the spec of a package, it will not apply to its body.  File: gnat_rm.info, Node: No_Obsolescent_Features, Next: No_Wide_Characters, Prev: No_Implicit_Loops, Up: Program Unit Level Restrictions 5.2.13 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.  File: gnat_rm.info, Node: No_Wide_Characters, Next: Static_Dispatch_Tables, Prev: No_Obsolescent_Features, Up: Program Unit Level Restrictions 5.2.14 No_Wide_Characters ------------------------- [GNAT] This restriction ensures at compile time that no uses of the types ‘Wide_Character’ or ‘Wide_String’ or corresponding wide wide types appear, and that no wide or wide wide string or character literals appear in the program (that is literals representing characters not in type ‘Character’).  File: gnat_rm.info, Node: Static_Dispatch_Tables, Next: SPARK_05, Prev: No_Wide_Characters, Up: Program Unit Level Restrictions 5.2.15 Static_Dispatch_Tables ----------------------------- [GNAT] This restriction checks at compile time that all the artifacts associated with dispatch tables can be placed in read-only memory.  File: gnat_rm.info, Node: SPARK_05, Prev: Static_Dispatch_Tables, Up: Program Unit Level Restrictions 5.2.16 SPARK_05 --------------- [GNAT] This restriction no longer has any effect and is superseded by SPARK 2014, whose restrictions are checked by the tool GNATprove. To check that a codebase respects SPARK 2014 restrictions, mark the code with pragma or aspect ‘SPARK_Mode’, and run the tool GNATprove at Stone assurance level, as follows: gnatprove -P project.gpr --mode=stone or equivalently: gnatprove -P project.gpr --mode=check_all  File: gnat_rm.info, Node: Implementation Advice, Next: Implementation Defined Characteristics, Prev: Standard and Implementation Defined Restrictions, Up: Top 6 Implementation Advice *********************** The main text of the Ada Reference Manual describes the required behavior of all Ada compilers, and the GNAT compiler conforms to these requirements. 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. They are not requirements, because they describe behavior that cannot be provided on all systems, or may be undesirable on some systems. As far as practical, GNAT follows the implementation advice in the Ada Reference Manual. Each such RM section corresponds to a section in this chapter whose title specifies the RM section number and paragraph number and the subject of the advice. The contents of each section consists of the RM text within quotation marks, followed by the GNAT interpretation of the 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. * Menu: * RM 1.1.3(20); Error Detection: RM 1 1 3 20 Error Detection. * RM 1.1.3(31); Child Units: RM 1 1 3 31 Child Units. * RM 1.1.5(12); Bounded Errors: RM 1 1 5 12 Bounded Errors. * RM 2.8(16); Pragmas: RM 2 8 16 Pragmas. * RM 2.8(17-19); Pragmas: RM 2 8 17-19 Pragmas. * RM 3.5.2(5); Alternative Character Sets: RM 3 5 2 5 Alternative Character Sets. * RM 3.5.4(28); Integer Types: RM 3 5 4 28 Integer Types. * RM 3.5.4(29); Integer Types: RM 3 5 4 29 Integer Types. * RM 3.5.5(8); Enumeration Values: RM 3 5 5 8 Enumeration Values. * RM 3.5.7(17); Float Types: RM 3 5 7 17 Float Types. * RM 3.6.2(11); Multidimensional Arrays: RM 3 6 2 11 Multidimensional Arrays. * RM 9.6(30-31); Duration’Small: RM 9 6 30-31 Duration’Small. * RM 10.2.1(12); Consistent Representation: RM 10 2 1 12 Consistent Representation. * RM 11.4.1(19); Exception Information: RM 11 4 1 19 Exception Information. * RM 11.5(28); Suppression of Checks: RM 11 5 28 Suppression of Checks. * RM 13.1 (21-24); Representation Clauses: RM 13 1 21-24 Representation Clauses. * RM 13.2(6-8); Packed Types: RM 13 2 6-8 Packed Types. * RM 13.3(14-19); Address Clauses: RM 13 3 14-19 Address Clauses. * RM 13.3(29-35); Alignment Clauses: RM 13 3 29-35 Alignment Clauses. * RM 13.3(42-43); Size Clauses: RM 13 3 42-43 Size Clauses. * RM 13.3(50-56); Size Clauses: RM 13 3 50-56 Size Clauses. * RM 13.3(71-73); Component Size Clauses: RM 13 3 71-73 Component Size Clauses. * RM 13.4(9-10); Enumeration Representation Clauses: RM 13 4 9-10 Enumeration Representation Clauses. * RM 13.5.1(17-22); Record Representation Clauses: RM 13 5 1 17-22 Record Representation Clauses. * RM 13.5.2(5); Storage Place Attributes: RM 13 5 2 5 Storage Place Attributes. * RM 13.5.3(7-8); Bit Ordering: RM 13 5 3 7-8 Bit Ordering. * RM 13.7(37); Address as Private: RM 13 7 37 Address as Private. * RM 13.7.1(16); Address Operations: RM 13 7 1 16 Address Operations. * RM 13.9(14-17); Unchecked Conversion: RM 13 9 14-17 Unchecked Conversion. * RM 13.11(23-25); Implicit Heap Usage: RM 13 11 23-25 Implicit Heap Usage. * RM 13.11.2(17); Unchecked Deallocation: RM 13 11 2 17 Unchecked Deallocation. * RM 13.13.2(1.6); Stream Oriented Attributes: RM 13 13 2 1 6 Stream Oriented Attributes. * RM A.1(52); Names of Predefined Numeric Types: RM A 1 52 Names of Predefined Numeric Types. * RM A.3.2(49); Ada.Characters.Handling: RM A 3 2 49 Ada Characters Handling. * RM A.4.4(106); Bounded-Length String Handling: RM A 4 4 106 Bounded-Length String Handling. * RM A.5.2(46-47); Random Number Generation: RM A 5 2 46-47 Random Number Generation. * RM A.10.7(23); Get_Immediate: RM A 10 7 23 Get_Immediate. * RM A.18; Containers: RM A 18 Containers. * RM B.1(39-41); Pragma Export: RM B 1 39-41 Pragma Export. * RM B.2(12-13); Package Interfaces: RM B 2 12-13 Package Interfaces. * RM B.3(63-71); Interfacing with C: RM B 3 63-71 Interfacing with C. * RM B.4(95-98); Interfacing with COBOL: RM B 4 95-98 Interfacing with COBOL. * RM B.5(22-26); Interfacing with Fortran: RM B 5 22-26 Interfacing with Fortran. * RM C.1(3-5); Access to Machine Operations: RM C 1 3-5 Access to Machine Operations. * RM C.1(10-16); Access to Machine Operations: RM C 1 10-16 Access to Machine Operations. * RM C.3(28); Interrupt Support: RM C 3 28 Interrupt Support. * RM C.3.1(20-21); Protected Procedure Handlers: RM C 3 1 20-21 Protected Procedure Handlers. * RM C.3.2(25); Package Interrupts: RM C 3 2 25 Package Interrupts. * RM C.4(14); Pre-elaboration Requirements: RM C 4 14 Pre-elaboration Requirements. * RM C.5(8); Pragma Discard_Names: RM C 5 8 Pragma Discard_Names. * RM C.7.2(30); The Package Task_Attributes: RM C 7 2 30 The Package Task_Attributes. * RM D.3(17); Locking Policies: RM D 3 17 Locking Policies. * RM D.4(16); Entry Queuing Policies: RM D 4 16 Entry Queuing Policies. * RM D.6(9-10); Preemptive Abort: RM D 6 9-10 Preemptive Abort. * RM D.7(21); Tasking Restrictions: RM D 7 21 Tasking Restrictions. * RM D.8(47-49); Monotonic Time: RM D 8 47-49 Monotonic Time. * RM E.5(28-29); Partition Communication Subsystem: RM E 5 28-29 Partition Communication Subsystem. * RM F(7); COBOL Support: RM F 7 COBOL Support. * RM F.1(2); Decimal Radix Support: RM F 1 2 Decimal Radix Support. * RM G; Numerics: RM G Numerics. * RM G.1.1(56-58); Complex Types: RM G 1 1 56-58 Complex Types. * RM G.1.2(49); Complex Elementary Functions: RM G 1 2 49 Complex Elementary Functions. * RM G.2.4(19); Accuracy Requirements: RM G 2 4 19 Accuracy Requirements. * RM G.2.6(15); Complex Arithmetic Accuracy: RM G 2 6 15 Complex Arithmetic Accuracy. * RM H.6(15/2); Pragma Partition_Elaboration_Policy: RM H 6 15/2 Pragma Partition_Elaboration_Policy.  File: gnat_rm.info, Node: RM 1 1 3 20 Error Detection, Next: RM 1 1 3 31 Child Units, Up: Implementation Advice 6.1 RM 1.1.3(20): Error Detection ================================= “If an implementation detects the use of an unsupported Specialized Needs Annex feature at run time, it should raise ‘Program_Error’ if feasible.” Not relevant. All specialized needs annex features are either supported, or diagnosed at compile time.  File: gnat_rm.info, Node: RM 1 1 3 31 Child Units, Next: RM 1 1 5 12 Bounded Errors, Prev: RM 1 1 3 20 Error Detection, Up: Implementation Advice 6.2 RM 1.1.3(31): Child Units ============================= “If an implementation wishes to provide implementation-defined extensions to the functionality of a language-defined library unit, it should normally do so by adding children to the library unit.” Followed.  File: gnat_rm.info, Node: RM 1 1 5 12 Bounded Errors, Next: RM 2 8 16 Pragmas, Prev: RM 1 1 3 31 Child Units, Up: Implementation Advice 6.3 RM 1.1.5(12): Bounded Errors ================================ “If an implementation detects a bounded error or erroneous execution, it should raise ‘Program_Error’.” Followed in all cases in which the implementation detects a bounded error or erroneous execution. Not all such situations are detected at runtime.  File: gnat_rm.info, Node: RM 2 8 16 Pragmas, Next: RM 2 8 17-19 Pragmas, Prev: RM 1 1 5 12 Bounded Errors, Up: Implementation Advice 6.4 RM 2.8(16): Pragmas ======================= “Normally, implementation-defined pragmas should have no semantic effect for error-free programs; that is, if the implementation-defined pragmas are removed from a working program, the program should still be legal, and should still have the same semantics.” The following implementation defined pragmas are exceptions to this rule: Pragma Explanation ------------------------------------------------- 'Abort_Defer' Affects semantics 'Ada_83' Affects legality 'Assert' Affects semantics 'CPP_Class' Affects semantics 'CPP_Constructor' Affects semantics 'Debug' Affects semantics 'Interface_Name' Affects semantics 'Machine_Attribute' Affects semantics 'Unimplemented_Unit' Affects legality 'Unchecked_Union' Affects semantics In each of the above cases, it is essential to the purpose of the pragma that this advice not be followed. For details see *note Implementation Defined Pragmas: 7.  File: gnat_rm.info, Node: RM 2 8 17-19 Pragmas, Next: RM 3 5 2 5 Alternative Character Sets, Prev: RM 2 8 16 Pragmas, Up: Implementation Advice 6.5 RM 2.8(17-19): Pragmas ========================== “Normally, an implementation should not define pragmas that can make an illegal program legal, except as follows: * A pragma used to complete a declaration, such as a pragma ‘Import’; * A pragma used to configure the environment by adding, removing, or replacing ‘library_items’.” See *note RM 2.8(16); Pragmas: 22b.  File: gnat_rm.info, Node: RM 3 5 2 5 Alternative Character Sets, Next: RM 3 5 4 28 Integer Types, Prev: RM 2 8 17-19 Pragmas, Up: Implementation Advice 6.6 RM 3.5.2(5): Alternative Character Sets =========================================== “If an implementation supports a mode with alternative interpretations for ‘Character’ and ‘Wide_Character’, the set of graphic characters of ‘Character’ should nevertheless remain a proper subset of the set of graphic characters of ‘Wide_Character’. Any character set ‘localizations’ should be reflected in the results of the subprograms defined in the language-defined package ‘Characters.Handling’ (see A.3) available in such a mode. In a mode with an alternative interpretation of ‘Character’, the implementation should also support a corresponding change in what is a legal ‘identifier_letter’.” Not all wide character modes follow this advice, in particular the JIS and IEC modes reflect standard usage in Japan, and in these encoding, the upper half of the Latin-1 set is not part of the wide-character subset, since the most significant bit is used for wide character encoding. However, this only applies to the external forms. Internally there is no such restriction.  File: gnat_rm.info, Node: RM 3 5 4 28 Integer Types, Next: RM 3 5 4 29 Integer Types, Prev: RM 3 5 2 5 Alternative Character Sets, Up: Implementation Advice 6.7 RM 3.5.4(28): Integer Types =============================== “An implementation should support ‘Long_Integer’ in addition to ‘Integer’ if the target machine supports 32-bit (or longer) arithmetic. No other named integer subtypes are recommended for package ‘Standard’. Instead, appropriate named integer subtypes should be provided in the library package ‘Interfaces’ (see B.2).” ‘Long_Integer’ is supported. Other standard integer types are supported so this advice is not fully followed. These types are supported for convenient interface to C, and so that all hardware types of the machine are easily available.  File: gnat_rm.info, Node: RM 3 5 4 29 Integer Types, Next: RM 3 5 5 8 Enumeration Values, Prev: RM 3 5 4 28 Integer Types, Up: Implementation Advice 6.8 RM 3.5.4(29): Integer Types =============================== “An implementation for a two’s complement machine should support modular types with a binary modulus up to ‘System.Max_Int*2+2’. An implementation should support a non-binary modules up to ‘Integer'Last’.” Followed.  File: gnat_rm.info, Node: RM 3 5 5 8 Enumeration Values, Next: RM 3 5 7 17 Float Types, Prev: RM 3 5 4 29 Integer Types, Up: Implementation Advice 6.9 RM 3.5.5(8): Enumeration Values =================================== “For the evaluation of a call on ‘S'Pos’ for an enumeration subtype, if the value of the operand does not correspond to the internal code for any enumeration literal of its type (perhaps due to an un-initialized variable), then the implementation should raise ‘Program_Error’. This is particularly important for enumeration types with noncontiguous internal codes specified by an enumeration_representation_clause.” Followed.  File: gnat_rm.info, Node: RM 3 5 7 17 Float Types, Next: RM 3 6 2 11 Multidimensional Arrays, Prev: RM 3 5 5 8 Enumeration Values, Up: Implementation Advice 6.10 RM 3.5.7(17): Float Types ============================== “An implementation should support ‘Long_Float’ in addition to ‘Float’ if the target machine supports 11 or more digits of precision. No other named floating point subtypes are recommended for package ‘Standard’. Instead, appropriate named floating point subtypes should be provided in the library package ‘Interfaces’ (see B.2).” ‘Short_Float’ and ‘Long_Long_Float’ are also provided. The former provides improved compatibility with other implementations supporting this type. The latter corresponds to the highest precision floating-point type supported by the hardware. On most machines, this will be the same as ‘Long_Float’, but on some machines, it will correspond to the IEEE extended form. The notable case is all x86 implementations, where ‘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.  File: gnat_rm.info, Node: RM 3 6 2 11 Multidimensional Arrays, Next: RM 9 6 30-31 Duration’Small, Prev: RM 3 5 7 17 Float Types, Up: Implementation Advice 6.11 RM 3.6.2(11): Multidimensional Arrays ========================================== “An implementation should normally represent multidimensional arrays in row-major order, consistent with the notation used for multidimensional array aggregates (see 4.3.3). However, if a pragma ‘Convention’ (‘Fortran’, …) applies to a multidimensional array type, then column-major order should be used instead (see B.5, 'Interfacing with Fortran').” Followed.  File: gnat_rm.info, Node: RM 9 6 30-31 Duration’Small, Next: RM 10 2 1 12 Consistent Representation, Prev: RM 3 6 2 11 Multidimensional Arrays, Up: Implementation Advice 6.12 RM 9.6(30-31): Duration’Small ================================== “Whenever possible in an implementation, the value of ‘Duration'Small’ should be no greater than 100 microseconds.” Followed. (‘Duration'Small’ = 10**(-9)). “The time base for ‘delay_relative_statements’ should be monotonic; it need not be the same time base as used for ‘Calendar.Clock’.” Followed.  File: gnat_rm.info, Node: RM 10 2 1 12 Consistent Representation, Next: RM 11 4 1 19 Exception Information, Prev: RM 9 6 30-31 Duration’Small, Up: Implementation Advice 6.13 RM 10.2.1(12): Consistent Representation ============================================= “In an implementation, a type declared in a pre-elaborated package should have the same representation in every elaboration of a given version of the package, whether the elaborations occur in distinct executions of the same program, or in executions of distinct programs or partitions that include the given version.” Followed, except in the case of tagged types. Tagged types involve implicit pointers to a local copy of a dispatch table, and these pointers have representations which thus depend on a particular elaboration of the package. It is not easy to see how it would be possible to follow this advice without severely impacting efficiency of execution.  File: gnat_rm.info, Node: RM 11 4 1 19 Exception Information, Next: RM 11 5 28 Suppression of Checks, Prev: RM 10 2 1 12 Consistent Representation, Up: Implementation Advice 6.14 RM 11.4.1(19): Exception Information ========================================= “‘Exception_Message’ by default and ‘Exception_Information’ should produce information useful for debugging. ‘Exception_Message’ should be short, about one line. ‘Exception_Information’ can be long. ‘Exception_Message’ should not include the ‘Exception_Name’. ‘Exception_Information’ should include both the ‘Exception_Name’ and the ‘Exception_Message’.” Followed. For each exception that doesn’t have a specified ‘Exception_Message’, the compiler generates one containing the location of the raise statement. This location has the form ‘file_name:line’, where file_name is the short file name (without path information) and line is the line number in the file. Note that in the case of the Zero Cost Exception mechanism, these messages become redundant with the Exception_Information that contains a full backtrace of the calling sequence, so they are disabled. To disable explicitly the generation of the source location message, use the Pragma ‘Discard_Names’.  File: gnat_rm.info, Node: RM 11 5 28 Suppression of Checks, Next: RM 13 1 21-24 Representation Clauses, Prev: RM 11 4 1 19 Exception Information, Up: Implementation Advice 6.15 RM 11.5(28): Suppression of Checks ======================================= “The implementation should minimize the code executed for checks that have been suppressed.” Followed.  File: gnat_rm.info, Node: RM 13 1 21-24 Representation Clauses, Next: RM 13 2 6-8 Packed Types, Prev: RM 11 5 28 Suppression of Checks, Up: Implementation Advice 6.16 RM 13.1 (21-24): Representation Clauses ============================================ “The recommended level of support for all representation items is qualified as follows: An implementation need not support representation items containing nonstatic expressions, except that an implementation should support a representation item for a given entity if each nonstatic expression in the representation item is a name that statically denotes a constant declared before the entity.” 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: X : Integer; Y : Float; for Y'Address use X'Address;>> "An implementation need not support a specification for the ``Size`` for a given composite subtype, nor the size or storage place for an object (including a component) of a given composite subtype, unless the constraints on the subtype and its composite subcomponents (if any) are all static constraints." Followed. Size Clauses are not permitted on nonstatic components, as described above. “An aliased component, or a component whose type is by-reference, should always be allocated at an addressable location.” Followed.  File: gnat_rm.info, Node: RM 13 2 6-8 Packed Types, Next: RM 13 3 14-19 Address Clauses, Prev: RM 13 1 21-24 Representation Clauses, Up: Implementation Advice 6.17 RM 13.2(6-8): Packed Types =============================== “If a type is packed, then the implementation should try to minimize storage allocated to objects of the type, possibly at the expense of speed of accessing components, subject to reasonable complexity in addressing calculations. The recommended level of support pragma ‘Pack’ is: For a packed record type, the components should be packed as tightly as possible subject to the Sizes of the component subtypes, and subject to any 'record_representation_clause' that applies to the type; the implementation may, but need not, reorder components or cross aligned word boundaries to improve the packing. A component whose ‘Size’ is greater than the word size may be allocated an integral number of words.” Followed. Tight packing of arrays is supported for all component sizes up to 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.  File: gnat_rm.info, Node: RM 13 3 14-19 Address Clauses, Next: RM 13 3 29-35 Alignment Clauses, Prev: RM 13 2 6-8 Packed Types, Up: Implementation Advice 6.18 RM 13.3(14-19): Address Clauses ==================================== “For an array ‘X’, ‘X'Address’ should point at the first component of the array, and not at the array bounds.” Followed. “The recommended level of support for the ‘Address’ attribute is: ‘X'Address’ should produce a useful result if ‘X’ is an object that is aliased or of a by-reference type, or is an entity whose ‘Address’ has been specified.” Followed. A valid address will be produced even if none of those conditions have been met. If necessary, the object is forced into memory to ensure the address is valid. “An implementation should support ‘Address’ clauses for imported subprograms.” Followed. “Objects (including subcomponents) that are aliased or of a by-reference type should be allocated on storage element boundaries.” Followed. “If the ‘Address’ of an object is specified, or it is imported or exported, then the implementation should not perform optimizations based on assumptions of no aliases.” Followed.  File: gnat_rm.info, Node: RM 13 3 29-35 Alignment Clauses, Next: RM 13 3 42-43 Size Clauses, Prev: RM 13 3 14-19 Address Clauses, Up: Implementation Advice 6.19 RM 13.3(29-35): Alignment Clauses ====================================== “The recommended level of support for the ‘Alignment’ attribute for subtypes is: An implementation should support specified Alignments that are factors and multiples of the number of storage elements per word, subject to the following:” Followed. “An implementation need not support specified Alignments for combinations of Sizes and Alignments that cannot be easily loaded and stored by available machine instructions.” Followed. “An implementation need not support specified Alignments that are greater than the maximum ‘Alignment’ the implementation ever returns by default.” Followed. “The recommended level of support for the ‘Alignment’ attribute for objects is: Same as above, for subtypes, but in addition:” Followed. “For stand-alone library-level objects of statically constrained subtypes, the implementation should support all alignments supported by the target linker. For example, page alignment is likely to be supported for such objects, but not for subtypes.” Followed.  File: gnat_rm.info, Node: RM 13 3 42-43 Size Clauses, Next: RM 13 3 50-56 Size Clauses, Prev: RM 13 3 29-35 Alignment Clauses, Up: Implementation Advice 6.20 RM 13.3(42-43): Size Clauses ================================= “The recommended level of support for the ‘Size’ attribute of objects is: A ‘Size’ clause should be supported for an object if the specified ‘Size’ is at least as large as its subtype’s ‘Size’, and corresponds to a size in storage elements that is a multiple of the object’s ‘Alignment’ (if the ‘Alignment’ is nonzero).” Followed.  File: gnat_rm.info, Node: RM 13 3 50-56 Size Clauses, Next: RM 13 3 71-73 Component Size Clauses, Prev: RM 13 3 42-43 Size Clauses, Up: Implementation Advice 6.21 RM 13.3(50-56): Size Clauses ================================= “If the ‘Size’ of a subtype is specified, and allows for efficient independent addressability (see 9.10) on the target architecture, then the ‘Size’ of the following objects of the subtype should equal the ‘Size’ of the subtype: Aliased objects (including components).” Followed. “‘Size’ clause on a composite subtype should not affect the internal layout of components.” Followed. But note that this can be overridden by use of the implementation pragma Implicit_Packing in the case of packed arrays. “The recommended level of support for the ‘Size’ attribute of subtypes is: The ‘Size’ (if not specified) of a static discrete or fixed point subtype should be the number of bits needed to represent each value belonging to the subtype using an unbiased representation, leaving space for a sign bit only if the subtype contains negative values. If such a subtype is a first subtype, then an implementation should support a specified ‘Size’ for it that reflects this representation.” Followed. “For a subtype implemented with levels of indirection, the ‘Size’ should include the size of the pointers, but not the size of what they point at.” Followed.  File: gnat_rm.info, Node: RM 13 3 71-73 Component Size Clauses, Next: RM 13 4 9-10 Enumeration Representation Clauses, Prev: RM 13 3 50-56 Size Clauses, Up: Implementation Advice 6.22 RM 13.3(71-73): Component Size Clauses =========================================== “The recommended level of support for the ‘Component_Size’ attribute is: An implementation need not support specified ‘Component_Sizes’ that are less than the ‘Size’ of the component subtype.” Followed. “An implementation should support specified Component_Sizes that are factors and multiples of the word size. For such Component_Sizes, the array should contain no gaps between components. For other Component_Sizes (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.” Followed.  File: gnat_rm.info, Node: RM 13 4 9-10 Enumeration Representation Clauses, Next: RM 13 5 1 17-22 Record Representation Clauses, Prev: RM 13 3 71-73 Component Size Clauses, Up: Implementation Advice 6.23 RM 13.4(9-10): Enumeration Representation Clauses ====================================================== “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 ‘System.Min_Int .. System.Max_Int’.” Followed.  File: gnat_rm.info, Node: RM 13 5 1 17-22 Record Representation Clauses, Next: RM 13 5 2 5 Storage Place Attributes, Prev: RM 13 4 9-10 Enumeration Representation Clauses, Up: Implementation Advice 6.24 RM 13.5.1(17-22): Record Representation Clauses ==================================================== “The recommended level of support for 'record_representation_clause's 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.” Followed. “A storage place should be supported if its size is equal to the ‘Size’ of the component subtype, and it starts and ends on a boundary that obeys the ‘Alignment’ of the component subtype.” Followed. “If the default bit ordering applies to the declaration of a given type, then for a component whose subtype’s ‘Size’ is less than the word size, any storage place that does not cross an aligned word boundary should be supported.” Followed. “An implementation may reserve a storage place for the tag field of a tagged type, and disallow other components from overlapping that place.” 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. “An implementation need not support a '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.” Followed. The above advice on record representation clauses is followed, and all mentioned features are implemented.  File: gnat_rm.info, Node: RM 13 5 2 5 Storage Place Attributes, Next: RM 13 5 3 7-8 Bit Ordering, Prev: RM 13 5 1 17-22 Record Representation Clauses, Up: Implementation Advice 6.25 RM 13.5.2(5): Storage Place Attributes =========================================== “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.” Followed. There are no such components in GNAT.  File: gnat_rm.info, Node: RM 13 5 3 7-8 Bit Ordering, Next: RM 13 7 37 Address as Private, Prev: RM 13 5 2 5 Storage Place Attributes, Up: Implementation Advice 6.26 RM 13.5.3(7-8): Bit Ordering ================================= “The recommended level of support for the non-default bit ordering is: If ‘Word_Size’ = ‘Storage_Unit’, then the implementation should support the non-default bit ordering in addition to the default bit ordering.” Followed. Word size does not equal storage size in this implementation. Thus non-default bit ordering is not supported.  File: gnat_rm.info, Node: RM 13 7 37 Address as Private, Next: RM 13 7 1 16 Address Operations, Prev: RM 13 5 3 7-8 Bit Ordering, Up: Implementation Advice 6.27 RM 13.7(37): Address as Private ==================================== “‘Address’ should be of a private type.” Followed.  File: gnat_rm.info, Node: RM 13 7 1 16 Address Operations, Next: RM 13 9 14-17 Unchecked Conversion, Prev: RM 13 7 37 Address as Private, Up: Implementation Advice 6.28 RM 13.7.1(16): Address Operations ====================================== “Operations in ‘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 ‘Program_Error’.” Followed. Address arithmetic is modular arithmetic that wraps around. No operation raises ‘Program_Error’, since all operations make sense.  File: gnat_rm.info, Node: RM 13 9 14-17 Unchecked Conversion, Next: RM 13 11 23-25 Implicit Heap Usage, Prev: RM 13 7 1 16 Address Operations, Up: Implementation Advice 6.29 RM 13.9(14-17): Unchecked Conversion ========================================= “The ‘Size’ of an array object should not include its bounds; hence, the bounds should not be part of the converted data.” Followed. “The implementation should not generate unnecessary run-time checks to ensure that the representation of ‘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.” 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. “The recommended level of support for unchecked conversions is: 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.” Followed.  File: gnat_rm.info, Node: RM 13 11 23-25 Implicit Heap Usage, Next: RM 13 11 2 17 Unchecked Deallocation, Prev: RM 13 9 14-17 Unchecked Conversion, Up: Implementation Advice 6.30 RM 13.11(23-25): Implicit Heap Usage ========================================= “An implementation should document any cases in which it dynamically allocates heap storage for a purpose other than the evaluation of an allocator.” Followed, the only other points at which heap storage is dynamically allocated are as follows: * At initial elaboration time, to allocate dynamically sized global objects. * To allocate space for a task when a task is created. * To extend the secondary stack dynamically when needed. The secondary stack is used for returning variable length results. “A default (implementation-provided) storage pool for an access-to-constant type should not have overhead to support deallocation of individual objects.” Followed. “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.” Followed.  File: gnat_rm.info, Node: RM 13 11 2 17 Unchecked Deallocation, Next: RM 13 13 2 1 6 Stream Oriented Attributes, Prev: RM 13 11 23-25 Implicit Heap Usage, Up: Implementation Advice 6.31 RM 13.11.2(17): Unchecked Deallocation =========================================== “For a standard storage pool, ‘Free’ should actually reclaim the storage.” Followed.  File: gnat_rm.info, Node: RM 13 13 2 1 6 Stream Oriented Attributes, Next: RM A 1 52 Names of Predefined Numeric Types, Prev: RM 13 11 2 17 Unchecked Deallocation, Up: Implementation Advice 6.32 RM 13.13.2(1.6): Stream Oriented Attributes ================================================ “If not specified, the value of Stream_Size for an elementary type should be the number of bits that corresponds to the minimum number of stream elements required by the first subtype of the type, rounded up to the nearest factor or multiple of the word size that is also a multiple of the stream element size.” Followed, except that the number of stream elements is 1, 2, 3, 4 or 8. The Stream_Size may be used to override the default choice. The default 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 ‘Read’ and ‘Write’, which uses the target-independent XDR standard representation for scalar types. This XDR alternative can be enabled via the binder switch -xdr.  File: gnat_rm.info, Node: RM A 1 52 Names of Predefined Numeric Types, Next: RM A 3 2 49 Ada Characters Handling, Prev: RM 13 13 2 1 6 Stream Oriented Attributes, Up: Implementation Advice 6.33 RM A.1(52): Names of Predefined Numeric Types ================================================== “If an implementation provides additional named predefined integer types, then the names should end with ‘Integer’ as in ‘Long_Integer’. If an implementation provides additional named predefined floating point types, then the names should end with ‘Float’ as in ‘Long_Float’.” Followed.  File: gnat_rm.info, Node: RM A 3 2 49 Ada Characters Handling, Next: RM A 4 4 106 Bounded-Length String Handling, Prev: RM A 1 52 Names of Predefined Numeric Types, Up: Implementation Advice 6.34 RM A.3.2(49): ‘Ada.Characters.Handling’ ============================================ “If an implementation provides a localized definition of ‘Character’ or ‘Wide_Character’, then the effects of the subprograms in ‘Characters.Handling’ should reflect the localizations. See also 3.5.2.” Followed. GNAT provides no such localized definitions.  File: gnat_rm.info, Node: RM A 4 4 106 Bounded-Length String Handling, Next: RM A 5 2 46-47 Random Number Generation, Prev: RM A 3 2 49 Ada Characters Handling, Up: Implementation Advice 6.35 RM A.4.4(106): Bounded-Length String Handling ================================================== “Bounded string objects should not be implemented by implicit pointers and dynamic allocation.” Followed. No implicit pointers or dynamic allocation are used.  File: gnat_rm.info, Node: RM A 5 2 46-47 Random Number Generation, Next: RM A 10 7 23 Get_Immediate, Prev: RM A 4 4 106 Bounded-Length String Handling, Up: Implementation Advice 6.36 RM A.5.2(46-47): Random Number Generation ============================================== “Any storage associated with an object of type ‘Generator’ should be reclaimed on exit from the scope of the object.” Followed. “If the generator period is sufficiently long in relation to the number of distinct initiator values, then each possible value of ‘Initiator’ passed to ‘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.” Followed. The generator period is sufficiently long for the first condition here to hold true.  File: gnat_rm.info, Node: RM A 10 7 23 Get_Immediate, Next: RM A 18 Containers, Prev: RM A 5 2 46-47 Random Number Generation, Up: Implementation Advice 6.37 RM A.10.7(23): ‘Get_Immediate’ =================================== “The ‘Get_Immediate’ procedures should be implemented with unbuffered input. For a device such as a keyboard, input should be 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 ‘Get_Immediate’.” 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 ‘Get_Immediate’ call. A special unit ‘Interfaces.Vxworks.IO’ is provided that contains routines to enable this functionality.  File: gnat_rm.info, Node: RM A 18 Containers, Next: RM B 1 39-41 Pragma Export, Prev: RM A 10 7 23 Get_Immediate, Up: Implementation Advice 6.38 RM A.18: ‘Containers’ ========================== All implementation advice pertaining to Ada.Containers and its child units (that is, all implementation advice occurring within section A.18 and its subsections) is followed except for A.18.24(17): “Bounded ordered set objects should be implemented without implicit pointers or dynamic allocation. “ The implementations of the two Reference_Preserving_Key functions of the generic package Ada.Containers.Bounded_Ordered_Sets each currently make use of dynamic allocation; other operations on bounded ordered set objects follow the implementation advice.  File: gnat_rm.info, Node: RM B 1 39-41 Pragma Export, Next: RM B 2 12-13 Package Interfaces, Prev: RM A 18 Containers, Up: Implementation Advice 6.39 RM B.1(39-41): Pragma ‘Export’ =================================== “If an implementation supports pragma ‘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 ‘adainit’ and ‘adafinal’. ‘adainit’ should contain the elaboration code for library units. ‘adafinal’ should contain the finalization code. These subprograms should have no effect the second and subsequent time they are called.” Followed. “Automatic elaboration of pre-elaborated packages should be provided when pragma ‘Export’ is supported.” Followed when the main program is in Ada. If the main program is in a foreign language, then ‘adainit’ must be called to elaborate pre-elaborated packages. “For each supported convention 'L' other than ‘Intrinsic’, an implementation should support ‘Import’ and ‘Export’ pragmas for objects of 'L'-compatible types and for subprograms, and pragma ‘Convention’ for 'L'-eligible types and for subprograms, presuming the other language has corresponding features. Pragma ‘Convention’ need not be supported for scalar types.” Followed.  File: gnat_rm.info, Node: RM B 2 12-13 Package Interfaces, Next: RM B 3 63-71 Interfacing with C, Prev: RM B 1 39-41 Pragma Export, Up: Implementation Advice 6.40 RM B.2(12-13): Package ‘Interfaces’ ======================================== “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 ‘Interfaces’.” Followed. “An implementation supporting an interface to C, COBOL, or Fortran should provide the corresponding package or packages described in the following clauses.” Followed. GNAT provides all the packages described in this section.  File: gnat_rm.info, Node: RM B 3 63-71 Interfacing with C, Next: RM B 4 95-98 Interfacing with COBOL, Prev: RM B 2 12-13 Package Interfaces, Up: Implementation Advice 6.41 RM B.3(63-71): Interfacing with C ====================================== “An implementation should support the following interface correspondences between Ada and C.” Followed. “An Ada procedure corresponds to a void-returning C function.” Followed. “An Ada function corresponds to a non-void C function.” Followed. “An Ada ‘in’ scalar parameter is passed as a scalar argument to a C function.” Followed. “An Ada ‘in’ parameter of an access-to-object type with designated type ‘T’ is passed as a ‘t*’ argument to a C function, where ‘t’ is the C type corresponding to the Ada type ‘T’.” Followed. “An Ada access ‘T’ parameter, or an Ada ‘out’ or ‘in out’ parameter of an elementary type ‘T’, is passed as a ‘t*’ argument to a C function, where ‘t’ is the C type corresponding to the Ada type ‘T’. In the case of an elementary ‘out’ or ‘in out’ parameter, a pointer to a temporary copy is used to preserve by-copy semantics.” Followed. “An Ada parameter of a record type ‘T’, of any mode, is passed as a ‘t*’ argument to a C function, where ‘t’ is the C structure corresponding to the Ada type ‘T’.” 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. “An Ada parameter of an array type with component type ‘T’, of any mode, is passed as a ‘t*’ argument to a C function, where ‘t’ is the C type corresponding to the Ada type ‘T’.” Followed. “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.” Followed.  File: gnat_rm.info, Node: RM B 4 95-98 Interfacing with COBOL, Next: RM B 5 22-26 Interfacing with Fortran, Prev: RM B 3 63-71 Interfacing with C, Up: Implementation Advice 6.42 RM B.4(95-98): Interfacing with COBOL ========================================== “An Ada implementation should support the following interface correspondences between Ada and COBOL.” Followed. “An Ada access ‘T’ parameter is passed as a ‘BY REFERENCE’ data item of the COBOL type corresponding to ‘T’.” Followed. “An Ada in scalar parameter is passed as a ‘BY CONTENT’ data item of the corresponding COBOL type.” Followed. “Any other Ada parameter is passed as a ‘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.” Followed.  File: gnat_rm.info, Node: RM B 5 22-26 Interfacing with Fortran, Next: RM C 1 3-5 Access to Machine Operations, Prev: RM B 4 95-98 Interfacing with COBOL, Up: Implementation Advice 6.43 RM B.5(22-26): Interfacing with Fortran ============================================ “An Ada implementation should support the following interface correspondences between Ada and Fortran:” Followed. “An Ada procedure corresponds to a Fortran subroutine.” Followed. “An Ada function corresponds to a Fortran function.” Followed. “An Ada parameter of an elementary, array, or record type ‘T’ is passed as a ‘T’ argument to a Fortran procedure, where ‘T’ is the Fortran type corresponding to the Ada type ‘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.” Followed. “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.” Followed.  File: gnat_rm.info, Node: RM C 1 3-5 Access to Machine Operations, Next: RM C 1 10-16 Access to Machine Operations, Prev: RM B 5 22-26 Interfacing with Fortran, Up: Implementation Advice 6.44 RM C.1(3-5): Access to Machine Operations ============================================== “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.” Followed. “The interfacing pragmas (see Annex B) should support interface to assembler; the default assembler should be associated with the convention identifier ‘Assembler’.” Followed. “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.” Followed.  File: gnat_rm.info, Node: RM C 1 10-16 Access to Machine Operations, Next: RM C 3 28 Interrupt Support, Prev: RM C 1 3-5 Access to Machine Operations, Up: Implementation Advice 6.45 RM C.1(10-16): Access to Machine Operations ================================================ “The implementation should ensure that little or no overhead is associated with calling intrinsic and machine-code subprograms.” Followed for both intrinsics and machine-code subprograms. “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.” Followed. A full set of machine operation intrinsic subprograms is provided. “Atomic read-modify-write operations—e.g., test and set, compare and swap, decrement and test, enqueue/dequeue.” Followed on any target supporting such operations. “Standard numeric functions—e.g.:, sin, log.” Followed on any target supporting such operations. “String manipulation operations—e.g.:, translate and test.” Followed on any target supporting such operations. “Vector operations—e.g.:, compare vector against thresholds.” Followed on any target supporting such operations. “Direct operations on I/O ports.” Followed on any target supporting such operations.  File: gnat_rm.info, Node: RM C 3 28 Interrupt Support, Next: RM C 3 1 20-21 Protected Procedure Handlers, Prev: RM C 1 10-16 Access to Machine Operations, Up: Implementation Advice 6.46 RM C.3(28): Interrupt Support ================================== “If the ‘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.” Followed. The underlying system does not allow for finer-grain control of interrupt blocking.  File: gnat_rm.info, Node: RM C 3 1 20-21 Protected Procedure Handlers, Next: RM C 3 2 25 Package Interrupts, Prev: RM C 3 28 Interrupt Support, Up: Implementation Advice 6.47 RM C.3.1(20-21): Protected Procedure Handlers ================================================== “Whenever possible, the implementation should allow interrupt handlers to be called directly by the hardware.” Followed on any target where the underlying operating system permits such direct calls. “Whenever practical, violations of any implementation-defined restrictions should be detected before run time.” Followed. Compile time warnings are given when possible.  File: gnat_rm.info, Node: RM C 3 2 25 Package Interrupts, Next: RM C 4 14 Pre-elaboration Requirements, Prev: RM C 3 1 20-21 Protected Procedure Handlers, Up: Implementation Advice 6.48 RM C.3.2(25): Package ‘Interrupts’ ======================================= “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 ‘Parameterless_Handler’ should be specified in a child package of ‘Interrupts’, with the same operations as in the predefined package Interrupts.” Followed.  File: gnat_rm.info, Node: RM C 4 14 Pre-elaboration Requirements, Next: RM C 5 8 Pragma Discard_Names, Prev: RM C 3 2 25 Package Interrupts, Up: Implementation Advice 6.49 RM C.4(14): Pre-elaboration Requirements ============================================= “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.” Followed. Executable code is generated in some cases, e.g., loops to initialize large arrays.  File: gnat_rm.info, Node: RM C 5 8 Pragma Discard_Names, Next: RM C 7 2 30 The Package Task_Attributes, Prev: RM C 4 14 Pre-elaboration Requirements, Up: Implementation Advice 6.50 RM C.5(8): Pragma ‘Discard_Names’ ====================================== “If the pragma applies to an entity, then the implementation should reduce the amount of storage used for storing names associated with that entity.” Followed.  File: gnat_rm.info, Node: RM C 7 2 30 The Package Task_Attributes, Next: RM D 3 17 Locking Policies, Prev: RM C 5 8 Pragma Discard_Names, Up: Implementation Advice 6.51 RM C.7.2(30): The Package Task_Attributes ============================================== “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 ‘N’ attribute objects, and the heap for the others. In the latter case, ‘N’ should be documented.” Not followed. This implementation is not targeted to such a domain.  File: gnat_rm.info, Node: RM D 3 17 Locking Policies, Next: RM D 4 16 Entry Queuing Policies, Prev: RM C 7 2 30 The Package Task_Attributes, Up: Implementation Advice 6.52 RM D.3(17): Locking Policies ================================= “The implementation should use names that end with ‘_Locking’ for locking policies defined by the implementation.” Followed. Two implementation-defined locking policies are defined, whose names (‘Inheritance_Locking’ and ‘Concurrent_Readers_Locking’) follow this suggestion.  File: gnat_rm.info, Node: RM D 4 16 Entry Queuing Policies, Next: RM D 6 9-10 Preemptive Abort, Prev: RM D 3 17 Locking Policies, Up: Implementation Advice 6.53 RM D.4(16): Entry Queuing Policies ======================================= “Names that end with ‘_Queuing’ should be used for all implementation-defined queuing policies.” Followed. No such implementation-defined queuing policies exist.  File: gnat_rm.info, Node: RM D 6 9-10 Preemptive Abort, Next: RM D 7 21 Tasking Restrictions, Prev: RM D 4 16 Entry Queuing Policies, Up: Implementation Advice 6.54 RM D.6(9-10): Preemptive Abort =================================== “Even though the '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 'abort_statement' to block.” Followed. “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.” Followed.  File: gnat_rm.info, Node: RM D 7 21 Tasking Restrictions, Next: RM D 8 47-49 Monotonic Time, Prev: RM D 6 9-10 Preemptive Abort, Up: Implementation Advice 6.55 RM D.7(21): Tasking Restrictions ===================================== “When feasible, the implementation should take advantage of the specified restrictions to produce a more efficient implementation.” 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 ‘Profile (Ravenscar)’ and pragma ‘Profile (Restricted)’ for more details.  File: gnat_rm.info, Node: RM D 8 47-49 Monotonic Time, Next: RM E 5 28-29 Partition Communication Subsystem, Prev: RM D 7 21 Tasking Restrictions, Up: Implementation Advice 6.56 RM D.8(47-49): Monotonic Time ================================== “When appropriate, implementations should provide configuration mechanisms to change the value of ‘Tick’.” Such configuration mechanisms are not appropriate to this implementation and are thus not supported. “It is recommended that ‘Calendar.Clock’ and ‘Real_Time.Clock’ be implemented as transformations of the same time base.” Followed. “It is recommended that the best time base which exists in the underlying system be available to the application through ‘Clock’. ‘Best’ may mean highest accuracy or largest range.” Followed.  File: gnat_rm.info, Node: RM E 5 28-29 Partition Communication Subsystem, Next: RM F 7 COBOL Support, Prev: RM D 8 47-49 Monotonic Time, Up: Implementation Advice 6.57 RM E.5(28-29): Partition Communication Subsystem ===================================================== “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.” Followed by GLADE, a separately supplied PCS that can be used with GNAT. “The ‘Write’ operation on a stream of type ‘Params_Stream_Type’ should raise ‘Storage_Error’ if it runs out of space trying to write the ‘Item’ into the stream.” Followed by GLADE, a separately supplied PCS that can be used with GNAT.  File: gnat_rm.info, Node: RM F 7 COBOL Support, Next: RM F 1 2 Decimal Radix Support, Prev: RM E 5 28-29 Partition Communication Subsystem, Up: Implementation Advice 6.58 RM F(7): COBOL Support =========================== “If COBOL (respectively, C) is widely supported in the target environment, implementations supporting the Information Systems Annex should provide the child package ‘Interfaces.COBOL’ (respectively, ‘Interfaces.C’) specified in Annex B and should support a ‘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.” Followed.  File: gnat_rm.info, Node: RM F 1 2 Decimal Radix Support, Next: RM G Numerics, Prev: RM F 7 COBOL Support, Up: Implementation Advice 6.59 RM F.1(2): Decimal Radix Support ===================================== “Packed decimal should be used as the internal representation for objects of subtype ‘S’ when ‘S’’Machine_Radix = 10.” Not followed. GNAT ignores ‘S’’Machine_Radix and always uses binary representations.  File: gnat_rm.info, Node: RM G Numerics, Next: RM G 1 1 56-58 Complex Types, Prev: RM F 1 2 Decimal Radix Support, Up: Implementation Advice 6.60 RM G: Numerics =================== “If Fortran (respectively, C) is widely supported in the target environment, implementations supporting the Numerics Annex should provide the child package ‘Interfaces.Fortran’ (respectively, ‘Interfaces.C’) specified in Annex B and should support a ‘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.” Followed.  File: gnat_rm.info, Node: RM G 1 1 56-58 Complex Types, Next: RM G 1 2 49 Complex Elementary Functions, Prev: RM G Numerics, Up: Implementation Advice 6.61 RM G.1.1(56-58): Complex Types =================================== “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.” Not followed. “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 ‘Signed_Zeros’ attribute of the component type is ‘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.” Not followed. “Implementations in which ‘Real'Signed_Zeros’ is ‘True’ should attempt to provide a rational treatment of the signs of zero results and result components. As one example, the result of the ‘Argument’ function should have the sign of the imaginary component of the parameter ‘X’ when the point represented by that parameter lies on the positive real axis; as another, the sign of the imaginary component of the ‘Compose_From_Polar’ function should be the same as (respectively, the opposite of) that of the ‘Argument’ parameter when that parameter has a value of zero and the ‘Modulus’ parameter has a nonnegative (respectively, negative) value.” Followed.  File: gnat_rm.info, Node: RM G 1 2 49 Complex Elementary Functions, Next: RM G 2 4 19 Accuracy Requirements, Prev: RM G 1 1 56-58 Complex Types, Up: Implementation Advice 6.62 RM G.1.2(49): Complex Elementary Functions =============================================== “Implementations in which ‘Complex_Types.Real'Signed_Zeros’ is ‘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.” Followed.  File: gnat_rm.info, Node: RM G 2 4 19 Accuracy Requirements, Next: RM G 2 6 15 Complex Arithmetic Accuracy, Prev: RM G 1 2 49 Complex Elementary Functions, Up: Implementation Advice 6.63 RM G.2.4(19): Accuracy Requirements ======================================== “The versions of the forward trigonometric functions without a ‘Cycle’ parameter should not be implemented by calling the corresponding version with a ‘Cycle’ parameter of ‘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 ‘Log’ without a ‘Base’ parameter should not be implemented by calling the corresponding version with a ‘Base’ parameter of ‘Numerics.e’.” Followed.  File: gnat_rm.info, Node: RM G 2 6 15 Complex Arithmetic Accuracy, Next: RM H 6 15/2 Pragma Partition_Elaboration_Policy, Prev: RM G 2 4 19 Accuracy Requirements, Up: Implementation Advice 6.64 RM G.2.6(15): Complex Arithmetic Accuracy ============================================== “The version of the ‘Compose_From_Polar’ function without a ‘Cycle’ parameter should not be implemented by calling the corresponding version with a ‘Cycle’ parameter of ‘2.0*Numerics.Pi’, since this will not provide the required accuracy in some portions of the domain.” Followed.  File: gnat_rm.info, Node: RM H 6 15/2 Pragma Partition_Elaboration_Policy, Prev: RM G 2 6 15 Complex Arithmetic Accuracy, Up: Implementation Advice 6.65 RM H.6(15/2): Pragma Partition_Elaboration_Policy ====================================================== “If the partition elaboration policy is ‘Sequential’ and the Environment task becomes permanently blocked during elaboration then the partition is deadlocked and it is recommended that the partition be immediately terminated.” Not followed.  File: gnat_rm.info, Node: Implementation Defined Characteristics, Next: Intrinsic Subprograms, Prev: Implementation Advice, Up: Top 7 Implementation Defined Characteristics **************************************** In addition to the implementation dependent pragmas and attributes, and the implementation advice, there are a number of other Ada features that are potentially implementation dependent 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 of how GNAT handles the implementation dependence. You can use this chapter as a guide to minimizing implementation dependent features in your programs if portability to other compilers and other operating systems is an important consideration. The numbers in each entry below correspond to the paragraph numbers in the Ada Reference Manual. * “Whether or not each recommendation given in Implementation Advice is followed. See 1.1.2(37).” See *note Implementation Advice: a. * “Capacity limitations of the implementation. See 1.1.3(3).” The complexity of programs that can be processed is limited only by the total amount of available virtual memory, and disk space for the generated object files. * “Variations from the standard that are impractical to avoid given the implementation’s execution environment. See 1.1.3(6).” There are no variations from the standard. * “Which code_statements cause external interactions. See 1.1.3(10).” Any 'code_statement' can potentially cause external interactions. * “The coded representation for the text of an Ada program. See 2.1(4).” See separate section on source representation. * “The semantics of an Ada program whose text is not in Normalization Form C. See 2.1(4).” See separate section on source representation. * “The representation for an end of line. See 2.2(2).” See separate section on source representation. * “Maximum supported line length and lexical element length. See 2.2(15).” The maximum line length is 255 characters and the maximum length of a lexical element is also 255 characters. This is the default setting if not overridden by the use of compiler switch '-gnaty' (which sets the maximum to 79) or '-gnatyMnn' which allows the maximum line length to be specified to be any value up to 32767. The maximum length of a lexical element is the same as the maximum line length. * “Implementation defined pragmas. See 2.8(14).” See *note Implementation Defined Pragmas: 7. * “Effect of pragma ‘Optimize’. See 2.8(27).” Pragma ‘Optimize’, if given with a ‘Time’ or ‘Space’ parameter, checks that the optimization flag is set, and aborts if it is not. * “The message string associated with the Assertion_Error exception raised by the failure of a predicate check if there is no applicable Predicate_Failure aspect. See 3.2.4(31).” In the case of a Dynamic_Predicate aspect, the string is “Dynamic_Predicate failed at ”, where “” might be something like “foo.adb:123”. The Static_Predicate case is handled analogously. * “The predefined integer types declared in ‘Standard’. See 3.5.4(25).” Type Representation -------------------------------------------------------------------------- 'Short_Short_Integer' 8-bit signed 'Short_Integer' 16-bit signed 'Integer' 32-bit signed 'Long_Integer' 64-bit signed (on most 64-bit targets, depending on the C definition of long) 32-bit signed (on all other targets) 'Long_Long_Integer' 64-bit signed 'Long_Long_Long_Integer' 128-bit signed (on 64-bit targets) 64-bit signed (on 32-bit targets) * “Any nonstandard integer types and the operators defined for them. See 3.5.4(26).” There are no nonstandard integer types. * “Any nonstandard real types and the operators defined for them. See 3.5.6(8).” There are no nonstandard real types. * “What combinations of requested decimal precision and range are supported for floating point types. See 3.5.7(7).” The precision and range are defined by the IEEE Standard for Floating-Point Arithmetic (IEEE 754-2019). * “The predefined floating point types declared in ‘Standard’. See 3.5.7(16).” Type Representation ------------------------------------------------------------------------------- 'Short_Float' IEEE Binary32 (Single) 'Float' IEEE Binary32 (Single) 'Long_Float' IEEE Binary64 (Double) 'Long_Long_Float' IEEE Binary64 (Double) on non-x86 architectures IEEE 80-bit Extended on x86 architecture The default rounding mode specified by the IEEE 754 Standard is assumed both for static and dynamic computations (that is, round to nearest, ties to even). The input routines yield correctly rounded values for Short_Float, Float, and Long_Float at least. The output routines can compute up to twice as many exact digits as the value of ‘T'Digits’ for any type, for example 30 digits for Long_Float; if more digits are requested, zeros are printed. * “The small of an ordinary fixed point type. See 3.5.9(8).” The small is the largest power of two that does not exceed the delta. * “What combinations of small, range, and digits are supported for fixed point types. See 3.5.9(10).” For an ordinary fixed point type, on 32-bit platforms, the small must lie in 2.0**(-80) .. 2.0**80 and the range in -9.0E+36 .. 9.0E+36; any combination is permitted that does not result in a mantissa larger than 63 bits. On 64-bit platforms, the small must lie in 2.0**(-127) .. 2.0**127 and the range in -1.0E+76 .. 1.0E+76; any combination is permitted that does not result in a mantissa larger than 63 bits, and any combination is permitted that results in a mantissa between 64 and 127 bits if the small is the ratio of two integers that lie in 1 .. 2.0**127. If the small is the ratio of two integers with 64-bit magnitude on 32-bit platforms and 128-bit magnitude on 64-bit platforms, which is the case if no ‘small’ clause is provided, then the operations of the fixed point type are entirely implemented by means of integer instructions. In the other cases, some operations, in particular input and output, may be implemented by means of floating-point instructions and may be affected by accuracy issues on architectures other than x86. For a decimal fixed point type, on 32-bit platforms, the small must lie in 1.0E-18 .. 1.0E+18 and the digits in 1 .. 18. On 64-bit platforms, the small must lie in 1.0E-38 .. 1.0E+38 and the digits in 1 .. 38. * “The result of ‘Tags.Expanded_Name’ for types declared within an unnamed 'block_statement'. See 3.9(10).” Block numbers of the form ‘BNNN’, where 'nnn' is a decimal integer are allocated. * “The sequence of characters of the value returned by Tags.Expanded_Name (respectively, Tags.Wide_Expanded_Name) when some of the graphic characters of Tags.Wide_Wide_Expanded_Name are not defined in Character (respectively, Wide_Character). See 3.9(10.1).” This is handled in the same way as the implementation-defined behavior referenced in A.4.12(34). * “Implementation-defined attributes. See 4.1.4(12).” See *note Implementation Defined Attributes: 8. * “The value of the parameter to Empty for some container aggregates. See 4.3.5(40).” As per the suggestion given in the Annotated Ada RM, the default value of the formal parameter is used if one exists and zero is used otherwise. * “The maximum number of chunks for a parallel reduction expression without a chunk_specification. See 4.5.10(21).” Feature unimplemented. * “Rounding of real static expressions which are exactly half-way between two machine numbers. See 4.9(38).” Round to even is used in all such cases. * “The maximum number of chunks for a parallel generalized iterator without a chunk_specification. See 5.5.2(10).” Feature unimplemented. * “The number of chunks for an array component iterator. See 5.5.2(11).” Feature unimplemented. * “Any extensions of the Global aspect. See 6.1.2(43).” Feature unimplemented. * “The circumstances the implementation passes in the null value for a view conversion of an access type used as an out parameter. See 6.4.1(19).” Difficult to characterize. * “Any extensions of the Default_Initial_Condition aspect. See 7.3.3(11).” SPARK allows specifying 'null' as the Default_Initial_Condition aspect of a type. See the SPARK reference manual for further details. * “Any implementation-defined time types. See 9.6(6).” There are no implementation-defined time types. * “The time base associated with relative delays. See 9.6(20).” See 9.6(20). The time base used is that provided by the C library function ‘gettimeofday’. * “The time base of the type ‘Calendar.Time’. See 9.6(23).” The time base used is that provided by the C library function ‘gettimeofday’. * “The time zone used for package ‘Calendar’ operations. See 9.6(24).” The time zone used by package ‘Calendar’ is the current system time zone setting for local time, as accessed by the C library function ‘localtime’. * “Any limit on 'delay_until_statements' of 'select_statements'. See 9.6(29).” There are no such limits. * “The result of Calendar.Formatting.Image if its argument represents more than 100 hours. See 9.6.1(86).” Calendar.Time_Error is raised. * “Implementation-defined conflict check policies. See 9.10.1(5).” There are no implementation-defined conflict check policies. * “The representation for a compilation. See 10.1(2).” A compilation is represented by a sequence of files presented to the compiler in a single invocation of the 'gcc' command. * “Any restrictions on compilations that contain multiple compilation_units. See 10.1(4).” No single file can contain more than one compilation unit, but any sequence of files can be presented to the compiler as a single compilation. * “The mechanisms for creating an environment and for adding and replacing compilation units. See 10.1.4(3).” See separate section on compilation model. * “The manner of explicitly assigning library units to a partition. See 10.2(2).” If a unit contains an Ada main program, then the Ada units for the partition are determined by recursive application of the rules in the Ada Reference Manual section 10.2(2-6). In other words, the Ada units will be those that are needed by the main program, and then this definition of need is applied recursively to those units, and the partition contains the transitive closure determined by this relationship. In short, all the necessary units are included, with no need to explicitly specify the list. If additional units are required, e.g., by foreign language units, then all units must be mentioned in the context clause of one of the needed Ada units. If the partition contains no main program, or if the main program is in a language other than Ada, then GNAT provides the binder options '-z' and '-n' respectively, and in this case a list of units can be explicitly supplied to the binder for inclusion in the partition (all units needed by these units will also be included automatically). For full details on the use of these options, refer to 'GNAT Make Program gnatmake' in the ‘GNAT User’s Guide’. * “The implementation-defined means, if any, of specifying which compilation units are needed by a given compilation unit. See 10.2(2).” The units needed by a given compilation unit are as defined in the Ada Reference Manual section 10.2(2-6). There are no implementation-defined pragmas or other implementation-defined means for specifying needed units. * “The manner of designating the main subprogram of a partition. See 10.2(7).” The main program is designated by providing the name of the corresponding ‘ALI’ file as the input parameter to the binder. * “The order of elaboration of 'library_items'. See 10.2(18).” The first constraint on ordering is that it meets the requirements of Chapter 10 of the Ada Reference Manual. This still leaves some implementation-dependent choices, which are resolved by analyzing the elaboration code of each unit and identifying implicit elaboration-order dependencies. * “Parameter passing and function return for the main subprogram. See 10.2(21).” The main program has no parameters. It may be a procedure, or a function returning an integer type. In the latter case, the returned integer value is the return code of the program (overriding any value that may have been set by a call to ‘Ada.Command_Line.Set_Exit_Status’). * “The mechanisms for building and running partitions. See 10.2(24).” GNAT itself supports programs with only a single partition. The GNATDIST tool provided with the GLADE package (which also includes an implementation of the PCS) provides a completely flexible method for building and running programs consisting of multiple partitions. See the separate GLADE manual for details. * “The details of program execution, including program termination. See 10.2(25).” See separate section on compilation model. * “The semantics of any non-active partitions supported by the implementation. See 10.2(28).” Passive partitions are supported on targets where shared memory is provided by the operating system. See the GLADE reference manual for further details. * “The information returned by ‘Exception_Message’. See 11.4.1(10).” Exception message returns the null string unless a specific message has been passed by the program. * “The result of ‘Exceptions.Exception_Name’ for types declared within an unnamed 'block_statement'. See 11.4.1(12).” Blocks have implementation defined names of the form ‘BNNN’ where 'nnn' is an integer. * “The information returned by ‘Exception_Information’. See 11.4.1(13).” ‘Exception_Information’ returns a string in the following format: *Exception_Name:* nnnnn *Message:* mmmmm *PID:* ppp *Load address:* 0xhhhh *Call stack traceback locations:* 0xhhhh 0xhhhh 0xhhhh ... 0xhhh where * ‘nnnn’ is the fully qualified name of the exception in all upper case letters. This line is always present. * ‘mmmm’ is the message (this line present only if message is non-null) * ‘ppp’ is the Process Id value as a decimal integer (this line is present only if the Process Id is nonzero). Currently we are not making use of this field. * The Load address line, the Call stack traceback locations line and the following values are present only if at least one traceback location was recorded. The Load address indicates the address at which the main executable was loaded; this line may not be present if operating system hasn’t relocated the main executable. The values are given in C style format, with lower case letters for a-f, and only as many digits present as are necessary. The line terminator sequence at the end of each line, including the last line is a single ‘LF’ character (‘16#0A#’). * “The sequence of characters of the value returned by Exceptions.Exception_Name (respectively, Exceptions.Wide_Exception_Name) when some of the graphic characters of Exceptions.Wide_Wide_Exception_Name are not defined in Character (respectively, Wide_Character). See 11.4.1(12.1).” This is handled in the same way as the implementation-defined behavior referenced in A.4.12(34). * “The information returned by Exception_Information. See 11.4.1(13).” The exception name and the source location at which the exception was raised are included. * “Implementation-defined policy_identifiers and assertion_aspect_marks allowed in a pragma Assertion_Policy. See 11.4.2(9).” Implementation-defined assertion_aspect_marks include Assert_And_Cut, Assume, Contract_Cases, Debug, Ghost, Initial_Condition, Loop_Invariant, Loop_Variant, Postcondition, Precondition, Predicate, Refined_Post, Statement_Assertions, and Subprogram_Variant. Implementation-defined policy_identifiers include Ignore and Suppressible. * “The default assertion policy. See 11.4.2(10).” The default assertion policy is Ignore, although this can be overridden via compiler switches such as “-gnata”. * “Implementation-defined check names. See 11.5(27).” The implementation defined check names include Alignment_Check, Atomic_Synchronization, Duplicated_Tag_Check, Container_Checks, Tampering_Check, Predicate_Check, and Validity_Check. In addition, a user program can add implementation-defined check names by means of the pragma Check_Name. See the description of pragma ‘Suppress’ for full details. * “Existence and meaning of second parameter of pragma Unsuppress. See 11.5(27.1).” The legality rules for and semantics of the second parameter of pragma Unsuppress match those for the second argument of pragma Suppress. * “The cases that cause conflicts between the representation of the ancestors of a type_declaration. See 13.1(13.1).” No such cases exist. * “The interpretation of each representation aspect. See 13.1(20).” See separate section on data representations. * “Any restrictions placed upon the specification of representation aspects. See 13.1(20).” See separate section on data representations. * “Implementation-defined aspects, including the syntax for specifying such aspects and the legality rules for such aspects. See 13.1.1(38).” See *note Implementation Defined Aspects: 128. * “The set of machine scalars. See 13.3(8.1).” See separate section on data representations. * “The meaning of ‘Size’ for indefinite subtypes. See 13.3(48).” The Size attribute of an indefinite subtype is not less than the Size attribute of any object of that type. * “The meaning of Object_Size for indefinite subtypes. See 13.3(58).” The Object_Size attribute of an indefinite subtype is not less than the Object_Size attribute of any object of that type. * “The default external representation for a type tag. See 13.3(75).” The default external representation for a type tag is the fully expanded name of the type in upper case letters. * “What determines whether a compilation unit is the same in two different partitions. See 13.3(76).” A compilation unit is the same in two different partitions if and only if it derives from the same source file. * “Implementation-defined components. See 13.5.1(15).” The only implementation defined component is the tag for a tagged type, which contains a pointer to the dispatching table. * “If ‘Word_Size’ = ‘Storage_Unit’, the default bit ordering. See 13.5.3(5).” ‘Word_Size’ (32) is not the same as ‘Storage_Unit’ (8) for this implementation, so no non-default bit ordering is supported. The default bit ordering corresponds to the natural endianness of the target architecture. * “The contents of the visible part of package ‘System’. See 13.7(2).” See the definition of package System in ‘system.ads’. Note that two declarations are added to package System. Max_Priority : constant Positive := Priority'Last; Max_Interrupt_Priority : constant Positive := Interrupt_Priority'Last; * “The range of Storage_Elements.Storage_Offset, the modulus of Storage_Elements.Storage_Element, and the declaration of Storage_Elements.Integer_Address. See 13.7.1(11).” See the definition of package System.Storage_Elements in ‘s-stoele.ads’. * “The contents of the visible part of package ‘System.Machine_Code’, and the meaning of 'code_statements'. See 13.8(7).” See the definition and documentation in file ‘s-maccod.ads’. * “The result of unchecked conversion for instances with scalar result types whose result is not defined by the language. See 13.9(11).” Unchecked conversion between types of the same size results in an uninterpreted transmission of the bits from one type to the other. If the types are of unequal sizes, then in the case of discrete types, a shorter source is first zero or sign extended as necessary, and a shorter target is simply truncated on the left. For all non-discrete types, the source is first copied if necessary to ensure that the alignment requirements of the target are met, then a pointer is constructed to the source value, and the result is obtained by dereferencing this pointer after converting it to be a pointer to the target type. Unchecked conversions where the target subtype is an unconstrained array are not permitted. If the target alignment is greater than the source alignment, then a copy of the result is made with appropriate alignment * “The result of unchecked conversion for instances with nonscalar result types whose result is not defined by the language. See 13.9(11).” See preceding definition for the scalar result case. * “Whether or not the implementation provides user-accessible names for the standard pool type(s). See 13.11(17).” There are 3 different standard pools used by the compiler when ‘Storage_Pool’ is not specified depending whether the type is local to a subprogram or defined at the library level and whether ‘Storage_Size``is specified or not. See documentation in the runtime library units ``System.Pool_Global’, ‘System.Pool_Size’ and ‘System.Pool_Local’ in files ‘s-poosiz.ads’, ‘s-pooglo.ads’ and ‘s-pooloc.ads’ for full details on the default pools used. All these pools are accessible by means of ‘with’ing these units. * “The meaning of ‘Storage_Size’ when neither the Storage_Size nor the Storage_Pool is specified for an access type. See 13.11(18).” ‘Storage_Size’ is measured in storage units, and refers to the total space available for an access type collection, or to the primary stack space for a task. * “The effect of specifying aspect Default_Storage_Pool on an instance of a language-defined generic unit. See 13.11.3(5).” Instances of language-defined generic units are treated the same as other instances with respect to the Default_Storage_Pool aspect. * “Implementation-defined restrictions allowed in a pragma ‘Restrictions’. See 13.12(8.7).” See *note Standard and Implementation Defined Restrictions: 9. * “The consequences of violating limitations on ‘Restrictions’ pragmas. See 13.12(9).” Restrictions that can be checked at compile time are enforced at compile time; violations are illegal. For other restrictions, any violation during program execution results in erroneous execution. * “Implementation-defined usage profiles allowed in a pragma Profile. See 13.12(15).” See *note Implementation Defined Pragmas: 7. * “The contents of the stream elements read and written by the Read and Write attributes of elementary types. See 13.13.2(9).” The representation is the in-memory representation of the base type of the type, using the number of bits corresponding to the ‘type'Size’ value, and the natural ordering of the machine. * “The names and characteristics of the numeric subtypes declared in the visible part of package ‘Standard’. See A.1(3).” See items describing the integer and floating-point types supported. * “The values returned by Strings.Hash. See A.4.9(3).” This hash function has predictable collisions and is subject to equivalent substring attacks. It is not suitable for construction of a hash table keyed on possibly malicious user input. * “The value returned by a call to a Text_Buffer Get procedure if any character in the returned sequence is not defined in Character. See A.4.12(34).” The contents of a buffer is represented internally as a UTF_8 string. The value return by Text_Buffer.Get is the result of passing that UTF_8 string to UTF_Encoding.Strings.Decode. * “The value returned by a call to a Text_Buffer Wide_Get procedure if any character in the returned sequence is not defined in Wide_Character. See A.4.12(34).” The contents of a buffer is represented internally as a UTF_8 string. The value return by Text_Buffer.Wide_Get is the result of passing that UTF_8 string to UTF_Encoding.Wide_Strings.Decode. * “The accuracy actually achieved by the elementary functions. See A.5.1(1).” The elementary functions correspond to the functions available in the C library. Only fast math mode is implemented. * “The sign of a zero result from some of the operators or functions in ‘Numerics.Generic_Elementary_Functions’, when ‘Float_Type'Signed_Zeros’ is ‘True’. See A.5.1(46).” The sign of zeroes follows the requirements of the IEEE 754 standard on floating-point. * “The value of ‘Numerics.Float_Random.Max_Image_Width’. See A.5.2(27).” Maximum image width is 6864, see library file ‘s-rannum.ads’. * “The value of ‘Numerics.Discrete_Random.Max_Image_Width’. See A.5.2(27).” Maximum image width is 6864, see library file ‘s-rannum.ads’. * “The string representation of a random number generator’s state. See A.5.2(38).” The value returned by the Image function is the concatenation of the fixed-width decimal representations of the 624 32-bit integers of the state vector. * “The values of the ‘Model_Mantissa’, ‘Model_Emin’, ‘Model_Epsilon’, ‘Model’, ‘Safe_First’, and ‘Safe_Last’ attributes, if the Numerics Annex is not supported. See A.5.3(72).” Running the compiler with '-gnatS' to produce a listing of package ‘Standard’ displays the values of these attributes. * “The value of ‘Buffer_Size’ in ‘Storage_IO’. See A.9(10).” All type representations are contiguous, and the ‘Buffer_Size’ is the value of ‘type'Size’ rounded up to the next storage unit boundary. * “External files for standard input, standard output, and standard error See A.10(5).” These files are mapped onto the files provided by the C streams libraries. See source file ‘i-cstrea.ads’ for further details. * “The accuracy of the value produced by ‘Put’. See A.10.9(36).” If more digits are requested in the output than are represented by the precision of the value, zeroes are output in the corresponding least significant digit positions. * “Current size for a stream file for which positioning is not supported. See A.12.1(1.1).” Positioning is supported. * “The meaning of ‘Argument_Count’, ‘Argument’, and ‘Command_Name’. See A.15(1).” These are mapped onto the ‘argv’ and ‘argc’ parameters of the main program in the natural manner. * “The interpretation of file names and directory names. See A.16(46).” These names are interpreted consistently with the underlying file system. * “The maxium value for a file size in Directories. See A.16(87).” Directories.File_Size’Last is equal to Long_Long_Integer’Last . * “The result for Directories.Size for a directory or special file. See A.16(93).” Name_Error is raised. * “The result for Directories.Modification_Time for a directory or special file. See A.16(93).” Name_Error is raised. * “The interpretation of a nonnull search pattern in Directories. See A.16(104).” When the ‘Pattern’ parameter is not the null string, it is interpreted according to the syntax of regular expressions as defined in the ‘GNAT.Regexp’ package. See *note GNAT.Regexp (g-regexp.ads): 26b. * “The results of a Directories search if the contents of the directory are altered while a search is in progress. See A.16(110).” The effect of a call to Get_Next_Entry is determined by the current state of the directory. * “The definition and meaning of an environment variable. See A.17(1).” This definition is determined by the underlying operating system. * “The circumstances where an environment variable cannot be defined. See A.17(16).” There are no such implementation-defined circumstances. * “Environment names for which Set has the effect of Clear. See A.17(17).” There are no such names. * “The value of Containers.Hash_Type’Modulus. The value of Containers.Count_Type’Last. See A.18.1(7).” Containers.Hash_Type’Modulus is 2**32. Containers.Count_Type’Last is 2**31 - 1. * “Implementation-defined convention names. See B.1(11).” The following convention names are supported Convention Name Interpretation --------------------------------------------------------------------------------------------------------------- 'Ada' Ada 'Ada_Pass_By_Copy' Allowed for any types except by-reference types such as limited records. Compatible with convention Ada, but causes any parameters with this convention to be passed by copy. 'Ada_Pass_By_Reference' Allowed for any types except by-copy types such as scalars. Compatible with convention Ada, but causes any parameters with this convention to be passed by reference. 'Assembler' Assembly language 'Asm' Synonym for Assembler 'Assembly' Synonym for Assembler 'C' C 'C_Pass_By_Copy' Allowed only for record types, like C, but also notes that record is to be passed by copy rather than reference. 'COBOL' COBOL 'C_Plus_Plus (or CPP)' C++ 'Default' Treated the same as C 'External' Treated the same as C 'Fortran' Fortran 'Intrinsic' For support of pragma ‘Import’ with convention Intrinsic, see separate section on Intrinsic Subprograms. 'Stdcall' Stdcall (used for Windows implementations only). This convention correspond to the WINAPI (previously called Pascal convention) C/C++ convention under Windows. A routine with this convention cleans the stack before exit. This pragma cannot be applied to a dispatching call. 'DLL' Synonym for Stdcall 'Win32' Synonym for Stdcall 'Stubbed' Stubbed is a special convention used to indicate that the body of the subprogram will be entirely ignored. Any call to the subprogram is converted into a raise of the ‘Program_Error’ exception. If a pragma ‘Import’ specifies convention ‘stubbed’ then no body need be present at all. This convention is useful during development for the inclusion of subprograms whose body has not yet been written. In addition, all otherwise unrecognized convention names are also treated as being synonymous with convention C. In all implementations, use of such other names results in a warning. * “The meaning of link names. See B.1(36).” Link names are the actual names used by the linker. * “The manner of choosing link names when neither the link name nor the address of an imported or exported entity is specified. See B.1(36).” The default linker name is that which would be assigned by the relevant external language, interpreting the Ada name as being in all lower case letters. * “The effect of pragma ‘Linker_Options’. See B.1(37).” The string passed to ‘Linker_Options’ is presented uninterpreted as an argument to the link command, unless it contains ASCII.NUL characters. NUL characters if they appear act as argument separators, so for example pragma Linker_Options ("-labc" & ASCII.NUL & "-ldef"); causes two separate arguments ‘-labc’ and ‘-ldef’ to be passed to the linker. The order of linker options is preserved for a given unit. The final list of options passed to the linker is in reverse order of the elaboration order. For example, linker options for a body always appear before the options from the corresponding package spec. * “The contents of the visible part of package ‘Interfaces’ and its language-defined descendants. See B.2(1).” See files with prefix ‘i-’ in the distributed library. * “Implementation-defined children of package ‘Interfaces’. The contents of the visible part of package ‘Interfaces’. See B.2(11).” See files with prefix ‘i-’ in the distributed library. * “The definitions of certain types and constants in Interfaces.C. See B.3(41).” See source file ‘i-c.ads’. * “The types ‘Floating’, ‘Long_Floating’, ‘Binary’, ‘Long_Binary’, ‘Decimal_ Element’, and ‘COBOL_Character’; and the initialization of the variables ‘Ada_To_COBOL’ and ‘COBOL_To_Ada’, in ‘Interfaces.COBOL’. See B.4(50).” COBOL Ada ------------------------------------------------------------------- 'Floating' Float 'Long_Floating' (Floating) Long_Float 'Binary' Integer 'Long_Binary' Long_Long_Integer 'Decimal_Element' Character 'COBOL_Character' Character For initialization, see the file ‘i-cobol.ads’ in the distributed library. * “The types Fortran_Integer, Real, Double_Precision, and Character_Set in Interfaces.Fortran. See B.5(17).” See source file ‘i-fortra.ads’. These types are derived, respectively, from Integer, Float, Long_Float, and Character. * “Implementation-defined intrinsic subprograms. See C.1(1).” See separate section on Intrinsic Subprograms. * “Any restrictions on a protected procedure or its containing type when an aspect Attach_handler or Interrupt_Handler is specified. See C.3.1(17).” There are no such restrictions. * “Any other forms of interrupt handler supported by the Attach_Handler and Interrupt_Handler aspects. See C.3.1(19).” There are no such forms. * “The semantics of some attributes and functions of an entity for which aspect Discard_Names is True. See C.5(7).” If Discard_Names is True for an enumeration type, the Image attribute provides the image of the Pos of the literal, and Value accepts Pos values. If both of the aspects''Discard_Names'' and ‘No_Tagged_Streams’ are true for a tagged type, its Expanded_Name and External_Tag values are empty strings. This is useful to avoid exposing entity names at binary level. * “The modulus and size of Test_and_Set_Flag. See C.6.3(8).” The modulus is 2**8. The size is 8. * “The value used to represent the set value for Atomic_Test_and_Set. See C.6.3(10).” The value is 1. * “The result of the ‘Task_Identification.Image’ attribute. See C.7.1(7).” The result of this attribute is a string that identifies the object or component that denotes a given task. If a variable ‘Var’ has a task type, the image for this task will have the form ‘Var_XXXXXXXX’, where the suffix 'XXXXXXXX' is the hexadecimal representation of the virtual address of the corresponding task control block. If the variable is an array of tasks, the image of each task will have the form of an indexed component indicating the position of a given task in the array, e.g., ‘Group(5)_XXXXXXX’. If the task is a component of a record, the image of the task will have the form of a selected component. These rules are fully recursive, so that the image of a task that is a subcomponent of a composite object corresponds to the expression that designates this task. If a task is created by an allocator, its image depends on the context. If the allocator is part of an object declaration, the rules described above are used to construct its image, and this image is not affected by subsequent assignments. If the allocator appears within an expression, the image includes only the name of the task type. If the configuration pragma Discard_Names is present, or if the restriction No_Implicit_Heap_Allocation is in effect, the image reduces to the numeric suffix, that is to say the hexadecimal representation of the virtual address of the control block of the task. * “The value of ‘Current_Task’ when in a protected entry or interrupt handler. See C.7.1(17).” Protected entries or interrupt handlers can be executed by any convenient thread, so the value of ‘Current_Task’ is undefined. * “Granularity of locking for Task_Attributes. See C.7.2(16).” No locking is needed if the formal type Attribute has the size and alignment of either Integer or System.Address and the bit representation of Initial_Value is all zeroes. Otherwise, locking is performed. * “The declarations of ‘Any_Priority’ and ‘Priority’. See D.1(11).” See declarations in file ‘system.ads’. * “Implementation-defined execution resources. See D.1(15).” There are no implementation-defined execution resources. * “Whether, on a multiprocessor, a task that is waiting for access to a protected object keeps its processor busy. See D.2.1(3).” On a multi-processor, a task that is waiting for access to a protected object does not keep its processor busy. * “The affect of implementation defined execution resources on task dispatching. See D.2.1(9).” Tasks map to threads in the threads package used by GNAT. Where possible and appropriate, these threads correspond to native threads of the underlying operating system. * “Implementation-defined task dispatching policies. See D.2.2(3).” There are no implementation-defined task dispatching policies. * “The value of Default_Quantum in Dispatching.Round_Robin. See D.2.5(4).” The value is 10 milliseconds. * “Implementation-defined 'policy_identifiers' allowed in a pragma ‘Locking_Policy’. See D.3(4).” The two implementation defined policies permitted in GNAT are ‘Inheritance_Locking’ and ‘Concurrent_Readers_Locking’. On targets that support the ‘Inheritance_Locking’ policy, locking is implemented by inheritance, i.e., the task owning the lock operates at a priority equal to the highest priority of any task currently requesting the lock. On targets that support the ‘Concurrent_Readers_Locking’ policy, locking is implemented with a read/write lock allowing multiple protected object functions to enter concurrently. * “Default ceiling priorities. See D.3(10).” The ceiling priority of protected objects of the type ‘System.Interrupt_Priority'Last’ as described in the Ada Reference Manual D.3(10), * “The ceiling of any protected object used internally by the implementation. See D.3(16).” The ceiling priority of internal protected objects is ‘System.Priority'Last’. * “Implementation-defined queuing policies. See D.4(1).” There are no implementation-defined queuing policies. * “Implementation-defined admission policies. See D.4.1(1).” There are no implementation-defined admission policies. * “Any operations that implicitly require heap storage allocation. See D.7(8).” The only operation that implicitly requires heap storage allocation is task creation. * “When restriction No_Dynamic_CPU_Assignment applies to a partition, the processor on which a task with a CPU value of a Not_A_Specific_CPU will execute. See D.7(10).” Unknown. * “When restriction No_Task_Termination applies to a partition, what happens when a task terminates. See D.7(15.1).” Execution is erroneous in that case. * “The behavior when restriction Max_Storage_At_Blocking is violated. See D.7(17).” Execution is erroneous in that case. * “The behavior when restriction Max_Asynchronous_Select_Nesting is violated. See D.7(18).” Execution is erroneous in that case. * “The behavior when restriction Max_Tasks is violated. See D.7(19).” Execution is erroneous in that case. * “Whether the use of pragma Restrictions results in a reduction in program code or data size or execution time. See D.7(20).” Yes it can, but the precise circumstances and properties of such reductions are difficult to characterize. * “The value of Barrier_Limit’Last in Synchronous_Barriers. See D.10.1(4).” Synchronous_Barriers.Barrier_Limit’Last is Integer’Last . * “When an aborted task that is waiting on a Synchronous_Barrier is aborted. See D.10.1(13).” Difficult to characterize. * “The value of Min_Handler_Ceiling in Execution_Time.Group_Budgets. See D.14.2(7).” See source file ‘a-etgrbu.ads’. * “The value of CPU_Range’Last in System.Multiprocessors. See D.16(4).” See source file ‘s-multip.ads’. * “The processor on which the environment task executes in the absence of a value for the aspect CPU. See D.16(13).” Unknown. * “The means for creating and executing distributed programs. See E(5).” The GLADE package provides a utility GNATDIST for creating and executing distributed programs. See the GLADE reference manual for further details. * “Any events that can result in a partition becoming inaccessible. See E.1(7).” See the GLADE reference manual for full details on such events. * “The scheduling policies, treatment of priorities, and management of shared resources between partitions in certain cases. See E.1(11).” See the GLADE reference manual for full details on these aspects of multi-partition execution. * “Whether the execution of the remote subprogram is immediately aborted as a result of cancellation. See E.4(13).” See the GLADE reference manual for details on the effect of abort in a distributed application. * “The range of type System.RPC.Partition_Id. See E.5(14).” System.RPC.Partition_ID’Last is Integer’Last. See source file ‘s-rpc.ads’. * “Implementation-defined interfaces in the PCS. See E.5(26).” See the GLADE reference manual for a full description of all implementation defined interfaces. * “The values of named numbers in the package ‘Decimal’. See F.2(7).” Named Number Value ---------------------------------------- 'Max_Scale' +18 'Min_Scale' -18 'Min_Delta' 1.0E-18 'Max_Delta' 1.0E+18 'Max_Decimal_Digits' 18 * “The value of ‘Max_Picture_Length’ in the package ‘Text_IO.Editing’. See F.3.3(16).” 64 * “The value of ‘Max_Picture_Length’ in the package ‘Wide_Text_IO.Editing’. See F.3.4(5).” 64 * “The accuracy actually achieved by the complex elementary functions and by other complex arithmetic operations. See G.1(1).” Standard library functions are used for the complex arithmetic operations. Only fast math mode is currently supported. * “The sign of a zero result (or a component thereof) from any operator or function in ‘Numerics.Generic_Complex_Types’, when ‘Real'Signed_Zeros’ is True. See G.1.1(53).” The signs of zero values are as recommended by the relevant implementation advice. * “The sign of a zero result (or a component thereof) from any operator or function in ‘Numerics.Generic_Complex_Elementary_Functions’, when ‘Real'Signed_Zeros’ is ‘True’. See G.1.2(45).” The signs of zero values are as recommended by the relevant implementation advice. * “Whether the strict mode or the relaxed mode is the default. See G.2(2).” The strict mode is the default. There is no separate relaxed mode. GNAT provides a highly efficient implementation of strict mode. * “The result interval in certain cases of fixed-to-float conversion. See G.2.1(10).” For cases where the result interval is implementation dependent, the accuracy is that provided by performing all operations in 64-bit IEEE floating-point format. * “The result of a floating point arithmetic operation in overflow situations, when the ‘Machine_Overflows’ attribute of the result type is ‘False’. See G.2.1(13).” Infinite and NaN values are produced as dictated by the IEEE floating-point standard. Note that on machines that are not fully compliant with the IEEE floating-point standard, such as Alpha, the '-mieee' compiler flag must be used for achieving IEEE conforming behavior (although at the cost of a significant performance penalty), so infinite and NaN values are properly generated. * “The result interval for division (or exponentiation by a negative exponent), when the floating point hardware implements division as multiplication by a reciprocal. See G.2.1(16).” Not relevant, division is IEEE exact. * “The definition of close result set, which determines the accuracy of certain fixed point multiplications and divisions. See G.2.3(5).” Operations in the close result set are performed using IEEE long format floating-point arithmetic. The input operands are converted to floating-point, the operation is done in floating-point, and the result is converted to the target type. * “Conditions on a 'universal_real' operand of a fixed point multiplication or division for which the result shall be in the perfect result set. See G.2.3(22).” The result is only defined to be in the perfect result set if the result can be computed by a single scaling operation involving a scale factor representable in 64 bits. * “The result of a fixed point arithmetic operation in overflow situations, when the ‘Machine_Overflows’ attribute of the result type is ‘False’. See G.2.3(27).” Not relevant, ‘Machine_Overflows’ is ‘True’ for fixed-point types. * “The result of an elementary function reference in overflow situations, when the ‘Machine_Overflows’ attribute of the result type is ‘False’. See G.2.4(4).” IEEE infinite and Nan values are produced as appropriate. * “The value of the angle threshold, within which certain elementary functions, complex arithmetic operations, and complex elementary functions yield results conforming to a maximum relative error bound. See G.2.4(10).” Information on this subject is not yet available. * “The accuracy of certain elementary functions for parameters beyond the angle threshold. See G.2.4(10).” Information on this subject is not yet available. * “The result of a complex arithmetic operation or complex elementary function reference in overflow situations, when the ‘Machine_Overflows’ attribute of the corresponding real type is ‘False’. See G.2.6(5).” IEEE infinite and Nan values are produced as appropriate. * “The accuracy of certain complex arithmetic operations and certain complex elementary functions for parameters (or components thereof) beyond the angle threshold. See G.2.6(8).” Information on those subjects is not yet available. * “The accuracy requirements for the subprograms Solve, Inverse, Determinant, Eigenvalues and Eigensystem for type Real_Matrix. See G.3.1(81).” Information on those subjects is not yet available. * “The accuracy requirements for the subprograms Solve, Inverse, Determinant, Eigenvalues and Eigensystem for type Complex_Matrix. See G.3.2(149).” Information on those subjects is not yet available. * “The consequences of violating No_Hidden_Indirect_Globals. See H.4(23.9).” Execution is erroneous in that case.