You've already forked gnatstudio
mirror of
https://github.com/AdaCore/gnatstudio.git
synced 2026-02-12 12:42:33 -08:00
10341 lines
406 KiB
XML
10341 lines
406 KiB
XML
<PREDEFINED_ADA>
|
||
|
||
<ASPECT id="0" name="Abstract_State" origin="GNAT RM" category="unknown">
|
||
<DOC>This aspect is equivalent to *note pragma Abstract_State: 1e.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Always_Terminates" origin="GNAT RM" category="unknown">
|
||
<DOC>This boolean aspect is equivalent to *note pragma Always_Terminates: 29.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Annotate" origin="GNAT RM" category="unknown">
|
||
<DOC>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);'</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Async_Readers" origin="GNAT RM" category="unknown">
|
||
<DOC>This boolean aspect is equivalent to *note pragma Async_Readers: 32.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Async_Writers" origin="GNAT RM" category="unknown">
|
||
<DOC>This boolean aspect is equivalent to *note pragma Async_Writers: 34.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Constant_After_Elaboration" origin="GNAT RM" category="unknown">
|
||
<DOC>This aspect is equivalent to *note pragma Constant_After_Elaboration:
|
||
44.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Contract_Cases" origin="GNAT RM" category="unknown">
|
||
<DOC>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.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Default_Initial_Condition" origin="GNAT RM" category="unknown">
|
||
<DOC>This aspect is equivalent to *note pragma Default_Initial_Condition: 52.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Depends" origin="GNAT RM" category="unknown">
|
||
<DOC>This aspect is equivalent to *note pragma Depends: 56.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Dimension" origin="GNAT RM" category="unknown">
|
||
<DOC>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.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Dimension_System" origin="GNAT RM" category="unknown">
|
||
<DOC>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.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Disable_Controlled" origin="GNAT RM" category="unknown">
|
||
<DOC>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.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Effective_Reads" origin="GNAT RM" category="unknown">
|
||
<DOC>This aspect is equivalent to *note pragma Effective_Reads: 5b.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Effective_Writes" origin="GNAT RM" category="unknown">
|
||
<DOC>This aspect is equivalent to *note pragma Effective_Writes: 5d.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Exceptional_Cases" origin="GNAT RM" category="unknown">
|
||
<DOC>This aspect may be specified for procedures and functions with side
|
||
effects; it can be used to list exceptions that might be propagated by
|
||
the subprogram with side effects in the context of its precondition,
|
||
and associate them with a specific postcondition.
|
||
|
||
For the syntax and semantics of this aspect, see the SPARK 2014
|
||
Reference Manual, section 6.1.9.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Exit_Cases" origin="GNAT RM" category="unknown">
|
||
<DOC>This aspect may be specified for procedures and functions with side
|
||
effects; it can be used to partition the input state into a list of
|
||
cases and specify, for each case, how the subprogram is allowed to
|
||
terminate (i.e. return normally or propagate an exception).
|
||
|
||
For the syntax and semantics of this aspect, see the SPARK 2014
|
||
Reference Manual, section 6.1.10.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Extensions_Visible" origin="GNAT RM" category="unknown">
|
||
<DOC>This aspect is equivalent to *note pragma Extensions_Visible: 6d.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Favor_Top_Level" origin="GNAT RM" category="unknown">
|
||
<DOC>This boolean aspect is equivalent to *note pragma Favor_Top_Level: 72.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Ghost" origin="GNAT RM" category="unknown">
|
||
<DOC>This aspect is equivalent to *note pragma Ghost: 76.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Ghost_Predicate" origin="GNAT RM" category="unknown">
|
||
<DOC>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.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Global" origin="GNAT RM" category="unknown">
|
||
<DOC>This aspect is equivalent to *note pragma Global: 78.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Initial_Condition" origin="GNAT RM" category="unknown">
|
||
<DOC>This aspect is equivalent to *note pragma Initial_Condition: 85.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Initializes" origin="GNAT RM" category="unknown">
|
||
<DOC>This aspect is equivalent to *note pragma Initializes: 88.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Inline_Always" origin="GNAT RM" category="unknown">
|
||
<DOC>This boolean aspect is equivalent to *note pragma Inline_Always: 8a.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Invariant" origin="GNAT RM" category="unknown">
|
||
<DOC>This aspect is equivalent to *note pragma Invariant: 92. It is a
|
||
synonym for the language defined aspect `Type_Invariant' except that it
|
||
is separately controllable using pragma `Assertion_Policy'.
|
||
|
||
3.26 Aspect Invariant’Class
|
||
|
||
This aspect is equivalent to *note pragma Type_Invariant_Class: 110. It
|
||
is a synonym for the language defined aspect `Type_Invariant'Class'
|
||
except that it is separately controllable using pragma
|
||
`Assertion_Policy'.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Iterable" origin="GNAT RM" category="unknown">
|
||
<DOC>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.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Linker_Section" origin="GNAT RM" category="unknown">
|
||
<DOC>This aspect is equivalent to *note pragma Linker_Section: 9a.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Local_Restrictions" origin="GNAT RM" category="unknown">
|
||
<DOC>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).</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Lock_Free" origin="GNAT RM" category="unknown">
|
||
<DOC>This boolean aspect is equivalent to *note pragma Lock_Free: 9c.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Max_Queue_Length" origin="GNAT RM" category="unknown">
|
||
<DOC>This aspect is equivalent to *note pragma Max_Queue_Length: a4.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="No_Caching" origin="GNAT RM" category="unknown">
|
||
<DOC>This boolean aspect is equivalent to *note pragma No_Caching: a7.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="No_Elaboration_Code_All" origin="GNAT RM" category="unknown">
|
||
<DOC>This aspect is equivalent to *note pragma No_Elaboration_Code_All: aa.
|
||
for a program unit.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="No_Inline" origin="GNAT RM" category="unknown">
|
||
<DOC>This boolean aspect is equivalent to *note pragma No_Inline: ad.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="No_Raise" origin="GNAT RM" category="unknown">
|
||
<DOC>This boolean aspect is equivalent to *note pragma No_Raise: af.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="No_Tagged_Streams" origin="GNAT RM" category="unknown">
|
||
<DOC>This aspect is equivalent to *note pragma No_Tagged_Streams: b3. with an
|
||
argument specifying a root tagged type (thus this aspect can only be
|
||
applied to such a type).</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="No_Task_Parts" origin="GNAT RM" category="unknown">
|
||
<DOC>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.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Object_Size" origin="GNAT RM" category="unknown">
|
||
<DOC>This aspect is equivalent to *note attribute Object_Size: 157.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Obsolescent" origin="GNAT RM" category="unknown">
|
||
<DOC>This aspect is equivalent to *note pragma Obsolescent: b6. Note that the
|
||
evaluation of this aspect happens at the point of occurrence, it is not
|
||
delayed until the freeze point.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Part_Of" origin="GNAT RM" category="unknown">
|
||
<DOC>This aspect is equivalent to *note pragma Part_Of: bc.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Persistent_BSS" origin="GNAT RM" category="unknown">
|
||
<DOC>This boolean aspect is equivalent to *note pragma Persistent_BSS: c0.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Predicate" origin="GNAT RM" category="unknown">
|
||
<DOC>This aspect is equivalent to *note pragma Predicate: c7. 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'.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Program_Exit" origin="GNAT RM" category="unknown">
|
||
<DOC>This boolean aspect is equivalent to *note pragma Program_Exit: d0.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Pure_Function" origin="GNAT RM" category="unknown">
|
||
<DOC>This boolean aspect is equivalent to *note pragma Pure_Function: d5.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Refined_Depends" origin="GNAT RM" category="unknown">
|
||
<DOC>This aspect is equivalent to *note pragma Refined_Depends: d9.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Refined_Global" origin="GNAT RM" category="unknown">
|
||
<DOC>This aspect is equivalent to *note pragma Refined_Global: db.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Refined_Post" origin="GNAT RM" category="unknown">
|
||
<DOC>This aspect is equivalent to *note pragma Refined_Post: dd.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Refined_State" origin="GNAT RM" category="unknown">
|
||
<DOC>This aspect is equivalent to *note pragma Refined_State: df.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Relaxed_Initialization" origin="GNAT RM" category="unknown">
|
||
<DOC>For the syntax and semantics of this aspect, see the SPARK 2014
|
||
Reference Manual, section 6.10.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Remote_Access_Type" origin="GNAT RM" category="unknown">
|
||
<DOC>This aspect is equivalent to *note pragma Remote_Access_Type: e2.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="SPARK_Mode" origin="GNAT RM" category="unknown">
|
||
<DOC>This aspect is equivalent to *note pragma SPARK_Mode: f9. and may be
|
||
specified for either or both of the specification and body of a
|
||
subprogram or package.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Scalar_Storage_Order" origin="GNAT RM" category="unknown">
|
||
<DOC>This aspect is equivalent to a *note attribute Scalar_Storage_Order:
|
||
165.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Secondary_Stack_Size" origin="GNAT RM" category="unknown">
|
||
<DOC>This aspect is equivalent to *note pragma Secondary_Stack_Size: e8.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Shared" origin="GNAT RM" category="unknown">
|
||
<DOC>This boolean aspect is equivalent to *note pragma Shared: eb. and is
|
||
thus a synonym for aspect `Atomic'.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Side_Effects" origin="GNAT RM" category="unknown">
|
||
<DOC>This aspect is equivalent to *note pragma Side_Effects: ef.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Simple_Storage_Pool" origin="GNAT RM" category="unknown">
|
||
<DOC>This aspect is equivalent to *note attribute Simple_Storage_Pool: f2.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Simple_Storage_Pool_Type" origin="GNAT RM" category="unknown">
|
||
<DOC>This boolean aspect is equivalent to *note pragma
|
||
Simple_Storage_Pool_Type: f1.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Subprogram_Variant" origin="GNAT RM" category="unknown">
|
||
<DOC>For the syntax and semantics of this aspect, see the SPARK 2014
|
||
Reference Manual, section 6.1.8.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Suppress_Debug_Info" origin="GNAT RM" category="unknown">
|
||
<DOC>This boolean aspect is equivalent to *note pragma Suppress_Debug_Info:
|
||
102.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Suppress_Initialization" origin="GNAT RM" category="unknown">
|
||
<DOC>This boolean aspect is equivalent to *note pragma
|
||
Suppress_Initialization: 105.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Test_Case" origin="GNAT RM" category="unknown">
|
||
<DOC>This aspect is equivalent to *note pragma Test_Case: 109.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Thread_Local_Storage" origin="GNAT RM" category="unknown">
|
||
<DOC>This boolean aspect is equivalent to *note pragma Thread_Local_Storage:
|
||
10b.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Universal_Aliasing" origin="GNAT RM" category="unknown">
|
||
<DOC>This boolean aspect is equivalent to *note pragma Universal_Aliasing:
|
||
116.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Unmodified" origin="GNAT RM" category="unknown">
|
||
<DOC>This boolean aspect is equivalent to *note pragma Unmodified: 118.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Unreferenced" origin="GNAT RM" category="unknown">
|
||
<DOC>This boolean aspect is equivalent to *note pragma Unreferenced: 11a.
|
||
|
||
When using the `-gnat2022' switch, this aspect is also supported on
|
||
formal parameters, which is in particular the only form possible for
|
||
expression functions.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Unreferenced_Objects" origin="GNAT RM" category="unknown">
|
||
<DOC>This boolean aspect is equivalent to *note pragma Unreferenced_Objects:
|
||
11c.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="User_Aspect" origin="GNAT RM" category="unknown">
|
||
<DOC>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.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Value_Size" origin="GNAT RM" category="unknown">
|
||
<DOC>This aspect is equivalent to *note attribute Value_Size: 177.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Volatile_Full_Access" origin="GNAT RM" category="unknown">
|
||
<DOC>This boolean aspect is equivalent to *note pragma Volatile_Full_Access:
|
||
126.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Volatile_Function" origin="GNAT RM" category="unknown">
|
||
<DOC>This boolean aspect is equivalent to *note pragma Volatile_Function:
|
||
128.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="0" name="Warnings" origin="GNAT RM" category="unknown">
|
||
<DOC>This aspect is equivalent to the two argument form of *note pragma
|
||
Warnings: 12a, where the first argument is `ON' or `OFF' and the second
|
||
argument is the entity.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="10/3" name="Bit_Order" origin="Ada RM" category="unknown">
|
||
<DOC>Order of bit numbering in a record_representation_clause. See</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="15/5" name="CPU" origin="Ada RM" category="unknown">
|
||
<DOC>Processor on which a given task, or calling task for a
|
||
protected operation, should run. See D.16.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="11/3" name="Coding" origin="Ada RM" category="unknown">
|
||
<DOC>Internal representation of enumeration literals. Specified by
|
||
an enumeration_representation_clause, not by an
|
||
aspect_specification. See 13.4.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="12/3" name="Component_Size" origin="Ada RM" category="unknown">
|
||
<DOC>Size in bits of a component of an array type. See 13.3.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="13/3" name="Constant_Indexing" origin="Ada RM" category="unknown">
|
||
<DOC>Defines function(s) to implement user-defined
|
||
indexed_components. See 4.1.6.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="14/3" name="Convention" origin="Ada RM" category="unknown">
|
||
<DOC>Calling convention or other convention used for interfacing to
|
||
other languages. See B.1.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="16/3" name="Default_Component_Value" origin="Ada RM" category="unknown">
|
||
<DOC>Default value for the components of an array-of-scalar
|
||
subtype. See 3.6.
|
||
|
||
16.1/5 Default_Initial_Condition
|
||
A condition that will hold true after the default
|
||
initialization of an object. See 7.3.3.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="17/3" name="Default_Iterator" origin="Ada RM" category="unknown">
|
||
<DOC>Default iterator to be used in for loops. See 5.5.1.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="18/3" name="Default_Storage_Pool" origin="Ada RM" category="unknown">
|
||
<DOC>Default storage pool for a generic instance. See 13.11.3.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="19/3" name="Default_Value" origin="Ada RM" category="unknown">
|
||
<DOC>Default value for a scalar subtype. See 3.5.
|
||
|
||
19.1/4 Discard_Names
|
||
Requests a reduction in storage for names associated with an
|
||
entity. See C.5.
|
||
|
||
19.2/5 Dispatching
|
||
Generic formal parameters used in the implementation of an
|
||
entity. See H.7.1.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="2/3" name="Address" origin="Ada RM" category="unknown">
|
||
<DOC>Machine address of an entity. See 13.3.
|
||
|
||
2.1/5 Aggregate Mechanism to define user-defined aggregates. See 4.3.5.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="20/3" name="Dispatching_Domain" origin="Ada RM" category="unknown">
|
||
<DOC>Domain (group of processors) on which a given task should run.
|
||
See D.16.1.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="21/5" name="Dynamic_Predicate" origin="Ada RM" category="unknown">
|
||
<DOC>Condition that will hold true for objects of a given subtype;
|
||
the subtype is not static. See 3.2.4.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="22/5" name="Elaborate_Body" origin="Ada RM" category="unknown">
|
||
<DOC>A given package will have a body, and that body is elaborated
|
||
immediately after the declaration. See 10.2.1.
|
||
|
||
22.1/4 Exclusive_Functions
|
||
Specifies mutual exclusion behavior of protected functions in
|
||
a protected type. See 9.5.1.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="23/3" name="Export" origin="Ada RM" category="unknown">
|
||
<DOC>Entity is exported to another language. See B.1.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="24/3" name="External_Name" origin="Ada RM" category="unknown">
|
||
<DOC>Name used to identify an imported or exported entity. See
|
||
B.1.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="25/3" name="External_Tag" origin="Ada RM" category="unknown">
|
||
<DOC>Unique identifier for a tagged type in streams. See 13.3.
|
||
|
||
25.1/5 Full_Access_Only
|
||
Declare that a volatile type, object, or component is full
|
||
access. See C.6.
|
||
|
||
25.2/5 Global Global object usage contract. See 6.1.2.
|
||
|
||
25.3/5 Global'Class
|
||
Global object usage contract inherited on derivation. See</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="26/3" name="Implicit_Dereference" origin="Ada RM" category="unknown">
|
||
<DOC>Mechanism for user-defined implicit .all. See 4.1.5.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="27/3" name="Import" origin="Ada RM" category="unknown">
|
||
<DOC>Entity is imported from another language. See B.1.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="28/3" name="Independent" origin="Ada RM" category="unknown">
|
||
<DOC>Declare that a type, object, or component is independently
|
||
addressable. See C.6.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="29/3" name="Independent_Components" origin="Ada RM" category="unknown">
|
||
<DOC>Declare that the components of an array or record type, or an
|
||
array object, are independently addressable. See C.6.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="3/3" name="Alignment" origin="Ada RM" category="unknown">
|
||
<DOC>Alignment of an object. See 13.3.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="30/3" name="Inline" origin="Ada RM" category="unknown">
|
||
<DOC>For efficiency, Inline calls are requested for a subprogram.
|
||
See 6.3.2.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="31/3" name="Input" origin="Ada RM" category="unknown">
|
||
<DOC>Function to read a value from a stream for a given type,
|
||
including any bounds and discriminants. See 13.13.2.
|
||
|
||
31.1/4 Input'Class
|
||
Function to read a value from a stream for a the class-wide
|
||
type associated with a given type, including any bounds and
|
||
discriminants. See 13.13.2.
|
||
|
||
31.2/5 Integer_Literal
|
||
Defines a function to implement user-defined integer literals.
|
||
See 4.2.1.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="32/3" name="Interrupt_Handler" origin="Ada RM" category="unknown">
|
||
<DOC>Protected procedure may be attached to interrupts. See C.3.1.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="33/3" name="Interrupt_Priority" origin="Ada RM" category="unknown">
|
||
<DOC>Priority of a task object or type, or priority of a protected
|
||
object or type; the priority is in the interrupt range. See
|
||
D.1.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="34/3" name="Iterator_Element" origin="Ada RM" category="unknown">
|
||
<DOC>Element type to be used for user-defined iterators. See
|
||
|
||
|
||
34.1/5 Iterator_View
|
||
An alternative type to used for container element iterators.
|
||
See 5.5.1.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="35/3" name="Layout" origin="Ada RM" category="unknown">
|
||
<DOC>Layout of record components. Specified by a
|
||
record_representation_clause, not by an aspect_specification.
|
||
See 13.5.1.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="36/3" name="Link_Name" origin="Ada RM" category="unknown">
|
||
<DOC>Linker symbol used to identify an imported or exported entity.
|
||
See B.1.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="37/3" name="Machine_Radix" origin="Ada RM" category="unknown">
|
||
<DOC>Radix (2 or 10) that is used to represent a decimal fixed
|
||
point type. See F.1.
|
||
|
||
37.1/5 Max_Entry_Queue_Length
|
||
The maximum entry queue length for a task type, protected
|
||
type, or entry. See D.4.
|
||
|
||
37.2/5 No_Controlled_Parts
|
||
A specification that a type and its descendants do not have
|
||
controlled parts. See H.4.1.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="38/5" name="No_Return" origin="Ada RM" category="unknown">
|
||
<DOC>A subprogram will not return normally. See 6.5.1.
|
||
|
||
38.1/5 Nonblocking
|
||
Specifies that an associated subprogram does not block. See</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="39/3" name="Output" origin="Ada RM" category="unknown">
|
||
<DOC>Procedure to write a value to a stream for a given type,
|
||
including any bounds and discriminants. See 13.13.2.
|
||
|
||
39.1/4 Output'Class
|
||
Procedure to write a value to a stream for a the class-wide
|
||
type associated with a given type, including any bounds and
|
||
discriminants. See 13.13.2.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="4/3" name="Alignment" origin="Ada RM" category="unknown">
|
||
<DOC>Alignment of a subtype. See 13.3.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="40/3" name="Pack" origin="Ada RM" category="unknown">
|
||
<DOC>Minimize storage when laying out records and arrays. See
|
||
|
||
|
||
40.1/5 Parallel_Calls
|
||
Specifies whether a given subprogram is expected to be called
|
||
in parallel. See 9.10.1.
|
||
|
||
40.2/5 Parallel_Iterator
|
||
An indication of whether a subprogram may use multiple threads
|
||
of control to invoke a loop body procedure. See 5.5.3.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="41/5" name="Post" origin="Ada RM" category="unknown">
|
||
<DOC>Postcondition; a condition that will hold true after a call.
|
||
See 6.1.1.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="42/5" name="Post'Class" origin="Ada RM" category="unknown">
|
||
<DOC>Postcondition that applies to corresponding subprograms of
|
||
descendant types. See 6.1.1.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="43/5" name="Pre" origin="Ada RM" category="unknown">
|
||
<DOC>Precondition; a condition that is expected to hold true before
|
||
a call. See 6.1.1.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="44/5" name="Pre'Class" origin="Ada RM" category="unknown">
|
||
<DOC>Precondition that applies to corresponding subprograms of
|
||
descendant types. See 6.1.1.
|
||
|
||
44.1/4 Predicate_Failure
|
||
Action to be performed when a predicate check fails. See
|
||
|
||
|
||
44.2/5 Preelaborable_Initialization
|
||
Declares that a type has preelaborable initialization. See</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="45/3" name="Preelaborate" origin="Ada RM" category="unknown">
|
||
<DOC>Code execution during elaboration is avoided for a given
|
||
package. See 10.2.1.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="46/3" name="Priority" origin="Ada RM" category="unknown">
|
||
<DOC>Priority of a task object or type, or priority of a protected
|
||
object or type; the priority is not in the interrupt range.
|
||
See D.1.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="47/3" name="Pure" origin="Ada RM" category="unknown">
|
||
<DOC>Side effects are avoided in the subprograms of a given
|
||
package. See 10.2.1.
|
||
|
||
47.1/5 Put_Image
|
||
Procedure to define the image of a given type. See 4.10.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="48/3" name="Read" origin="Ada RM" category="unknown">
|
||
<DOC>Procedure to read a value from a stream for a given type. See
|
||
|
||
|
||
48.1/4 Read'Class
|
||
Procedure to read a value from a stream for the class-wide
|
||
type associated with a given type. See 13.13.2.
|
||
|
||
48.2/5 Real_Literal
|
||
Defines a function or functions to implement user-defined real
|
||
literals. See 4.2.1.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="49/3" name="Record" origin="Ada RM" category="unknown">
|
||
<DOC>layout
|
||
|
||
See Layout. See 13.5.1.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="5/4" name="All_Calls_Remote" origin="Ada RM" category="unknown">
|
||
<DOC>All indirect or dispatching remote subprogram calls, and all
|
||
direct remote subprogram calls, should use the Partition
|
||
Communication Subsystem. See E.2.3.
|
||
|
||
5.1/5 Allows_Exit
|
||
An indication of whether a subprogram will operate correctly
|
||
for arbitrary transfers of control. See 5.5.3.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="50/5" name="Relative_Deadline" origin="Ada RM" category="unknown">
|
||
<DOC>Task or protected type parameter used in Earliest Deadline
|
||
First Dispatching. See D.2.6.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="51/3" name="Remote_Call_Interface" origin="Ada RM" category="unknown">
|
||
<DOC>Subprograms in a given package may be used in remote procedure
|
||
calls. See E.2.3.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="52/3" name="Remote_Types" origin="Ada RM" category="unknown">
|
||
<DOC>Types in a given package may be used in remote procedure
|
||
calls. See E.2.2.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="53/3" name="Shared_Passive" origin="Ada RM" category="unknown">
|
||
<DOC>A given package is used to represent shared memory in a
|
||
distributed system. See E.2.1.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="54/3" name="Size" origin="Ada RM" category="unknown">
|
||
<DOC>Size in bits of an object. See 13.3.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="55/3" name="Size" origin="Ada RM" category="unknown">
|
||
<DOC>Size in bits of a subtype. See 13.3.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="56/3" name="Small" origin="Ada RM" category="unknown">
|
||
<DOC>Scale factor for a fixed point type. See 3.5.10.
|
||
|
||
56.1/5 Stable_Properties
|
||
A list of functions describing characteristics that usually
|
||
are unchanged by primitive operations of the type or an
|
||
individual primitive subprogram. See 7.3.4.
|
||
|
||
56.2/5 Stable_Properties'Class
|
||
A list of functions describing characteristics that usually
|
||
are unchanged by primitive operations of a class of types or a
|
||
primitive subprogram for such a class. See 7.3.4.
|
||
|
||
56.3/5 Static Specifies that an associated expression function can be used
|
||
in static expressions. See 6.8.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="57/5" name="Static_Predicate" origin="Ada RM" category="unknown">
|
||
<DOC>Condition that will hold true for objects of a given subtype;
|
||
the subtype may be static. See 3.2.4.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="58/3" name="Storage_Pool" origin="Ada RM" category="unknown">
|
||
<DOC>Pool of memory from which new will allocate for a given access
|
||
type. See 13.11.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="59/3" name="Storage_Size" origin="Ada RM" category="unknown">
|
||
<DOC>Sets memory size for allocations for an access type. See</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="6/3" name="Asynchronous" origin="Ada RM" category="unknown">
|
||
<DOC>Remote procedure calls are asynchronous; the caller continues
|
||
without waiting for the call to return. See E.4.1.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="60/3" name="Storage_Size" origin="Ada RM" category="unknown">
|
||
<DOC>Size in storage elements reserved for a task type or single
|
||
task object. See 13.3.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="61/3" name="Stream_Size" origin="Ada RM" category="unknown">
|
||
<DOC>Size in bits used to represent elementary objects in a stream.
|
||
See 13.13.2.
|
||
|
||
61.1/5 String_Literal
|
||
Defines a function to implement user-defined string literals.
|
||
See 4.2.1.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="62/5" name="Synchronization" origin="Ada RM" category="unknown">
|
||
<DOC>Defines whether a given primitive operation of a synchronized
|
||
interface will be implemented by an entry or protected
|
||
procedure. See 9.5.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="7/3" name="Atomic" origin="Ada RM" category="unknown">
|
||
<DOC>Declare that a type, object, or component is atomic. See C.6.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="8/3" name="Atomic_Components" origin="Ada RM" category="unknown">
|
||
<DOC>Declare that the components of an array type or object are
|
||
atomic. See C.6.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="9/3" name="Attach_Handler" origin="Ada RM" category="unknown">
|
||
<DOC>Protected procedure is attached to an interrupt. See C.3.1.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="1/3" name="This" origin="Ada RM" category="unknown">
|
||
<DOC>subclause summarizes the definitions given elsewhere of the
|
||
language-defined aspects. Aspects are properties of entities that can be
|
||
specified by the Ada program; unless otherwise specified below, aspects can be
|
||
specified using an aspect_specification.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="63/3" name="Type_Invariant" origin="Ada RM" category="unknown">
|
||
<DOC>A condition that will hold true for all objects of a type. See</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="64/3" name="Type_Invariant'Class" origin="Ada RM" category="unknown">
|
||
<DOC>A condition that will hold true for all objects in a class of
|
||
types. See 7.3.2.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="65/3" name="Unchecked_Union" origin="Ada RM" category="unknown">
|
||
<DOC>Type is used to interface to a C union type. See B.3.3.
|
||
|
||
65.1/5 Use_Formal
|
||
Generic formal parameters used in the implementation of an
|
||
entity. See H.7.1.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="66/3" name="Variable_Indexing" origin="Ada RM" category="unknown">
|
||
<DOC>Defines function(s) to implement user-defined
|
||
indexed_components. See 4.1.6.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="67/3" name="Volatile" origin="Ada RM" category="unknown">
|
||
<DOC>Declare that a type, object, or component is volatile. See
|
||
C.6.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="68/3" name="Volatile_Components" origin="Ada RM" category="unknown">
|
||
<DOC>Declare that the components of an array type or object are
|
||
volatile. See C.6.</DOC>
|
||
</ASPECT>
|
||
<ASPECT id="69/3" name="Write" origin="Ada RM" category="unknown">
|
||
<DOC>Procedure to write a value to a stream for a given type. See
|
||
|
||
|
||
69.1/4 Write'Class
|
||
Procedure to write a value to a stream for a the class-wide
|
||
type associated with a given type. See 13.13.2.
|
||
|
||
69.2/5 Yield Ensures that a callable entity includes a task dispatching
|
||
point. See D.2.1.</DOC>
|
||
</ASPECT>
|
||
<ATTRIBUTE id="0" name="Abort_Signal" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>`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).</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Address_Size" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>`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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Asm_Input" origin="GNAT RM" category="function">
|
||
|
||
<DOC>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: 180.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Asm_Output" origin="GNAT RM" category="function">
|
||
|
||
<DOC>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: 180.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Atomic_Always_Lock_Free" origin="GNAT RM" category="unknown">
|
||
|
||
<DOC>The prefix of the `Atomic_Always_Lock_Free' attribute is a type. The
|
||
result indicates whether atomic operations are supported by the target
|
||
for the given type.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Bit" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>`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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Bit_Position" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>`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'.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Code_Address" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Compiler_Version" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>`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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Constrained" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Default_Bit_Order" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>`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'.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Default_Scalar_Storage_Order" origin="GNAT RM" category="unknown">
|
||
|
||
<DOC>`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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Deref" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Descriptor_Size" origin="GNAT RM" category="unknown">
|
||
|
||
<DOC>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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Elab_Body" origin="GNAT RM" category="procedure">
|
||
|
||
<DOC>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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Elab_Spec" origin="GNAT RM" category="procedure">
|
||
|
||
<DOC>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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Elab_Subp_Body" origin="GNAT RM" category="unknown">
|
||
|
||
<DOC>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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Elaborated" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Emax" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Enabled" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Enum_Rep" origin="GNAT RM" category="function">
|
||
|
||
<DOC>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 <Universal_Integer>;
|
||
|
||
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'.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Enum_Val" origin="GNAT RM" category="function">
|
||
|
||
<DOC>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 : <Universal_Integer>) 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).</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Epsilon" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Fast_Math" origin="GNAT RM" category="unknown">
|
||
|
||
<DOC>`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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Finalization_Size" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Fixed_Value" origin="GNAT RM" category="function">
|
||
|
||
<DOC>For every fixed-point type `S', `S'Fixed_Value' denotes a function with
|
||
the following specification:
|
||
|
||
function S'Fixed_Value (Arg : <Universal_Integer>) 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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="From_Any" origin="GNAT RM" category="unknown">
|
||
|
||
<DOC>This internal attribute is used for the generation of remote subprogram
|
||
stubs in the context of the Distributed Systems Annex.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Has_Access_Values" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Has_Discriminants" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Has_Tagged_Values" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Img" origin="GNAT RM" category="function">
|
||
|
||
<DOC>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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Initialized" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>For the syntax and semantics of this attribute, see the SPARK 2014
|
||
Reference Manual, section 6.10.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Integer_Value" origin="GNAT RM" category="function">
|
||
|
||
<DOC>For every integer type `S', `S'Integer_Value' denotes a function with
|
||
the following spec:
|
||
|
||
function S'Integer_Value (Arg : <Universal_Fixed>) 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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Invalid_Value" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Large" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Library_Level" origin="GNAT RM" category="unknown">
|
||
|
||
<DOC>`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;</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Loop_Entry" origin="GNAT RM" category="unknown">
|
||
|
||
<DOC>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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Machine_Size" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>This attribute is identical to the `Object_Size' attribute. It is
|
||
provided for compatibility with the DEC Ada 83 attribute of this name.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Mantissa" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Max_Integer_Size" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>`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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Maximum_Alignment" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>`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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Mechanism_Code" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>`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</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Null_Parameter" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Object_Size" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>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:
|
||
|
||
procedure BadAVConvert is
|
||
type R is new Integer;
|
||
subtype R1 is R range 1 .. 10;
|
||
subtype R2 is R range 1 .. 10;
|
||
for R1'Object_Size use 8;
|
||
for R2'Object_Size use 16;
|
||
type R1P is access all R1;
|
||
type R2P is access all R2;
|
||
R1PV : R1P := new R1'(4);
|
||
R2PV : R2P;
|
||
begin
|
||
R2PV := R2P (R1PV);
|
||
|
|
||
>>> target designated subtype not compatible with
|
||
type "R1" defined at line 3
|
||
|
||
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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Old" origin="GNAT RM" category="unknown">
|
||
|
||
<DOC>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'.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Passed_By_Reference" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>`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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Pool_Address" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>`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'.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Range_Length" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>`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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Restriction_Set" origin="GNAT RM" category="unknown">
|
||
|
||
<DOC>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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Result" origin="GNAT RM" category="unknown">
|
||
|
||
<DOC>`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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Round" origin="GNAT RM" category="function">
|
||
|
||
<DOC>In addition to the usage of this attribute in the Ada RM, GNAT also
|
||
permits the use of the `'Round' attribute for ordinary fixed point
|
||
types.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Safe_Emax" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Safe_Large" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Safe_Small" origin="GNAT RM" category="unknown">
|
||
|
||
<DOC>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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Scalar_Storage_Order" origin="GNAT RM" category="unknown">
|
||
|
||
<DOC>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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Simple_Storage_Pool" origin="GNAT RM" category="unknown">
|
||
|
||
<DOC>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'.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Small" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Small_Denominator" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>`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).</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Small_Numerator" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>`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).</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Storage_Unit" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>`Standard'Storage_Unit' (`Standard' is the only allowed prefix)
|
||
provides the same value as `System.Storage_Unit'.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Stub_Type" origin="GNAT RM" category="type">
|
||
|
||
<DOC>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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="System_Allocator_Alignment" origin="GNAT RM" category="unknown">
|
||
|
||
<DOC>`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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Target_Name" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>`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”).</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="To_Address" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>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).</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="To_Any" origin="GNAT RM" category="unknown">
|
||
|
||
<DOC>This internal attribute is used for the generation of remote subprogram
|
||
stubs in the context of the Distributed Systems Annex.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="TypeCode" origin="GNAT RM" category="unknown">
|
||
|
||
<DOC>This internal attribute is used for the generation of remote subprogram
|
||
stubs in the context of the Distributed Systems Annex.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Type_Class" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>`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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Type_Key" origin="GNAT RM" category="unknown">
|
||
|
||
<DOC>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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Unconstrained_Array" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Universal_Literal_String" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>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;</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Unrestricted_Access" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>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 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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Update" origin="GNAT RM" category="unknown">
|
||
|
||
<DOC>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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="VADS_Size" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Valid_Scalars" origin="GNAT RM" category="unknown">
|
||
|
||
<DOC>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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Valid_Value" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>The `'Valid_Value' attribute is defined for enumeration types other than
|
||
those in package Standard or types derived from those types. 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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Value_Size" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>`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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Wchar_T_Size" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>`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.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="0" name="Word_Size" origin="GNAT RM" category="variable">
|
||
|
||
<DOC>`Standard'Word_Size' (`Standard' is the only allowed prefix) provides
|
||
the value `System.Word_Size'. The result is a static constant.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="165" name="Class'Output" origin="Ada RM" category="procedure">
|
||
|
||
<DOC>For every subtype S'Class of a class-wide type T'Class:
|
||
|
||
|
||
S'Class'Output denotes a procedure with the following
|
||
specification:
|
||
|
||
|
||
procedure S'Class'Output(
|
||
Stream : not null access Ada.Streams.Root_Stream_Type'Class;
|
||
Item : in T'Class)
|
||
|
||
|
||
First writes the external tag of Item to Stream (by calling
|
||
String'Output(Stream, Tags.External_Tag(Item'Tag)) - see 3.9)
|
||
and then dispatches to the subprogram denoted by the Output
|
||
attribute of the specific type identified by the tag.
|
||
Tag_Error is raised if the tag of Item identifies a type
|
||
declared at an accessibility level deeper than that of S. See</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="191" name="Class'Read" origin="Ada RM" category="procedure">
|
||
|
||
<DOC>For every subtype S'Class of a class-wide type T'Class:
|
||
|
||
|
||
S'Class'Read denotes a procedure with the following
|
||
specification:
|
||
|
||
|
||
procedure S'Class'Read(
|
||
Stream : not null access Ada.Streams.Root_Stream_Type'Class;
|
||
Item : out T'Class)
|
||
|
||
|
||
Dispatches to the subprogram denoted by the Read attribute of
|
||
the specific type identified by the tag of Item. See 13.13.2.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="282" name="Class'Write" origin="Ada RM" category="procedure">
|
||
|
||
<DOC>For every subtype S'Class of a class-wide type T'Class:
|
||
|
||
|
||
S'Class'Write denotes a procedure with the following
|
||
specification:
|
||
|
||
|
||
procedure S'Class'Write(
|
||
Stream : not null access Ada.Streams.Root_Stream_Type'Class;
|
||
Item : in T'Class)
|
||
|
||
|
||
Dispatches to the subprogram denoted by the Write attribute of
|
||
the specific type identified by the tag of Item. See 13.13.2.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="100/1" name="Last" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For a prefix A that is of an array type (after any implicit
|
||
dereference), or denotes a constrained array subtype:
|
||
|
||
|
||
A'Last denotes the upper bound of the first index range; its
|
||
type is the corresponding index type. See 3.6.2.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="102" name="Last" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For every scalar subtype S:
|
||
|
||
|
||
S'Last denotes the upper bound of the range of S. The value of
|
||
this attribute is of the type of S. See 3.5.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="104/1" name="Last(N)" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For a prefix A that is of an array type (after any implicit
|
||
dereference), or denotes a constrained array subtype:
|
||
|
||
|
||
A'Last(N) denotes the upper bound of the N-th index range; its
|
||
type is the corresponding index type. See 3.6.2.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="106" name="Last_Bit" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For a component C of a composite, non-array object R:
|
||
|
||
|
||
If the nondefault bit ordering applies to the composite type,
|
||
and if a component_clause specifies the placement of C,
|
||
denotes the value given for the last_bit of the
|
||
component_clause; otherwise, denotes the offset, from the
|
||
start of the first of the storage elements occupied by C, of
|
||
the last bit occupied by C. This offset is measured in bits.
|
||
The value of this attribute is of the type universal_integer.
|
||
See 13.5.2.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="107.1/4" name="Last_Valid" origin="Ada RM" category="unknown">
|
||
|
||
<DOC>For every static discrete subtype S for which there exists at
|
||
least one value belonging to S that satisfies the predicates
|
||
of S:
|
||
|
||
|
||
S'Last_Valid denotes the largest value that belongs to S and
|
||
satisfies the predicates of S. The value of this attribute is
|
||
of the type of S. See 3.5.5.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="108" name="Leading_Part" origin="Ada RM" category="function">
|
||
|
||
<DOC>For every subtype S of a floating point type T:
|
||
|
||
|
||
S'Leading_Part denotes a function with the following
|
||
specification:
|
||
|
||
|
||
function S'Leading_Part (X : T;
|
||
Radix_Digits : universal_integer)
|
||
return T
|
||
|
||
|
||
Let v be the value T'Machine_Radix(k-Radix_Digits), where k is
|
||
the normalized exponent of X. The function yields the value
|
||
|
||
|
||
* Floor(X/v) x v, when X is nonnegative and Radix_Digits is
|
||
positive;
|
||
|
||
|
||
* Ceiling(X/v) x v, when X is negative and Radix_Digits is
|
||
positive.
|
||
|
||
|
||
Constraint_Error is raised when Radix_Digits is zero or
|
||
negative. A zero result, which can only occur when X is zero,
|
||
has the sign of X. See A.5.3.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="115/1" name="Length" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For a prefix A that is of an array type (after any implicit
|
||
dereference), or denotes a constrained array subtype:
|
||
|
||
|
||
A'Length denotes the number of values of the first index range
|
||
(zero for a null range); its type is universal_integer. See</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="117/1" name="Length(N)" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For a prefix A that is of an array type (after any implicit
|
||
dereference), or denotes a constrained array subtype:
|
||
|
||
|
||
A'Length(N) denotes the number of values of the N-th index
|
||
range (zero for a null range); its type is universal_integer.
|
||
See 3.6.2.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="119" name="Machine" origin="Ada RM" category="function">
|
||
|
||
<DOC>For every subtype S of a floating point type T:
|
||
|
||
|
||
S'Machine denotes a function with the following specification:
|
||
|
||
|
||
function S'Machine (X : T)
|
||
return T
|
||
|
||
|
||
If X is a machine number of the type T, the function yields X;
|
||
otherwise, it yields the value obtained by rounding or
|
||
truncating X to either one of the adjacent machine numbers of
|
||
the type T. Constraint_Error is raised if rounding or
|
||
truncating X to the precision of the machine numbers results
|
||
in a value outside the base range of S. A zero result has the
|
||
sign of X when S'Signed_Zeros is True. See A.5.3.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="12" name="Aft" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For every fixed point subtype S:
|
||
|
||
|
||
S'Aft yields the number of decimal digits needed after the
|
||
decimal point to accommodate the delta of the subtype S,
|
||
unless the delta of the subtype S is greater than 0.1, in
|
||
which case the attribute yields the value one. (S'Aft is the
|
||
smallest positive integer N for which (10**N)*S'Delta is
|
||
greater than or equal to one.) The value of this attribute is
|
||
of the type universal_integer. See 3.5.10.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="123" name="Machine_Emax" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For every subtype S of a floating point type T:
|
||
|
||
|
||
Yields the largest (most positive) value of exponent such that
|
||
every value expressible in the canonical form (for the type
|
||
T), having a mantissa of T'Machine_Mantissa digits, is a
|
||
machine number (see 3.5.7) of the type T. This attribute
|
||
yields a value of the type universal_integer. See A.5.3.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="125" name="Machine_Emin" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For every subtype S of a floating point type T:
|
||
|
||
|
||
Yields the smallest (most negative) value of exponent such
|
||
that every value expressible in the canonical form (for the
|
||
type T), having a mantissa of T'Machine_Mantissa digits, is a
|
||
machine number (see 3.5.7) of the type T. This attribute
|
||
yields a value of the type universal_integer. See A.5.3.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="127" name="Machine_Mantissa" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For every subtype S of a floating point type T:
|
||
|
||
|
||
Yields the largest value of p such that every value
|
||
expressible in the canonical form (for the type T), having a
|
||
p-digit mantissa and an exponent between T'Machine_Emin and
|
||
T'Machine_Emax, is a machine number (see 3.5.7) of the type T.
|
||
This attribute yields a value of the type universal_integer.
|
||
See A.5.3.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="129" name="Machine_Overflows" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For every subtype S of a floating point type T:
|
||
|
||
|
||
Yields the value True if overflow and divide-by-zero are
|
||
detected and reported by raising Constraint_Error for every
|
||
predefined operation that yields a result of the type T;
|
||
yields the value False otherwise. The value of this attribute
|
||
is of the predefined type Boolean. See A.5.3.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="13.1/2" name="Alignment" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For every subtype S:
|
||
|
||
|
||
The value of this attribute is of type universal_integer, and
|
||
nonnegative.
|
||
|
||
|
||
For an object X of subtype S, if S'Alignment is not zero, then
|
||
X'Alignment is a nonzero integral multiple of S'Alignment
|
||
unless specified otherwise by a representation item. See</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="131" name="Machine_Overflows" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For every subtype S of a fixed point type T:
|
||
|
||
|
||
Yields the value True if overflow and divide-by-zero are
|
||
detected and reported by raising Constraint_Error for every
|
||
predefined operation that yields a result of the type T;
|
||
yields the value False otherwise. The value of this attribute
|
||
is of the predefined type Boolean. See A.5.4.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="133" name="Machine_Radix" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For every subtype S of a floating point type T:
|
||
|
||
|
||
Yields the radix of the hardware representation of the type T.
|
||
The value of this attribute is of the type universal_integer.
|
||
See A.5.3.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="135" name="Machine_Radix" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For every subtype S of a fixed point type T:
|
||
|
||
|
||
Yields the radix of the hardware representation of the type T.
|
||
The value of this attribute is of the type universal_integer.
|
||
See A.5.4.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="136.1/2" name="Machine_Rounding" origin="Ada RM" category="function">
|
||
|
||
<DOC>For every subtype S of a floating point type T:
|
||
|
||
|
||
S'Machine_Rounding denotes a function with the following
|
||
specification:
|
||
|
||
|
||
function S'Machine_Rounding (X : T)
|
||
return T
|
||
|
||
|
||
The function yields the integral value nearest to X. If X lies
|
||
exactly halfway between two integers, one of those integers is
|
||
returned, but which of them is returned is unspecified. A zero
|
||
result has the sign of X when S'Signed_Zeros is True. This
|
||
function provides access to the rounding behavior which is
|
||
most efficient on the target processor. See A.5.3.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="137" name="Machine_Rounds" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For every subtype S of a floating point type T:
|
||
|
||
|
||
Yields the value True if rounding is performed on inexact
|
||
results of every predefined operation that yields a result of
|
||
the type T; yields the value False otherwise. The value of
|
||
this attribute is of the predefined type Boolean. See A.5.3.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="139" name="Machine_Rounds" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For every subtype S of a fixed point type T:
|
||
|
||
|
||
Yields the value True if rounding is performed on inexact
|
||
results of every predefined operation that yields a result of
|
||
the type T; yields the value False otherwise. The value of
|
||
this attribute is of the predefined type Boolean. See A.5.4.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="14/1" name="Alignment" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For a prefix X that denotes an object:
|
||
|
||
|
||
The value of this attribute is of type universal_integer, and
|
||
nonnegative; zero means that the object is not necessarily
|
||
aligned on a storage element boundary. If X'Alignment is not
|
||
zero, then X is aligned on a storage unit boundary and
|
||
X'Address is an integral multiple of X'Alignment (that is, the
|
||
Address modulo the Alignment is zero).</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="141" name="Max" origin="Ada RM" category="function">
|
||
|
||
<DOC>For every scalar subtype S:
|
||
|
||
|
||
S'Max denotes a function with the following specification:
|
||
|
||
|
||
function S'Max(Left, Right : S'Base)
|
||
return S'Base
|
||
|
||
|
||
The function returns the greater of the values of the two
|
||
parameters. See 3.5.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="144.1/3" name="Max_Alignment_For_Allocation" origin="Ada RM" category="unknown">
|
||
|
||
<DOC>For every subtype S:
|
||
|
||
|
||
Denotes the maximum value for Alignment that can be requested
|
||
by the implementation via Allocate for an access type whose
|
||
designated subtype is S. The value of this attribute is of
|
||
type universal_integer. See 13.11.1.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="145" name="Max_Size_In_Storage_Elements" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For every subtype S:
|
||
|
||
|
||
Denotes the maximum value for Size_In_Storage_Elements that
|
||
can be requested by the implementation via Allocate for an
|
||
access type whose designated subtype is S. The value of this
|
||
attribute is of type universal_integer. See 13.11.1.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="147" name="Min" origin="Ada RM" category="function">
|
||
|
||
<DOC>For every scalar subtype S:
|
||
|
||
|
||
S'Min denotes a function with the following specification:
|
||
|
||
|
||
function S'Min(Left, Right : S'Base)
|
||
return S'Base
|
||
|
||
|
||
The function returns the lesser of the values of the two
|
||
parameters. See 3.5.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="150.1/2" name="Mod" origin="Ada RM" category="function">
|
||
|
||
<DOC>For every modular subtype S:
|
||
|
||
|
||
S'Mod denotes a function with the following specification:
|
||
|
||
|
||
function S'Mod (Arg : universal_integer)
|
||
return S'Base
|
||
|
||
|
||
This function returns Arg mod S'Modulus, as a value of the
|
||
type of S. See 3.5.4.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="151" name="Model" origin="Ada RM" category="function">
|
||
|
||
<DOC>For every subtype S of a floating point type T:
|
||
|
||
|
||
S'Model denotes a function with the following specification:
|
||
|
||
|
||
function S'Model (X : T)
|
||
return T
|
||
|
||
|
||
If the Numerics Annex is not supported, the meaning of this
|
||
attribute is implementation defined; see G.2.2 for the
|
||
definition that applies to implementations supporting the
|
||
Numerics Annex. See A.5.3.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="155" name="Model_Emin" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For every subtype S of a floating point type T:
|
||
|
||
|
||
If the Numerics Annex is not supported, this attribute yields
|
||
an implementation defined value that is greater than or equal
|
||
to the value of T'Machine_Emin. See G.2.2 for further
|
||
requirements that apply to implementations supporting the
|
||
Numerics Annex. The value of this attribute is of the type
|
||
universal_integer. See A.5.3.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="157" name="Model_Epsilon" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For every subtype S of a floating point type T:
|
||
|
||
|
||
Yields the value T'Machine_Radix(1 - T'Model_Mantissa). The
|
||
value of this attribute is of the type universal_real. See
|
||
A.5.3.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="159" name="Model_Mantissa" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For every subtype S of a floating point type T:
|
||
|
||
|
||
If the Numerics Annex is not supported, this attribute yields
|
||
an implementation defined value that is greater than or equal
|
||
to Ceiling(d x log(10) / log(T'Machine_Radix)) + 1, where d is
|
||
the requested decimal precision of T, and less than or equal
|
||
to the value of T'Machine_Mantissa. See G.2.2 for further
|
||
requirements that apply to implementations supporting the
|
||
Numerics Annex. The value of this attribute is of the type
|
||
universal_integer. See A.5.3.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="161" name="Model_Small" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For every subtype S of a floating point type T:
|
||
|
||
|
||
Yields the value T'Machine_Radix(T'Model_Emin - 1). The value
|
||
of this attribute is of the type universal_real. See A.5.3.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="163" name="Modulus" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For every modular subtype S:
|
||
|
||
|
||
S'Modulus yields the modulus of the type of S, as a value of
|
||
the type universal_integer. See 3.5.4.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="164.1/5" name="Object_Size" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For every subtype S:
|
||
|
||
|
||
If S is definite, denotes the size (in bits) of a stand-alone
|
||
aliased object, or a component of subtype S in the absence of
|
||
an aspect_specification or representation item that specifies
|
||
the size of the object or component. If S is indefinite, the
|
||
meaning is implementation-defined. The value of this attribute
|
||
is of the type universal_integer. See 13.3.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="164.3/3" name="Old" origin="Ada RM" category="unknown">
|
||
|
||
<DOC>For a prefix X that denotes an object of a nonlimited type:
|
||
|
||
|
||
Each X'Old in a postcondition expression that is enabled,
|
||
other than those that occur in subexpressions that are
|
||
determined to be unevaluated, denotes a constant that is
|
||
implicitly declared at the beginning of the subprogram body,
|
||
entry body, or accept statement. See 6.1.1.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="169" name="Output" origin="Ada RM" category="procedure">
|
||
|
||
<DOC>For every subtype S of a specific type T:
|
||
|
||
|
||
S'Output denotes a procedure with the following specification:
|
||
|
||
|
||
procedure S'Output(
|
||
Stream : not null access Ada.Streams.Root_Stream_Type'Class;
|
||
Item : in T)
|
||
|
||
|
||
S'Output writes the value of Item to Stream, including any
|
||
bounds or discriminants. See 13.13.2.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="17" name="Base" origin="Ada RM" category="type">
|
||
|
||
<DOC>For every scalar subtype S:
|
||
|
||
|
||
S'Base denotes an unconstrained subtype of the type of S. This
|
||
unconstrained subtype is called the base subtype of the type.
|
||
See 3.5.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="172.1/3" name="Overlaps_Storage" origin="Ada RM" category="unknown">
|
||
|
||
<DOC>For a prefix X that denotes an object:
|
||
|
||
|
||
X'Overlaps_Storage denotes a function with the following
|
||
specification:
|
||
|
||
|
||
function X'Overlaps_Storage (Arg : any_type)
|
||
return Boolean
|
||
|
||
|
||
The actual parameter shall be a name that denotes an object.
|
||
The object denoted by the actual parameter can be of any type.
|
||
This function evaluates the names of the objects involved and
|
||
returns True if the representation of the object denoted by
|
||
the actual parameter shares at least one bit with the
|
||
representation of the object denoted by X; otherwise, it
|
||
returns False. See 13.3.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="172.5/5" name="Parallel_Reduce(Reducer" origin="Ada RM" category="variable">
|
||
|
||
<DOC>, Initial_Value)
|
||
For a prefix X of an array type (after any implicit
|
||
dereference), or that denotes an iterable container object
|
||
(see 5.5.1):
|
||
|
||
|
||
X'Parallel_Reduce is a reduction expression that yields a
|
||
result equivalent to replacing the attribute identifier with
|
||
Reduce and the prefix of the attribute with the
|
||
value_sequence:
|
||
|
||
|
||
[parallel for Item of X => Item]
|
||
|
||
|
||
See 4.5.10.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="173/1" name="Partition_Id" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For a prefix D that denotes a library-level declaration,
|
||
excepting a declaration of or within a declared-pure library
|
||
unit:
|
||
|
||
|
||
Denotes a value of the type universal_integer that identifies
|
||
the partition in which D was elaborated. If D denotes the
|
||
declaration of a remote call interface library unit (see
|
||
E.2.3) the given partition is the one where the body of D was
|
||
elaborated. See E.1.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="175" name="Pos" origin="Ada RM" category="function">
|
||
|
||
<DOC>For every discrete subtype S:
|
||
|
||
|
||
S'Pos denotes a function with the following specification:
|
||
|
||
|
||
function S'Pos(Arg : S'Base)
|
||
return universal_integer
|
||
|
||
|
||
This function returns the position number of the value of Arg,
|
||
as a value of type universal_integer. See 3.5.5.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="179" name="Position" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For a component C of a composite, non-array object R:
|
||
|
||
|
||
If the nondefault bit ordering applies to the composite type,
|
||
and if a component_clause specifies the placement of C,
|
||
denotes the value given for the position of the
|
||
component_clause; otherwise, denotes the same value as
|
||
R.C'Address - R'Address. The value of this attribute is of the
|
||
type universal_integer. See 13.5.2.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="181" name="Pred" origin="Ada RM" category="function">
|
||
|
||
<DOC>For every scalar subtype S:
|
||
|
||
|
||
S'Pred denotes a function with the following specification:
|
||
|
||
|
||
function S'Pred(Arg : S'Base)
|
||
return S'Base
|
||
|
||
|
||
For an enumeration type, the function returns the value whose
|
||
position number is one less than that of the value of Arg;
|
||
Constraint_Error is raised if there is no such value of the
|
||
type. For an integer type, the function returns the result of
|
||
subtracting one from the value of Arg. For a fixed point type,
|
||
the function returns the result of subtracting small from the
|
||
value of Arg. For a floating point type, the function returns
|
||
the machine number (as defined in 3.5.7) immediately below the
|
||
value of Arg; Constraint_Error is raised if there is no such
|
||
machine number. See 3.5.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="184.1/5" name="Preelaborable_Initialization" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For a nonformal composite subtype S declared within the
|
||
visible part of a package or a generic package, or a generic
|
||
formal private subtype or formal derived subtype:
|
||
|
||
|
||
This attribute is of Boolean type, and its value reflects
|
||
whether the type of S has preelaborable initialization. See</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="184.3/2" name="Priority" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For a prefix P that denotes a protected object:
|
||
|
||
|
||
Denotes a non-aliased component of the protected object P.
|
||
This component is of type System.Any_Priority and its value is
|
||
the priority of P. P'Priority denotes a variable if and only
|
||
if P denotes a variable. A reference to this attribute shall
|
||
appear only within the body of P. See D.5.2.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="184.5/5" name="Put_Image" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For every subtype S of a type T other than universal_real or
|
||
universal_fixed:
|
||
|
||
|
||
S'Put_Image denotes a procedure with the following
|
||
specification:
|
||
|
||
|
||
procedure S'Put_Image
|
||
(Buffer : in out
|
||
Ada.Strings.Text_Buffers.Root_Buffer_Type'Class;
|
||
Arg : in T);
|
||
|
||
|
||
The default implementation of S'Put_Image writes (using
|
||
Wide_Wide_Put) an image of the value of Arg. See 4.10.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="185/1" name="Range" origin="Ada RM" category="type">
|
||
|
||
<DOC>For a prefix A that is of an array type (after any implicit
|
||
dereference), or denotes a constrained array subtype:
|
||
|
||
|
||
A'Range is equivalent to the range A'First .. A'Last, except
|
||
that the prefix A is only evaluated once. See 3.6.2.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="187" name="Range" origin="Ada RM" category="type">
|
||
|
||
<DOC>For every scalar subtype S:
|
||
|
||
|
||
S'Range is equivalent to the range S'First .. S'Last. See</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="189/1" name="Range(N)" origin="Ada RM" category="type">
|
||
|
||
<DOC>For a prefix A that is of an array type (after any implicit
|
||
dereference), or denotes a constrained array subtype:
|
||
|
||
|
||
A'Range(N) is equivalent to the range A'First(N) .. A'Last(N),
|
||
except that the prefix A is only evaluated once. See 3.6.2.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="19" name="Bit_Order" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For every specific record subtype S:
|
||
|
||
|
||
Denotes the bit ordering for the type of S. The value of this
|
||
attribute is of type System.Bit_Order. See 13.5.3.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="195" name="Read" origin="Ada RM" category="procedure">
|
||
|
||
<DOC>For every subtype S of a specific type T:
|
||
|
||
|
||
S'Read denotes a procedure with the following specification:
|
||
|
||
|
||
procedure S'Read(
|
||
Stream : not null access Ada.Streams.Root_Stream_Type'Class;
|
||
Item : out T)
|
||
|
||
|
||
S'Read reads the value of Item from Stream. See 13.13.2.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="198.1/5" name="Reduce(Reducer" origin="Ada RM" category="variable">
|
||
|
||
<DOC>, Initial_Value)
|
||
For a value_sequence V:
|
||
|
||
|
||
This attribute represents a reduction expression, and is in
|
||
the form of a reduction_attribute_reference. See 4.5.10.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="198.3/5" name="Reduce(Reducer" origin="Ada RM" category="variable">
|
||
|
||
<DOC>, Initial_Value)
|
||
For a prefix X of an array type (after any implicit
|
||
dereference), or that denotes an iterable container object
|
||
(see 5.5.1):
|
||
|
||
|
||
X'Reduce is a reduction expression that yields a result
|
||
equivalent to replacing the prefix of the attribute with the
|
||
value_sequence:
|
||
|
||
|
||
[for Item of X => Item]
|
||
|
||
|
||
See 4.5.10.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="198.7/5" name="Relative_Deadline" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For a prefix P that denotes a protected object:
|
||
|
||
|
||
Denotes a non-aliased component of the protected object P.
|
||
This component is of type Ada.Real_Time.Time_Span and its
|
||
value is the relative deadline of P. P'Relative_Deadline
|
||
denotes a variable if and only if P denotes a variable. A
|
||
reference to this attribute shall appear only within the body
|
||
of P. See D.5.2.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="199" name="Remainder" origin="Ada RM" category="function">
|
||
|
||
<DOC>For every subtype S of a floating point type T:
|
||
|
||
|
||
S'Remainder denotes a function with the following
|
||
specification:
|
||
|
||
|
||
function S'Remainder (X, Y : T)
|
||
return T
|
||
|
||
|
||
For nonzero Y, let v be the value X - n x Y, where n is the
|
||
integer nearest to the exact value of X/Y; if |n - X/Y| = 1/2,
|
||
then n is chosen to be even. If v is a machine number of the
|
||
type T, the function yields v; otherwise, it yields zero.
|
||
Constraint_Error is raised if Y is zero. A zero result has the
|
||
sign of X when S'Signed_Zeros is True. See A.5.3.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="2" name="Access" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For a prefix P that denotes a subprogram:
|
||
|
||
|
||
P'Access yields an access value that designates the subprogram
|
||
denoted by P. The type of P'Access is an access-to-subprogram
|
||
type (S), as determined by the expected type. See 3.10.2.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="202.1/3" name="Result" origin="Ada RM" category="unknown">
|
||
|
||
<DOC>For a prefix F that denotes a function declaration or an
|
||
access-to-function type:
|
||
|
||
|
||
Within a postcondition expression for F, denotes the return
|
||
object of the function call for which the postcondition
|
||
expression is evaluated. The type of this attribute is that of
|
||
the result subtype of the function or access-to-function type
|
||
except within a Post'Class postcondition expression for a
|
||
function with a controlling result or with a controlling
|
||
access result; in those cases the type of the attribute is
|
||
described above as part of the Name Resolution Rules for
|
||
Post'Class. See 6.1.1.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="203" name="Round" origin="Ada RM" category="function">
|
||
|
||
<DOC>For every decimal fixed point subtype S:
|
||
|
||
|
||
S'Round denotes a function with the following specification:
|
||
|
||
|
||
function S'Round(X : universal_real)
|
||
return S'Base
|
||
|
||
|
||
The function returns the value obtained by rounding X (away
|
||
from 0, if X is midway between two values of the type of S).
|
||
See 3.5.10.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="207" name="Rounding" origin="Ada RM" category="function">
|
||
|
||
<DOC>For every subtype S of a floating point type T:
|
||
|
||
|
||
S'Rounding denotes a function with the following
|
||
specification:
|
||
|
||
|
||
function S'Rounding (X : T)
|
||
return T
|
||
|
||
|
||
The function yields the integral value nearest to X, rounding
|
||
away from zero if X lies exactly halfway between two integers.
|
||
A zero result has the sign of X when S'Signed_Zeros is True.
|
||
See A.5.3.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="21/1" name="Body_Version" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For a prefix P that statically denotes a program unit:
|
||
|
||
|
||
Yields a value of the predefined type String that identifies
|
||
the version of the compilation unit that contains the body
|
||
(but not any subunits) of the program unit. See E.3.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="211" name="Safe_First" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For every subtype S of a floating point type T:
|
||
|
||
|
||
Yields the lower bound of the safe range (see 3.5.7) of the
|
||
type T. If the Numerics Annex is not supported, the value of
|
||
this attribute is implementation defined; see G.2.2 for the
|
||
definition that applies to implementations supporting the
|
||
Numerics Annex. The value of this attribute is of the type
|
||
universal_real. See A.5.3.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="213" name="Safe_Last" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For every subtype S of a floating point type T:
|
||
|
||
|
||
Yields the upper bound of the safe range (see 3.5.7) of the
|
||
type T. If the Numerics Annex is not supported, the value of
|
||
this attribute is implementation defined; see G.2.2 for the
|
||
definition that applies to implementations supporting the
|
||
Numerics Annex. The value of this attribute is of the type
|
||
universal_real. See A.5.3.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="215" name="Scale" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For every decimal fixed point subtype S:
|
||
|
||
|
||
S'Scale denotes the scale of the subtype S, defined as the
|
||
value N such that S'Delta = 10.0**(-N). The scale indicates
|
||
the position of the point relative to the rightmost
|
||
significant digits of values of subtype S. The value of this
|
||
attribute is of the type universal_integer. See 3.5.10.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="217" name="Scaling" origin="Ada RM" category="function">
|
||
|
||
<DOC>For every subtype S of a floating point type T:
|
||
|
||
|
||
S'Scaling denotes a function with the following specification:
|
||
|
||
|
||
function S'Scaling (X : T;
|
||
Adjustment : universal_integer)
|
||
return T
|
||
|
||
|
||
Let v be the value X x T'Machine_Radix(Adjustment). If v is a
|
||
machine number of the type T, or if |v| >= T'Model_Small, the
|
||
function yields v; otherwise, it yields either one of the
|
||
machine numbers of the type T adjacent to v. Constraint_Error
|
||
is optionally raised if v is outside the base range of S. A
|
||
zero result has the sign of X when S'Signed_Zeros is True. See
|
||
A.5.3.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="221" name="Signed_Zeros" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For every subtype S of a floating point type T:
|
||
|
||
|
||
Yields the value True if the hardware representation for the
|
||
type T has the capability of representing both positively and
|
||
negatively signed zeros, these being generated and used by the
|
||
predefined operations of the type T as specified in IEC
|
||
:1989; yields the value False otherwise. The value of this
|
||
attribute is of the predefined type Boolean. See A.5.3.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="223" name="Size" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For every subtype S:
|
||
|
||
|
||
If S is definite, denotes the size (in bits) that the
|
||
implementation would choose for the following objects of
|
||
subtype S:
|
||
|
||
|
||
* A record component of subtype S when the record type is
|
||
packed.
|
||
|
||
|
||
* The formal parameter of an instance of
|
||
Unchecked_Conversion that converts from subtype S to some
|
||
other subtype.
|
||
|
||
|
||
If S is indefinite, the meaning is implementation defined. The
|
||
value of this attribute is of the type universal_integer. See</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="228/1" name="Size" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For a prefix X that denotes an object:
|
||
|
||
|
||
Denotes the size in bits of the representation of the object.
|
||
The value of this attribute is of the type universal_integer.
|
||
See 13.3.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="23" name="Callable" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For a prefix T that is of a task type (after any implicit
|
||
dereference):
|
||
|
||
|
||
Yields the value True when the task denoted by T is callable,
|
||
and False otherwise; See 9.9.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="230" name="Small" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For every fixed point subtype S:
|
||
|
||
|
||
S'Small denotes the small of the type of S. The value of this
|
||
attribute is of the type universal_real. See 3.5.10.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="232" name="Storage_Pool" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For every access-to-object subtype S:
|
||
|
||
|
||
Denotes the storage pool of the type of S. The type of this
|
||
attribute is Root_Storage_Pool'Class. See 13.11.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="234" name="Storage_Size" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For every access-to-object subtype S:
|
||
|
||
|
||
Yields the result of calling Storage_Size(S'Storage_Pool),
|
||
which is intended to be a measure of the number of storage
|
||
elements reserved for the pool. The type of this attribute is
|
||
universal_integer. See 13.11.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="236/1" name="Storage_Size" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For a prefix T that denotes a task object (after any implicit
|
||
dereference):
|
||
|
||
|
||
Denotes the number of storage elements reserved for the task.
|
||
The value of this attribute is of the type universal_integer.
|
||
The Storage_Size includes the size of the task's stack, if
|
||
any. The language does not specify whether or not it includes
|
||
other storage associated with the task (such as the "task
|
||
control block" used by some implementations.) See 13.3.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="237.1/2" name="Stream_Size" origin="Ada RM" category="unknown">
|
||
|
||
<DOC>For every subtype S of an elementary type T:
|
||
|
||
|
||
Denotes the number of bits read from or written to a stream by
|
||
the default implementations of S'Read and S'Write. Hence, the
|
||
number of stream elements required per item of elementary type
|
||
T is:
|
||
|
||
|
||
T'Stream_Size / Ada.Streams.Stream_Element'Size
|
||
|
||
|
||
The value of this attribute is of type universal_integer and
|
||
is a multiple of Stream_Element'Size. See 13.13.2.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="238" name="Succ" origin="Ada RM" category="function">
|
||
|
||
<DOC>For every scalar subtype S:
|
||
|
||
|
||
S'Succ denotes a function with the following specification:
|
||
|
||
|
||
function S'Succ(Arg : S'Base)
|
||
return S'Base
|
||
|
||
|
||
For an enumeration type, the function returns the value whose
|
||
position number is one more than that of the value of Arg;
|
||
Constraint_Error is raised if there is no such value of the
|
||
type. For an integer type, the function returns the result of
|
||
adding one to the value of Arg. For a fixed point type, the
|
||
function returns the result of adding small to the value of
|
||
Arg. For a floating point type, the function returns the
|
||
machine number (as defined in 3.5.7) immediately above the
|
||
value of Arg; Constraint_Error is raised if there is no such
|
||
machine number. See 3.5.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="242" name="Tag" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For every subtype S of a tagged type T (specific or
|
||
class-wide):
|
||
|
||
|
||
S'Tag denotes the tag of the type T (or if T is class-wide,
|
||
the tag of the root type of the corresponding class). The
|
||
value of this attribute is of type Tag. See 3.9.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="244" name="Tag" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For a prefix X that is of a class-wide tagged type (after any
|
||
implicit dereference):
|
||
|
||
|
||
X'Tag denotes the tag of X. The value of this attribute is of
|
||
type Tag. See 3.9.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="246" name="Terminated" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For a prefix T that is of a task type (after any implicit
|
||
dereference):
|
||
|
||
|
||
Yields the value True if the task denoted by T is terminated,
|
||
and False otherwise. The value of this attribute is of the
|
||
predefined type Boolean. See 9.9.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="248" name="Truncation" origin="Ada RM" category="function">
|
||
|
||
<DOC>For every subtype S of a floating point type T:
|
||
|
||
|
||
S'Truncation denotes a function with the following
|
||
specification:
|
||
|
||
|
||
function S'Truncation (X : T)
|
||
return T
|
||
|
||
|
||
The function yields the value Ceiling(X) when X is negative,
|
||
and Floor(X) otherwise. A zero result has the sign of X when
|
||
S'Signed_Zeros is True. See A.5.3.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="25" name="Caller" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For a prefix E that denotes an entry_declaration:
|
||
|
||
|
||
Yields a value of the type Task_Id that identifies the task
|
||
whose call is now being serviced. Use of this attribute is
|
||
allowed only inside an accept_statement, or entry_body after
|
||
the entry_barrier, corresponding to the entry_declaration
|
||
denoted by E. See C.7.1.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="252" name="Unbiased_Rounding" origin="Ada RM" category="function">
|
||
|
||
<DOC>For every subtype S of a floating point type T:
|
||
|
||
|
||
S'Unbiased_Rounding denotes a function with the following
|
||
specification:
|
||
|
||
|
||
function S'Unbiased_Rounding (X : T)
|
||
return T
|
||
|
||
|
||
The function yields the integral value nearest to X, rounding
|
||
toward the even integer if X lies exactly halfway between two
|
||
integers. A zero result has the sign of X when S'Signed_Zeros
|
||
is True. See A.5.3.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="256" name="Unchecked_Access" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For a prefix X that denotes an aliased view of an object:
|
||
|
||
|
||
All rules and semantics that apply to X'Access (see 3.10.2)
|
||
apply also to X'Unchecked_Access, except that, for the
|
||
purposes of accessibility rules and checks, it is as if X were
|
||
declared immediately within a library package. See 13.10.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="258" name="Val" origin="Ada RM" category="function">
|
||
|
||
<DOC>For every discrete subtype S:
|
||
|
||
|
||
S'Val denotes a function with the following specification:
|
||
|
||
|
||
function S'Val(Arg : universal_integer)
|
||
return S'Base
|
||
|
||
|
||
This function returns a value of the type of S whose position
|
||
number equals the value of Arg. See 3.5.5.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="262" name="Valid" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For a prefix X that denotes a scalar object (after any
|
||
implicit dereference):
|
||
|
||
|
||
Yields True if and only if the object denoted by X is normal,
|
||
has a valid representation, and then, if the preceding
|
||
conditions hold, the value of X also satisfies the predicates
|
||
of the nominal subtype of X. The value of this attribute is of
|
||
the predefined type Boolean. See 13.9.2.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="264" name="Value" origin="Ada RM" category="function">
|
||
|
||
<DOC>For every scalar subtype S:
|
||
|
||
|
||
S'Value denotes a function with the following specification:
|
||
|
||
|
||
function S'Value(Arg : String)
|
||
return S'Base
|
||
|
||
|
||
This function returns a value given an image of the value as a
|
||
String, ignoring any leading or trailing spaces. See 3.5.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="268/1" name="Version" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For a prefix P that statically denotes a program unit:
|
||
|
||
|
||
Yields a value of the predefined type String that identifies
|
||
the version of the compilation unit that contains the
|
||
declaration of the program unit. See E.3.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="27" name="Ceiling" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For every subtype S of a floating point type T:
|
||
|
||
|
||
S'Ceiling denotes a function with the following specification:
|
||
|
||
|
||
function S'Ceiling (X : T)
|
||
return T
|
||
|
||
|
||
The function yields the value Ceiling(X), that is, the
|
||
smallest (most negative) integral value greater than or equal
|
||
to X. When X is zero, the result has the sign of X; a zero
|
||
result otherwise has a negative sign when S'Signed_Zeros is
|
||
True. See A.5.3.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="270" name="Wide_Image" origin="Ada RM" category="function">
|
||
|
||
<DOC>For every subtype S of a type T:
|
||
|
||
|
||
S'Wide_Image denotes a function with the following
|
||
specification:
|
||
|
||
|
||
function S'Wide_Image(Arg : S'Base)
|
||
return Wide_String
|
||
|
||
|
||
S'Wide_Image calls S'Put_Image passing Arg (which will
|
||
typically store a sequence of character values in a text
|
||
buffer) and then returns the result of retrieving the contents
|
||
of that buffer with function Wide_Get. See 4.10.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="273.1/5" name="Wide_Image" origin="Ada RM" category="function">
|
||
|
||
<DOC>For a prefix X of a type T other than universal_real or
|
||
universal_fixed:
|
||
|
||
|
||
X'Wide_Image denotes the result of calling function
|
||
S'Wide_Image with Arg being X, where S is the nominal subtype
|
||
of X. See 4.10.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="274" name="Wide_Value" origin="Ada RM" category="function">
|
||
|
||
<DOC>For every scalar subtype S:
|
||
|
||
|
||
S'Wide_Value denotes a function with the following
|
||
specification:
|
||
|
||
|
||
function S'Wide_Value(Arg : Wide_String)
|
||
return S'Base
|
||
|
||
|
||
This function returns a value given an image of the value as a
|
||
Wide_String, ignoring any leading or trailing spaces. See</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="277.1/2" name="Wide_Wide_Image" origin="Ada RM" category="function">
|
||
|
||
<DOC>For every subtype S of a type T:
|
||
|
||
|
||
S'Wide_Wide_Image denotes a function with the following
|
||
specification:
|
||
|
||
|
||
function S'Wide_Wide_Image(Arg : S'Base)
|
||
return Wide_Wide_String
|
||
|
||
|
||
S'Wide_Wide_Image calls S'Put_Image passing Arg (which will
|
||
typically store a sequence of character values in a text
|
||
buffer) and then returns the result of retrieving the contents
|
||
of that buffer with function Wide_Wide_Get. See 4.10.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="277.11/2" name="Wide_Wide_Width" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For every scalar subtype S:
|
||
|
||
|
||
S'Wide_Wide_Width denotes the maximum length of a
|
||
Wide_Wide_String returned by S'Wide_Wide_Image over all values
|
||
of the subtype S, assuming a default implementation of
|
||
S'Put_Image. It denotes zero for a subtype that has a null
|
||
range. Its type is universal_integer. See 3.5.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="277.5/5" name="Wide_Wide_Image" origin="Ada RM" category="function">
|
||
|
||
<DOC>For a prefix X of a type T other than universal_real or
|
||
universal_fixed:
|
||
|
||
|
||
X'Wide_Wide_Image denotes the result of calling function
|
||
S'Wide_Wide_Image with Arg being X, where S is the nominal
|
||
subtype of X. See 4.10.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="277.7/2" name="Wide_Wide_Value" origin="Ada RM" category="function">
|
||
|
||
<DOC>For every scalar subtype S:
|
||
|
||
|
||
S'Wide_Wide_Value denotes a function with the following
|
||
specification:
|
||
|
||
|
||
function S'Wide_Wide_Value(Arg : Wide_Wide_String)
|
||
return S'Base
|
||
|
||
|
||
This function returns a value given an image of the value as a
|
||
Wide_Wide_String, ignoring any leading or trailing spaces. See</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="278" name="Wide_Width" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For every scalar subtype S:
|
||
|
||
|
||
S'Wide_Width denotes the maximum length of a Wide_String
|
||
returned by S'Wide_Image over all values of the subtype S,
|
||
assuming a default implementation of S'Put_Image. It denotes
|
||
zero for a subtype that has a null range. Its type is
|
||
universal_integer. See 3.5.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="280" name="Width" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For every scalar subtype S:
|
||
|
||
|
||
S'Width denotes the maximum length of a String returned by
|
||
S'Image over all values of the subtype S, assuming a default
|
||
implementation of S'Put_Image. It denotes zero for a subtype
|
||
that has a null range. Its type is universal_integer. See</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="286" name="Write" origin="Ada RM" category="procedure">
|
||
|
||
<DOC>For every subtype S of a specific type T:
|
||
|
||
|
||
S'Write denotes a procedure with the following specification:
|
||
|
||
|
||
procedure S'Write(
|
||
Stream : not null access Ada.Streams.Root_Stream_Type'Class;
|
||
Item : in T)
|
||
|
||
|
||
S'Write writes the value of Item to Stream. See 13.13.2.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="31" name="Class" origin="Ada RM" category="unknown">
|
||
|
||
<DOC>For every subtype S of a tagged type T (specific or
|
||
class-wide):
|
||
|
||
|
||
S'Class denotes a subtype of the class-wide type (called
|
||
T'Class in this document) for the class rooted at T (or if S
|
||
already denotes a class-wide subtype, then S'Class is the same
|
||
as S).
|
||
|
||
|
||
S'Class is unconstrained. However, if S is constrained, then
|
||
the values of S'Class are only those that when converted to
|
||
the type T belong to S. See 3.9.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="34" name="Class" origin="Ada RM" category="unknown">
|
||
|
||
<DOC>For every subtype S of an untagged private type whose full
|
||
view is tagged:
|
||
|
||
|
||
Denotes the class-wide subtype corresponding to the full view
|
||
of S. This attribute is allowed only from the beginning of the
|
||
private part in which the full view is declared, until the
|
||
declaration of the full view. After the full view, the Class
|
||
attribute of the full view can be used. See 7.3.1.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="92" name="Class'Input" origin="Ada RM" category="function">
|
||
|
||
<DOC>For every subtype S'Class of a class-wide type T'Class:
|
||
|
||
|
||
S'Class'Input denotes a function with the following
|
||
specification:
|
||
|
||
|
||
function S'Class'Input(
|
||
Stream : not null access Ada.Streams.Root_Stream_Type'Class)
|
||
return T'Class
|
||
|
||
|
||
First reads the external tag from Stream and determines the
|
||
corresponding internal tag (by calling
|
||
Tags.Descendant_Tag(String'Input(Stream), S'Tag) which can
|
||
raise Tag_Error - see 3.9) and then dispatches to the
|
||
subprogram denoted by the Input attribute of the specific type
|
||
identified by the internal tag; returns that result. If the
|
||
specific type identified by the internal tag is abstract,
|
||
Constraint_Error is raised. See 13.13.2.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="36/1" name="Component_Size" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For a prefix X that denotes an array subtype or array object
|
||
(after any implicit dereference):
|
||
|
||
|
||
Denotes the size in bits of components of the type of X. The
|
||
value of this attribute is of type universal_integer. See</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="38" name="Compose" origin="Ada RM" category="function">
|
||
|
||
<DOC>For every subtype S of a floating point type T:
|
||
|
||
|
||
S'Compose denotes a function with the following specification:
|
||
|
||
|
||
function S'Compose (Fraction : T;
|
||
Exponent : universal_integer)
|
||
return T
|
||
|
||
|
||
Let v be the value Fraction x T'Machine_Radix(Exponent-k),
|
||
where k is the normalized exponent of Fraction. If v is a
|
||
machine number of the type T, or if |v| >= T'Model_Small, the
|
||
function yields v; otherwise, it yields either one of the
|
||
machine numbers of the type T adjacent to v. Constraint_Error
|
||
is optionally raised if v is outside the base range of S. A
|
||
zero result has the sign of Fraction when S'Signed_Zeros is
|
||
True. See A.5.3.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="4" name="Access" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For a prefix X that denotes an aliased view of an object:
|
||
|
||
|
||
X'Access yields an access value that designates the object
|
||
denoted by X. The type of X'Access is an access-to-object
|
||
type, as determined by the expected type. The expected type
|
||
shall be a general access type. See 3.10.2.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="42" name="Constrained" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For a prefix A that is of a discriminated type (after any
|
||
implicit dereference):
|
||
|
||
|
||
Yields the value True if A denotes a constant, a value, a
|
||
tagged object, or a constrained variable, and False otherwise.
|
||
The value of this attribute is of the predefined type Boolean.
|
||
See 3.7.2.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="44" name="Copy_Sign" origin="Ada RM" category="function">
|
||
|
||
<DOC>For every subtype S of a floating point type T:
|
||
|
||
|
||
S'Copy_Sign denotes a function with the following
|
||
specification:
|
||
|
||
|
||
function S'Copy_Sign (Value, Sign : T)
|
||
return T
|
||
|
||
|
||
If the value of Value is nonzero, the function yields a result
|
||
whose magnitude is that of Value and whose sign is that of
|
||
Sign; otherwise, it yields the value zero. Constraint_Error is
|
||
optionally raised if the result is outside the base range of
|
||
S. A zero result has the sign of Sign when S'Signed_Zeros is
|
||
True. See A.5.3.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="48" name="Count" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For a prefix E that denotes an entry of a task or protected
|
||
unit:
|
||
|
||
|
||
Yields the number of calls presently queued on the entry E of
|
||
the current instance of the unit. The value of this attribute
|
||
is of the type universal_integer. See 9.9.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="50/1" name="Definite" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For a prefix S that denotes a formal indefinite subtype:
|
||
|
||
|
||
S'Definite yields True if the actual subtype corresponding to
|
||
S is definite; otherwise, it yields False. The value of this
|
||
attribute is of the predefined type Boolean. See 12.5.1.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="52" name="Delta" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For every fixed point subtype S:
|
||
|
||
|
||
S'Delta denotes the delta of the fixed point subtype S. The
|
||
value of this attribute is of the type universal_real. See</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="54" name="Denorm" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For every subtype S of a floating point type T:
|
||
|
||
|
||
Yields the value True if every value expressible in the form
|
||
+- mantissa x T'Machine_Radix(T'Machine_Emin)
|
||
where mantissa is a nonzero T'Machine_Mantissa-digit fraction
|
||
in the number base T'Machine_Radix, the first digit of which
|
||
is zero, is a machine number (see 3.5.7) of the type T; yields
|
||
the value False otherwise. The value of this attribute is of
|
||
the predefined type Boolean. See A.5.3.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="56" name="Digits" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For every floating point subtype S:
|
||
|
||
|
||
S'Digits denotes the requested decimal precision for the
|
||
subtype S. The value of this attribute is of the type
|
||
universal_integer. See 3.5.8.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="58" name="Digits" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For every decimal fixed point subtype S:
|
||
|
||
|
||
S'Digits denotes the digits of the decimal fixed point subtype
|
||
S, which corresponds to the number of decimal digits that are
|
||
representable in objects of the subtype. The value of this
|
||
attribute is of the type universal_integer. See 3.5.10.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="59.1/5" name="Enum_Rep" origin="Ada RM" category="function">
|
||
|
||
<DOC>For every discrete subtype S:
|
||
|
||
|
||
S'Enum_Rep denotes a function with the following
|
||
specification:
|
||
|
||
|
||
function S'Enum_Rep (Arg : S'Base) return universal_integer
|
||
|
||
|
||
This function returns the representation value of the value of
|
||
Arg, as a value of type universal_integer. The representation
|
||
value is the internal code specified in an enumeration
|
||
representation clause, if any, for the type corresponding to
|
||
the value of Arg, and otherwise is the position number of the
|
||
value. See 13.4.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="59.5/5" name="Enum_Val" origin="Ada RM" category="function">
|
||
|
||
<DOC>For every discrete subtype S:
|
||
|
||
|
||
S'Enum_Val denotes a function with the following
|
||
specification:
|
||
|
||
|
||
function S'Enum_Val (Arg : universal_integer) return S'Base
|
||
|
||
|
||
This function returns a value of the type of S whose
|
||
representation value equals the value of Arg. For the
|
||
evaluation of a call on S'Enum_Val, if there is no value in
|
||
the base range of its type with the given representation
|
||
value, Constraint_Error is raised. See 13.4.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="6/1" name="Address" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For a prefix X that denotes an object, program unit, or label:
|
||
|
||
|
||
Denotes the address of the first of the storage elements
|
||
allocated to X. For a program unit or label, this value refers
|
||
to the machine code associated with the corresponding body or
|
||
statement. The value of this attribute is of type
|
||
System.Address. See 13.3.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="60" name="Exponent" origin="Ada RM" category="function">
|
||
|
||
<DOC>For every subtype S of a floating point type T:
|
||
|
||
|
||
S'Exponent denotes a function with the following
|
||
specification:
|
||
|
||
|
||
function S'Exponent (X : T)
|
||
return universal_integer
|
||
|
||
|
||
The function yields the normalized exponent of X. See A.5.3.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="64" name="External_Tag" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For every subtype S of a tagged type T (specific or
|
||
class-wide):
|
||
|
||
|
||
S'External_Tag denotes an external string representation for
|
||
S'Tag; it is of the predefined type String. External_Tag may
|
||
be specified for a specific tagged type via an
|
||
attribute_definition_clause; the expression of such a clause
|
||
shall be static. The default external tag representation is
|
||
implementation defined. See 13.13.2. See 13.3.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="66/1" name="First" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For a prefix A that is of an array type (after any implicit
|
||
dereference), or denotes a constrained array subtype:
|
||
|
||
|
||
A'First denotes the lower bound of the first index range; its
|
||
type is the corresponding index type. See 3.6.2.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="68" name="First" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For every scalar subtype S:
|
||
|
||
|
||
S'First denotes the lower bound of the range of S. The value
|
||
of this attribute is of the type of S. See 3.5.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="70/1" name="First(N)" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For a prefix A that is of an array type (after any implicit
|
||
dereference), or denotes a constrained array subtype:
|
||
|
||
|
||
A'First(N) denotes the lower bound of the N-th index range;
|
||
its type is the corresponding index type. See 3.6.2.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="72" name="First_Bit" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For a component C of a composite, non-array object R:
|
||
|
||
|
||
If the nondefault bit ordering applies to the composite type,
|
||
and if a component_clause specifies the placement of C,
|
||
denotes the value given for the first_bit of the
|
||
component_clause; otherwise, denotes the offset, from the
|
||
start of the first of the storage elements occupied by C, of
|
||
the first bit occupied by C. This offset is measured in bits.
|
||
The first bit of a storage element is numbered zero. The value
|
||
of this attribute is of the type universal_integer. See</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="73.1/4" name="First_Valid" origin="Ada RM" category="unknown">
|
||
|
||
<DOC>For every static discrete subtype S for which there exists at
|
||
least one value belonging to S that satisfies the predicates
|
||
of S:
|
||
|
||
|
||
S'First_Valid denotes the smallest value that belongs to S and
|
||
satisfies the predicates of S. The value of this attribute is
|
||
of the type of S. See 3.5.5.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="74" name="Floor" origin="Ada RM" category="function">
|
||
|
||
<DOC>For every subtype S of a floating point type T:
|
||
|
||
|
||
S'Floor denotes a function with the following specification:
|
||
|
||
|
||
function S'Floor (X : T)
|
||
return T
|
||
|
||
|
||
The function yields the value Floor(X), that is, the largest
|
||
(most positive) integral value less than or equal to X. When X
|
||
is zero, the result has the sign of X; a zero result otherwise
|
||
has a positive sign. See A.5.3.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="78" name="Fore" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For every fixed point subtype S:
|
||
|
||
|
||
S'Fore yields the minimum number of characters needed before
|
||
the decimal point for the decimal representation of any value
|
||
of the subtype S, assuming that the representation does not
|
||
include an exponent, but includes a one-character prefix that
|
||
is either a minus sign or a space. (This minimum number does
|
||
not include superfluous zeros or underlines, and is at least
|
||
) The value of this attribute is of the type
|
||
universal_integer. See 3.5.10.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="8" name="Adjacent" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For every subtype S of a floating point type T:
|
||
|
||
|
||
S'Adjacent denotes a function with the following
|
||
specification:
|
||
|
||
|
||
function S'Adjacent (X, Towards : T)
|
||
return T
|
||
|
||
|
||
If Towards = X, the function yields X; otherwise, it yields
|
||
the machine number of the type T adjacent to X in the
|
||
direction of Towards, if that machine number exists. If the
|
||
result would be outside the base range of S, Constraint_Error
|
||
is raised. When T'Signed_Zeros is True, a zero result has the
|
||
sign of X. When Towards is zero, its sign has no bearing on
|
||
the result. See A.5.3.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="80" name="Fraction" origin="Ada RM" category="function">
|
||
|
||
<DOC>For every subtype S of a floating point type T:
|
||
|
||
|
||
S'Fraction denotes a function with the following
|
||
specification:
|
||
|
||
|
||
function S'Fraction (X : T)
|
||
return T
|
||
|
||
|
||
The function yields the value X x T'Machine_Radix(-k), where k
|
||
is the normalized exponent of X. A zero result, which can only
|
||
occur when X is zero, has the sign of X. See A.5.3.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="83.1/3" name="Has_Same_Storage" origin="Ada RM" category="unknown">
|
||
|
||
<DOC>For a prefix X that denotes an object:
|
||
|
||
|
||
X'Has_Same_Storage denotes a function with the following
|
||
specification:
|
||
|
||
|
||
function X'Has_Same_Storage (Arg : any_type)
|
||
return Boolean
|
||
|
||
|
||
The actual parameter shall be a name that denotes an object.
|
||
The object denoted by the actual parameter can be of any type.
|
||
This function evaluates the names of the objects involved. It
|
||
returns True if the representation of the object denoted by
|
||
the actual parameter occupies exactly the same bits as the
|
||
representation of the object denoted by X and the objects
|
||
occupy at least one bit; otherwise, it returns False. See</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="84/1" name="Identity" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For a prefix E that denotes an exception:
|
||
|
||
|
||
E'Identity returns the unique identity of the exception. The
|
||
type of this attribute is Exception_Id. See 11.4.1.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="86" name="Identity" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For a prefix T that is of a task type (after any implicit
|
||
dereference):
|
||
|
||
|
||
Yields a value of the type Task_Id that identifies the task
|
||
denoted by T. See C.7.1.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="88" name="Image" origin="Ada RM" category="function">
|
||
|
||
<DOC>For every subtype S of a type T:
|
||
|
||
|
||
S'Image denotes a function with the following specification:
|
||
|
||
|
||
function S'Image(Arg : S'Base)
|
||
return String
|
||
|
||
|
||
S'Image calls S'Put_Image passing Arg (which will typically
|
||
store a sequence of character values in a text buffer) and
|
||
then returns the result of retrieving the contents of that
|
||
buffer with function Get. See 4.10.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="91.1/5" name="Image" origin="Ada RM" category="function">
|
||
|
||
<DOC>For a prefix X of a type T other than universal_real or
|
||
universal_fixed:
|
||
|
||
|
||
X'Image denotes the result of calling function S'Image with
|
||
Arg being X, where S is the nominal subtype of X. See 4.10.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="91.3/5" name="Index" origin="Ada RM" category="variable">
|
||
|
||
<DOC>For a prefix E that denotes an entry declaration of an entry
|
||
family:
|
||
|
||
|
||
Within a precondition or postcondition expression for entry
|
||
family E, denotes the value of the entry index for the call of
|
||
E. The nominal subtype of this attribute is the entry index
|
||
subtype. See 6.1.1.</DOC>
|
||
</ATTRIBUTE>
|
||
<ATTRIBUTE id="96" name="Input" origin="Ada RM" category="function">
|
||
|
||
<DOC>For every subtype S of a specific type T:
|
||
|
||
|
||
S'Input denotes a function with the following specification:
|
||
|
||
|
||
function S'Input(
|
||
Stream : not null access Ada.Streams.Root_Stream_Type'Class)
|
||
return T
|
||
|
||
|
||
S'Input reads and returns one value from Stream, using any
|
||
bounds or discriminants written by a corresponding S'Output to
|
||
determine how much to read. See 13.13.2.</DOC>
|
||
</ATTRIBUTE>
|
||
<PRAGMA id="0" name="Abort_Defer" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Abort_Defer;
|
||
|
||
This pragma must appear at the start of the statement sequence of a
|
||
handled sequence of statements (right after the `begin'). It has the
|
||
effect of deferring aborts for the sequence of statements (but not for
|
||
the declarations or handlers, if any, associated with this statement
|
||
sequence). This can also be useful for adding a polling point in Ada
|
||
code, where asynchronous abort of tasks is checked when leaving the
|
||
statement sequence, and is lighter than, for example, using `delay
|
||
0.0;', since with zero-cost exception handling, propagating exceptions
|
||
(implicitly used to implement task abort) cannot be done reliably in an
|
||
asynchronous way.
|
||
|
||
An example of usage would be:
|
||
|
||
-- Add a polling point to check for task aborts
|
||
|
||
begin
|
||
pragma Abort_Defer;
|
||
end;</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Abstract_State" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Abstract_State (ABSTRACT_STATE_LIST);
|
||
|
||
ABSTRACT_STATE_LIST ::=
|
||
null
|
||
| STATE_NAME_WITH_OPTIONS
|
||
| (STATE_NAME_WITH_OPTIONS {, STATE_NAME_WITH_OPTIONS} )
|
||
|
||
STATE_NAME_WITH_OPTIONS ::=
|
||
STATE_NAME
|
||
| (STATE_NAME with OPTION_LIST)
|
||
|
||
OPTION_LIST ::= OPTION {, OPTION}
|
||
|
||
OPTION ::=
|
||
SIMPLE_OPTION
|
||
| NAME_VALUE_OPTION
|
||
|
||
SIMPLE_OPTION ::= Ghost | Synchronous
|
||
|
||
NAME_VALUE_OPTION ::=
|
||
Part_Of => ABSTRACT_STATE
|
||
| External [=> EXTERNAL_PROPERTY_LIST]
|
||
|
||
EXTERNAL_PROPERTY_LIST ::=
|
||
EXTERNAL_PROPERTY
|
||
| (EXTERNAL_PROPERTY {, EXTERNAL_PROPERTY} )
|
||
|
||
EXTERNAL_PROPERTY ::=
|
||
Async_Readers [=> static_boolean_EXPRESSION]
|
||
| Async_Writers [=> static_boolean_EXPRESSION]
|
||
| Effective_Reads [=> static_boolean_EXPRESSION]
|
||
| Effective_Writes [=> static_boolean_EXPRESSION]
|
||
others => static_boolean_EXPRESSION
|
||
|
||
STATE_NAME ::= defining_identifier
|
||
|
||
ABSTRACT_STATE ::= name
|
||
|
||
For the semantics of this pragma, see the entry for aspect
|
||
`Abstract_State' in the SPARK 2014 Reference Manual, section 7.1.4.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Ada_05" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Ada_05;
|
||
pragma Ada_05 (local_NAME);
|
||
|
||
A configuration pragma that establishes Ada 2005 mode for the unit to
|
||
which it applies, regardless of the mode set by the command line
|
||
switches. This pragma is useful when writing a reusable component that
|
||
itself uses Ada 2005 features, but which is intended to be usable from
|
||
either Ada 83 or Ada 95 programs.
|
||
|
||
Like all configuration pragmas, if the pragma is placed before a library
|
||
level package specification it is not propagated to the corresponding
|
||
package body (see RM 10.1.5(8)); it must be added explicitly to the
|
||
package body.
|
||
|
||
The one argument form (which is not a configuration pragma) is used for
|
||
managing the transition from Ada 95 to Ada 2005 in the run-time
|
||
library. If an entity is marked as Ada_2005 only, then referencing the
|
||
entity in Ada_83 or Ada_95 mode will generate a warning. In addition,
|
||
in Ada_83 or Ada_95 mode, a preference rule is established which does
|
||
not choose such an entity unless it is unambiguously specified. This
|
||
avoids extra subprograms marked this way from generating ambiguities in
|
||
otherwise legal pre-Ada_2005 programs. The one argument form is
|
||
intended for exclusive use in the GNAT run-time library.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Ada_12" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Ada_12;
|
||
pragma Ada_12 (local_NAME);
|
||
|
||
A configuration pragma that establishes Ada 2012 mode for the unit to
|
||
which it applies, regardless of the mode set by the command line
|
||
switches. This mode is set automatically for the `Ada' and `System'
|
||
packages and their children, so you need not specify it in these
|
||
contexts. This pragma is useful when writing a reusable component that
|
||
itself uses Ada 2012 features, but which is intended to be usable from
|
||
Ada 83, Ada 95, or Ada 2005 programs.
|
||
|
||
Like all configuration pragmas, if the pragma is placed before a library
|
||
level package specification it is not propagated to the corresponding
|
||
package body (see RM 10.1.5(8)); it must be added explicitly to the
|
||
package body.
|
||
|
||
The one argument form, which is not a configuration pragma, is used for
|
||
managing the transition from Ada 2005 to Ada 2012 in the run-time
|
||
library. If an entity is marked as Ada_2012 only, then referencing the
|
||
entity in any pre-Ada_2012 mode will generate a warning. In addition,
|
||
in any pre-Ada_2012 mode, a preference rule is established which does
|
||
not choose such an entity unless it is unambiguously specified. This
|
||
avoids extra subprograms marked this way from generating ambiguities in
|
||
otherwise legal pre-Ada_2012 programs. The one argument form is
|
||
intended for exclusive use in the GNAT run-time library.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Ada_2005" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Ada_2005;
|
||
|
||
This configuration pragma is a synonym for pragma Ada_05 and has the
|
||
same syntax and effect.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Ada_2012" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Ada_2012;
|
||
|
||
This configuration pragma is a synonym for pragma Ada_12 and has the
|
||
same syntax and effect.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Ada_2022" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Ada_2022;
|
||
pragma Ada_2022 (local_NAME);
|
||
|
||
A configuration pragma that establishes Ada 2022 mode for the unit to
|
||
which it applies, regardless of the mode set by the command line
|
||
switches. This mode is set automatically for the `Ada' and `System'
|
||
packages and their children, so you need not specify it in these
|
||
contexts. This pragma is useful when writing a reusable component that
|
||
itself uses Ada 2022 features, but which is intended to be usable from
|
||
Ada 83, Ada 95, Ada 2005 or Ada 2012 programs.
|
||
|
||
Like all configuration pragmas, if the pragma is placed before a library
|
||
level package specification it is not propagated to the corresponding
|
||
package body (see RM 10.1.5(8)); it must be added explicitly to the
|
||
package body.
|
||
|
||
The one argument form, which is not a configuration pragma, is used for
|
||
managing the transition from Ada 2012 to Ada 2022 in the run-time
|
||
library. If an entity is marked as Ada_2022 only, then referencing the
|
||
entity in any pre-Ada_2022 mode will generate a warning. In addition,
|
||
in any pre-Ada_2012 mode, a preference rule is established which does
|
||
not choose such an entity unless it is unambiguously specified. This
|
||
avoids extra subprograms marked this way from generating ambiguities in
|
||
otherwise legal pre-Ada_2022 programs. The one argument form is
|
||
intended for exclusive use in the GNAT run-time library.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Ada_83" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Ada_83;
|
||
|
||
A configuration pragma that establishes Ada 83 mode for the unit to
|
||
which it applies, regardless of the mode set by the command line
|
||
switches. In Ada 83 mode, GNAT attempts to be as compatible with the
|
||
syntax and semantics of Ada 83, as defined in the original Ada 83
|
||
Reference Manual as possible. In particular, the keywords added by Ada
|
||
95 and Ada 2005 are not recognized, optional package bodies are allowed,
|
||
and generics may name types with unknown discriminants without using
|
||
the `(<>)' notation. In addition, some but not all of the additional
|
||
restrictions of Ada 83 are enforced.
|
||
|
||
Like all configuration pragmas, if the pragma is placed before a library
|
||
level package specification it is not propagated to the corresponding
|
||
package body (see RM 10.1.5(8)); it must be added explicitly to the
|
||
package body.
|
||
|
||
Ada 83 mode is intended for two purposes. Firstly, it allows existing
|
||
Ada 83 code to be compiled and adapted to GNAT with less effort.
|
||
Secondly, it aids in keeping code backwards compatible with Ada 83.
|
||
However, there is no guarantee that code that is processed correctly by
|
||
GNAT in Ada 83 mode will in fact compile and execute with an Ada 83
|
||
compiler, since GNAT does not enforce all the additional checks
|
||
required by Ada 83.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Ada_95" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Ada_95;
|
||
|
||
A configuration pragma that establishes Ada 95 mode for the unit to
|
||
which it applies, regardless of the mode set by the command line
|
||
switches. This mode is set automatically for the `Ada' and `System'
|
||
packages and their children, so you need not specify it in these
|
||
contexts. This pragma is useful when writing a reusable component that
|
||
itself uses Ada 95 features, but which is intended to be usable from
|
||
either Ada 83 or Ada 95 programs.
|
||
|
||
Like all configuration pragmas, if the pragma is placed before a library
|
||
level package specification it is not propagated to the corresponding
|
||
package body (see RM 10.1.5(8)); it must be added explicitly to the
|
||
package body.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Admission_Policy" origin="Ada RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Admission_Policy;</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Aggregate_Individually_Assign" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Aggregate_Individually_Assign;
|
||
|
||
Where possible, GNAT will store the binary representation of a record
|
||
aggregate in memory for space and performance reasons. This
|
||
configuration pragma changes this behavior so that record aggregates
|
||
are instead always converted into individual assignment statements.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="All_Calls_Remote" origin="Ada RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma All_Calls_Remote [(library_unit_name)];</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Allow_Integer_Address" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Allow_Integer_Address;
|
||
|
||
In almost all versions of GNAT, `System.Address' is a private type in
|
||
accordance with the implementation advice in the RM. This means that
|
||
integer values, in particular integer literals, are not allowed as
|
||
address values. If the configuration pragma `Allow_Integer_Address' is
|
||
given, then integer expressions may be used anywhere a value of type
|
||
`System.Address' is required. The effect is to introduce an implicit
|
||
unchecked conversion from the integer value to type `System.Address'.
|
||
The reverse case of using an address where an integer type is required
|
||
is handled analogously. The following example compiles without errors:
|
||
|
||
pragma Allow_Integer_Address;
|
||
with System; use System;
|
||
package AddrAsInt is
|
||
X : Integer;
|
||
Y : Integer;
|
||
for X'Address use 16#1240#;
|
||
for Y use at 16#3230#;
|
||
m : Address := 16#4000#;
|
||
n : constant Address := 4000;
|
||
p : constant Address := Address (X + Y);
|
||
v : Integer := y'Address;
|
||
w : constant Integer := Integer (Y'Address);
|
||
type R is new integer;
|
||
RR : R := 1000;
|
||
Z : Integer;
|
||
for Z'Address use RR;
|
||
end AddrAsInt;
|
||
|
||
Note that pragma `Allow_Integer_Address' is ignored if `System.Address'
|
||
is not a private type. In implementations of `GNAT' where
|
||
System.Address is a visible integer type, this pragma serves no purpose
|
||
but is ignored rather than rejected to allow common sets of sources to
|
||
be used in the two situations.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Always_Terminates" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Always_Terminates [ (boolean_EXPRESSION) ];
|
||
|
||
For the semantics of this pragma, see the entry for aspect
|
||
`Always_Terminates' in the SPARK 2014 Reference Manual, section 6.1.11.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Annotate" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Annotate (IDENTIFIER [, IDENTIFIER {, ARG}] [, entity => local_NAME]);
|
||
|
||
ARG ::= NAME | EXPRESSION
|
||
|
||
This pragma is used to annotate programs. IDENTIFIER identifies the
|
||
type of annotation. GNAT verifies that it is an identifier, but does
|
||
not otherwise analyze it. The second optional identifier is also left
|
||
unanalyzed, and by convention is used to control the action of the tool
|
||
to which the annotation is addressed. The remaining ARG arguments can
|
||
be either string literals or more generally expressions. String
|
||
literals (and concatenations of string literals) are assumed to be
|
||
either of type `Standard.String' or else `Wide_String' or
|
||
`Wide_Wide_String' depending on the character literals they contain.
|
||
All other kinds of arguments are analyzed as expressions, and must be
|
||
unambiguous. The last argument if present must have the identifier
|
||
`Entity' and GNAT verifies that a local name is given.
|
||
|
||
The analyzed pragma is retained in the tree, but not otherwise processed
|
||
by any part of the GNAT compiler, except to generate corresponding note
|
||
lines in the generated ALI file. For the format of these note lines, see
|
||
the compiler source file lib-writ.ads. This pragma is intended for use
|
||
by external tools, including ASIS. The use of pragma Annotate does not
|
||
affect the compilation process in any way. This pragma may be used as a
|
||
configuration pragma.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Assert" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Assert (
|
||
boolean_EXPRESSION
|
||
[, string_EXPRESSION]);
|
||
|
||
The effect of this pragma depends on whether the corresponding command
|
||
line switch is set to activate assertions. The pragma expands into code
|
||
equivalent to the following:
|
||
|
||
if assertions-enabled then
|
||
if not boolean_EXPRESSION then
|
||
System.Assertions.Raise_Assert_Failure
|
||
(string_EXPRESSION);
|
||
end if;
|
||
end if;
|
||
|
||
The string argument, if given, is the message that will be associated
|
||
with the exception occurrence if the exception is raised. If no second
|
||
argument is given, the default message is `file':`nnn', where `file' is
|
||
the name of the source file containing the assert, and `nnn' is the
|
||
line number of the assert.
|
||
|
||
Note that, as with the `if' statement to which it is equivalent, the
|
||
type of the expression is either `Standard.Boolean', or any type derived
|
||
from this standard type.
|
||
|
||
Assert checks can be either checked or ignored. By default they are
|
||
ignored. They will be checked if either the command line switch
|
||
`-gnata' is used, or if an `Assertion_Policy' or `Check_Policy' pragma
|
||
is used to enable `Assert_Checks'.
|
||
|
||
If assertions are ignored, then there is no run-time effect (and in
|
||
particular, any side effects from the expression will not occur at run
|
||
time). (The expression is still analyzed at compile time, and may
|
||
cause types to be frozen if they are mentioned here for the first time).
|
||
|
||
If assertions are checked, then the given expression is tested, and if
|
||
it is `False' then `System.Assertions.Raise_Assert_Failure' is called
|
||
which results in the raising of `Assert_Failure' with the given message.
|
||
|
||
You should generally avoid side effects in the expression arguments of
|
||
this pragma, because these side effects will turn on and off with the
|
||
setting of the assertions mode, resulting in assertions that have an
|
||
effect on the program. However, the expressions are analyzed for
|
||
semantic correctness whether or not assertions are enabled, so turning
|
||
assertions on and off cannot affect the legality of a program.
|
||
|
||
Note that the implementation defined policy `DISABLE', given in a
|
||
pragma `Assertion_Policy', can be used to suppress this semantic
|
||
analysis.
|
||
|
||
Note: this is a standard language-defined pragma in versions of Ada
|
||
from 2005 on. In GNAT, it is implemented in all versions of Ada, and
|
||
the DISABLE policy is an implementation-defined addition.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Assert_And_Cut" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Assert_And_Cut (
|
||
boolean_EXPRESSION
|
||
[, string_EXPRESSION]);
|
||
|
||
The effect of this pragma is identical to that of pragma `Assert',
|
||
except that in an `Assertion_Policy' pragma, the identifier
|
||
`Assert_And_Cut' is used to control whether it is ignored or checked
|
||
(or disabled).
|
||
|
||
The intention is that this be used within a subprogram when the given
|
||
test expresion sums up all the work done so far in the subprogram, so
|
||
that the rest of the subprogram can be verified (informally or
|
||
formally) using only the entry preconditions, and the expression in
|
||
this pragma. This allows dividing up a subprogram into sections for the
|
||
purposes of testing or formal verification. The pragma also serves as
|
||
useful documentation.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Assertion_Policy" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Assertion_Policy (CHECK | DISABLE | IGNORE | SUPPRESSIBLE);
|
||
|
||
pragma Assertion_Policy (
|
||
ASSERTION_KIND => POLICY_IDENTIFIER
|
||
{, ASSERTION_KIND => POLICY_IDENTIFIER});
|
||
|
||
ASSERTION_KIND ::= RM_ASSERTION_KIND | ID_ASSERTION_KIND
|
||
|
||
RM_ASSERTION_KIND ::= Assert |
|
||
Static_Predicate |
|
||
Dynamic_Predicate |
|
||
Pre |
|
||
Pre'Class |
|
||
Post |
|
||
Post'Class |
|
||
Type_Invariant |
|
||
Type_Invariant'Class |
|
||
Default_Initial_Condition
|
||
|
||
ID_ASSERTION_KIND ::= Assertions |
|
||
Assert_And_Cut |
|
||
Assume |
|
||
Contract_Cases |
|
||
Debug |
|
||
Ghost |
|
||
Initial_Condition |
|
||
Invariant |
|
||
Invariant'Class |
|
||
Loop_Invariant |
|
||
Loop_Variant |
|
||
Postcondition |
|
||
Precondition |
|
||
Predicate |
|
||
Refined_Post |
|
||
Statement_Assertions |
|
||
Subprogram_Variant
|
||
|
||
POLICY_IDENTIFIER ::= Check | Disable | Ignore | Suppressible
|
||
|
||
This is a standard Ada 2012 pragma that is available as an
|
||
implementation-defined pragma in earlier versions of Ada. The
|
||
assertion kinds `RM_ASSERTION_KIND' are those defined in the Ada
|
||
standard. The assertion kinds `ID_ASSERTION_KIND' are implementation
|
||
defined additions recognized by the GNAT compiler.
|
||
|
||
The pragma applies in both cases to pragmas and aspects with matching
|
||
names, e.g. `Pre' applies to the Pre aspect, and `Precondition' applies
|
||
to both the `Precondition' pragma and the aspect `Precondition'. Note
|
||
that the identifiers for pragmas Pre_Class and Post_Class are
|
||
Pre’Class and Post’Class (not Pre_Class and Post_Class), since
|
||
these pragmas are intended to be identical to the corresponding aspects.
|
||
|
||
If the policy is `CHECK', then assertions are enabled, i.e. the
|
||
corresponding pragma or aspect is activated. If the policy is
|
||
`IGNORE', then assertions are ignored, i.e. the corresponding pragma
|
||
or aspect is deactivated. This pragma overrides the effect of the
|
||
`-gnata' switch on the command line. If the policy is `SUPPRESSIBLE',
|
||
then assertions are enabled by default, however, if the `-gnatp' switch
|
||
is specified all assertions are ignored.
|
||
|
||
The implementation defined policy `DISABLE' is like `IGNORE' except
|
||
that it completely disables semantic checking of the corresponding
|
||
pragma or aspect. This is useful when the pragma or aspect argument
|
||
references subprograms in a with’ed package which is replaced by a
|
||
dummy package for the final build.
|
||
|
||
The implementation defined assertion kind `Assertions' applies to all
|
||
assertion kinds. The form with no assertion kind given implies this
|
||
choice, so it applies to all assertion kinds (RM defined, and
|
||
implementation defined).
|
||
|
||
The implementation defined assertion kind `Statement_Assertions'
|
||
applies to `Assert', `Assert_And_Cut', `Assume', `Loop_Invariant', and
|
||
`Loop_Variant'.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Assume" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Assume (
|
||
boolean_EXPRESSION
|
||
[, string_EXPRESSION]);
|
||
|
||
The effect of this pragma is identical to that of pragma `Assert',
|
||
except that in an `Assertion_Policy' pragma, the identifier `Assume' is
|
||
used to control whether it is ignored or checked (or disabled).
|
||
|
||
The intention is that this be used for assumptions about the external
|
||
environment. So you cannot expect to verify formally or informally that
|
||
the condition is met, this must be established by examining things
|
||
outside the program itself. For example, we may have code that depends
|
||
on the size of `Long_Long_Integer' being at least 64. So we could write:
|
||
|
||
pragma Assume (Long_Long_Integer'Size >= 64);
|
||
|
||
This assumption cannot be proved from the program itself, but it acts
|
||
as a useful run-time check that the assumption is met, and documents
|
||
the need to ensure that it is met by reference to information outside
|
||
the program.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Assume_No_Invalid_Values" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Assume_No_Invalid_Values (On | Off);
|
||
|
||
This is a configuration pragma that controls the assumptions made by the
|
||
compiler about the occurrence of invalid representations (invalid
|
||
values) in the code.
|
||
|
||
The default behavior (corresponding to an Off argument for this
|
||
pragma), is to assume that values may in general be invalid unless the
|
||
compiler can prove they are valid. Consider the following example:
|
||
|
||
V1 : Integer range 1 .. 10;
|
||
V2 : Integer range 11 .. 20;
|
||
|
||
for J in V2 .. V1 loop
|
||
|
||
end loop;
|
||
|
||
if V1 and V2 have valid values, then the loop is known at compile time
|
||
not to execute since the lower bound must be greater than the upper
|
||
bound. However in default mode, no such assumption is made, and the
|
||
loop may execute. If `Assume_No_Invalid_Values (On)' is given, the
|
||
compiler will assume that any occurrence of a variable other than in an
|
||
explicit `'Valid' test always has a valid value, and the loop above
|
||
will be optimized away.
|
||
|
||
The use of `Assume_No_Invalid_Values (On)' is appropriate if you know
|
||
your code is free of uninitialized variables and other possible sources
|
||
of invalid representations, and may result in more efficient code. A
|
||
program that accesses an invalid representation with this pragma in
|
||
effect is erroneous, so no guarantees can be made about its behavior.
|
||
|
||
It is peculiar though permissible to use this pragma in conjunction
|
||
with validity checking (-gnatVa). In such cases, accessing invalid
|
||
values will generally give an exception, though formally the program is
|
||
erroneous so there are no guarantees that this will always be the case,
|
||
and it is recommended that these two options not be used together.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Async_Readers" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Async_Readers [ (static_boolean_EXPRESSION) ];
|
||
|
||
For the semantics of this pragma, see the entry for aspect
|
||
`Async_Readers' in the SPARK 2014 Reference Manual, section 7.1.2.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Async_Writers" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Async_Writers [ (static_boolean_EXPRESSION) ];
|
||
|
||
For the semantics of this pragma, see the entry for aspect
|
||
`Async_Writers' in the SPARK 2014 Reference Manual, section 7.1.2.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Asynchronous" origin="Ada RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Asynchronous;</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Atomic" origin="Ada RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Atomic;</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Atomic_Components" origin="Ada RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Atomic_Components;</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Attach_Handler" origin="Ada RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Attach_Handler;</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Attribute_Definition" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Attribute_Definition
|
||
([Attribute =>] ATTRIBUTE_DESIGNATOR,
|
||
[Entity =>] LOCAL_NAME,
|
||
[Expression =>] EXPRESSION | NAME);
|
||
|
||
If `Attribute' is a known attribute name, this pragma is equivalent to
|
||
the attribute definition clause:
|
||
|
||
for Entity'Attribute use Expression;
|
||
|
||
If `Attribute' is not a recognized attribute name, the pragma is
|
||
ignored, and a warning is emitted. This allows source code to be
|
||
written that takes advantage of some new attribute, while remaining
|
||
compilable with earlier compilers.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="CPP_Class" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma CPP_Class ([Entity =>] LOCAL_NAME);
|
||
|
||
The argument denotes an entity in the current declarative region that is
|
||
declared as a record type. It indicates that the type corresponds to an
|
||
externally declared C++ class type, and is to be laid out the same way
|
||
that C++ would lay out the type. If the C++ class has virtual primitives
|
||
then the record must be declared as a tagged record type.
|
||
|
||
Types for which `CPP_Class' is specified do not have assignment or
|
||
equality operators defined (such operations can be imported or declared
|
||
as subprograms as required). Initialization is allowed only by
|
||
constructor functions (see pragma `CPP_Constructor'). Such types are
|
||
implicitly limited if not explicitly declared as limited or derived
|
||
from a limited type, and an error is issued in that case.
|
||
|
||
See *note Interfacing to C++: 49. for related information.
|
||
|
||
Note: Pragma `CPP_Class' is currently obsolete. It is supported for
|
||
backward compatibility but its functionality is available using pragma
|
||
`Import' with `Convention' = `CPP'.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="CPP_Constructor" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma CPP_Constructor ([Entity =>] LOCAL_NAME
|
||
[, [External_Name =>] static_string_EXPRESSION ]
|
||
[, [Link_Name =>] static_string_EXPRESSION ]);
|
||
|
||
This pragma identifies an imported function (imported in the usual way
|
||
with pragma `Import') as corresponding to a C++ constructor. If
|
||
`External_Name' and `Link_Name' are not specified then the `Entity'
|
||
argument is a name that must have been previously mentioned in a pragma
|
||
`Import' with `Convention' = `CPP'. Such name must be of one of the
|
||
following forms:
|
||
|
||
* `function' `Fname' `return' T`
|
||
|
||
* `function' `Fname' `return' T’Class
|
||
|
||
* `function' `Fname' (…) `return' T`
|
||
|
||
* `function' `Fname' (…) `return' T’Class
|
||
|
||
where `T' is a limited record type imported from C++ with pragma
|
||
`Import' and `Convention' = `CPP'.
|
||
|
||
The first two forms import the default constructor, used when an object
|
||
of type `T' is created on the Ada side with no explicit constructor.
|
||
The latter two forms cover all the non-default constructors of the type.
|
||
See the GNAT User’s Guide for details.
|
||
|
||
If no constructors are imported, it is impossible to create any objects
|
||
on the Ada side and the type is implicitly declared abstract.
|
||
|
||
Pragma `CPP_Constructor' is intended primarily for automatic generation
|
||
using an automatic binding generator tool (such as the `-fdump-ada-spec'
|
||
GCC switch). See *note Interfacing to C++: 49. for more related
|
||
information.
|
||
|
||
Note: The use of functions returning class-wide types for constructors
|
||
is currently obsolete. They are supported for backward compatibility.
|
||
The use of functions returning the type T leave the Ada sources more
|
||
clear because the imported C++ constructors always return an object of
|
||
type T; that is, they never return an object whose type is a descendant
|
||
of type T.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="CPP_Virtual" origin="GNAT RM">
|
||
<DOC>This pragma is now obsolete and, other than generating a warning if
|
||
warnings on obsolescent features are enabled, is completely ignored.
|
||
It is retained for compatibility purposes. It used to be required to
|
||
ensure compatibility with C++, but is no longer required for that
|
||
purpose because GNAT generates the same object layout as the G++
|
||
compiler by default.
|
||
|
||
See *note Interfacing to C++: 49. for related information.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="CPP_Vtable" origin="GNAT RM">
|
||
<DOC>This pragma is now obsolete and, other than generating a warning if
|
||
warnings on obsolescent features are enabled, is completely ignored.
|
||
It used to be required to ensure compatibility with C++, but is no
|
||
longer required for that purpose because GNAT generates the same object
|
||
layout as the G++ compiler by default.
|
||
|
||
See *note Interfacing to C++: 49. for related information.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="CPU" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma CPU (EXPRESSION);
|
||
|
||
This pragma is standard in Ada 2012, but is available in all earlier
|
||
versions of Ada as an implementation-defined pragma. See Ada 2012
|
||
Reference Manual for details.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="C_Pass_By_Copy" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma C_Pass_By_Copy
|
||
([Max_Size =>] static_integer_EXPRESSION);
|
||
|
||
Normally the default mechanism for passing C convention records to C
|
||
convention subprograms is to pass them by reference, as suggested by RM
|
||
B.3(69). Use the configuration pragma `C_Pass_By_Copy' to change this
|
||
default, by requiring that record formal parameters be passed by copy
|
||
if all of the following conditions are met:
|
||
|
||
* The size of the record type does not exceed the value specified for
|
||
`Max_Size'.
|
||
|
||
* The record type has `Convention C'.
|
||
|
||
* The formal parameter has this record type, and the subprogram has a
|
||
foreign (non-Ada) convention.
|
||
|
||
If these conditions are met the argument is passed by copy; i.e., in a
|
||
manner consistent with what C expects if the corresponding formal in the
|
||
C prototype is a struct (rather than a pointer to a struct).
|
||
|
||
You can also pass records by copy by specifying the convention
|
||
`C_Pass_By_Copy' for the record type, or by using the extended `Import'
|
||
and `Export' pragmas, which allow specification of passing mechanisms
|
||
on a parameter by parameter basis.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Check" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Check (
|
||
[Name =>] CHECK_KIND,
|
||
[Check =>] Boolean_EXPRESSION
|
||
[, [Message =>] string_EXPRESSION] );
|
||
|
||
CHECK_KIND ::= IDENTIFIER |
|
||
Pre'Class |
|
||
Post'Class |
|
||
Type_Invariant'Class |
|
||
Invariant'Class
|
||
|
||
This pragma is similar to the predefined pragma `Assert' except that an
|
||
extra identifier argument is present. In conjunction with pragma
|
||
`Check_Policy', this can be used to define groups of assertions that can
|
||
be independently controlled. The identifier `Assertion' is special, it
|
||
refers to the normal set of pragma `Assert' statements.
|
||
|
||
Checks introduced by this pragma are normally deactivated by default.
|
||
They can be activated either by the command line option `-gnata', which
|
||
turns on all checks, or individually controlled using pragma
|
||
`Check_Policy'.
|
||
|
||
The identifiers `Assertions' and `Statement_Assertions' are not
|
||
permitted as check kinds, since this would cause confusion with the use
|
||
of these identifiers in `Assertion_Policy' and `Check_Policy' pragmas,
|
||
where they are used to refer to sets of assertions.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Check_Float_Overflow" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Check_Float_Overflow;
|
||
|
||
In Ada, the predefined floating-point types (`Short_Float', `Float',
|
||
`Long_Float', `Long_Long_Float') are defined to be `unconstrained'.
|
||
This means that even though each has a well-defined base range, an
|
||
operation that delivers a result outside this base range is not
|
||
required to raise an exception. This implementation permission
|
||
accommodates the notion of infinities in IEEE floating-point, and
|
||
corresponds to the efficient execution mode on most machines. GNAT will
|
||
not raise overflow exceptions on these machines; instead it will
|
||
generate infinities and NaN’s as defined in the IEEE standard.
|
||
|
||
Generating infinities, although efficient, is not always desirable.
|
||
Often the preferable approach is to check for overflow, even at the
|
||
(perhaps considerable) expense of run-time performance. This can be
|
||
accomplished by defining your own constrained floating-point subtypes
|
||
– i.e., by supplying explicit range constraints – and indeed such a
|
||
subtype can have the same base range as its base type. For example:
|
||
|
||
subtype My_Float is Float range Float'Range;
|
||
|
||
Here `My_Float' has the same range as `Float' but is constrained, so
|
||
operations on `My_Float' values will be checked for overflow against
|
||
this range.
|
||
|
||
This style will achieve the desired goal, but it is often more
|
||
convenient to be able to simply use the standard predefined
|
||
floating-point types as long as overflow checking could be guaranteed.
|
||
The `Check_Float_Overflow' configuration pragma achieves this effect.
|
||
If a unit is compiled subject to this configuration pragma, then all
|
||
operations on predefined floating-point types including operations on
|
||
base types of these floating-point types will be treated as though
|
||
those types were constrained, and overflow checks will be generated.
|
||
The `Constraint_Error' exception is raised if the result is out of
|
||
range.
|
||
|
||
This mode can also be set by use of the compiler switch `-gnateF'.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Check_Name" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Check_Name (check_name_IDENTIFIER);
|
||
|
||
This is a configuration pragma that defines a new implementation
|
||
defined check name (unless IDENTIFIER matches one of the predefined
|
||
check names, in which case the pragma has no effect). Check names are
|
||
global to a partition, so if two or more configuration pragmas are
|
||
present in a partition mentioning the same name, only one new check
|
||
name is introduced.
|
||
|
||
An implementation defined check name introduced with this pragma may be
|
||
used in only three contexts: `pragma Suppress', `pragma Unsuppress',
|
||
and as the prefix of a `Check_Name'Enabled' attribute reference. For
|
||
any of these three cases, the check name must be visible. A check name
|
||
is visible if it is in the configuration pragmas applying to the
|
||
current unit, or if it appears at the start of any unit that is part of
|
||
the dependency set of the current unit (e.g., units that are mentioned
|
||
in `with' clauses).
|
||
|
||
Check names introduced by this pragma are subject to control by compiler
|
||
switches (in particular -gnatp) in the usual manner.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Check_Policy" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Check_Policy
|
||
([Name =>] CHECK_KIND,
|
||
[Policy =>] POLICY_IDENTIFIER);
|
||
|
||
pragma Check_Policy (
|
||
CHECK_KIND => POLICY_IDENTIFIER
|
||
{, CHECK_KIND => POLICY_IDENTIFIER});
|
||
|
||
ASSERTION_KIND ::= RM_ASSERTION_KIND | ID_ASSERTION_KIND
|
||
|
||
CHECK_KIND ::= IDENTIFIER |
|
||
Pre'Class |
|
||
Post'Class |
|
||
Type_Invariant'Class |
|
||
Invariant'Class
|
||
|
||
The identifiers Name and Policy are not allowed as CHECK_KIND values. This
|
||
avoids confusion between the two possible syntax forms for this pragma.
|
||
|
||
POLICY_IDENTIFIER ::= ON | OFF | CHECK | DISABLE | IGNORE
|
||
|
||
This pragma is used to set the checking policy for assertions (specified
|
||
by aspects or pragmas), the `Debug' pragma, or additional checks to be
|
||
checked using the `Check' pragma. It may appear either as a
|
||
configuration pragma, or within a declarative part of package. In the
|
||
latter case, it applies from the point where it appears to the end of
|
||
the declarative region (like pragma `Suppress').
|
||
|
||
The `Check_Policy' pragma is similar to the predefined
|
||
`Assertion_Policy' pragma, and if the check kind corresponds to one of
|
||
the assertion kinds that are allowed by `Assertion_Policy', then the
|
||
effect is identical.
|
||
|
||
If the first argument is Debug, then the policy applies to Debug
|
||
pragmas, disabling their effect if the policy is `OFF', `DISABLE', or
|
||
`IGNORE', and allowing them to execute with normal semantics if the
|
||
policy is `ON' or `CHECK'. In addition if the policy is `DISABLE', then
|
||
the procedure call in `Debug' pragmas will be totally ignored and not
|
||
analyzed semantically.
|
||
|
||
Finally the first argument may be some other identifier than the above
|
||
possibilities, in which case it controls a set of named assertions that
|
||
can be checked using pragma `Check'. For example, if the pragma:
|
||
|
||
pragma Check_Policy (Critical_Error, OFF);
|
||
|
||
is given, then subsequent `Check' pragmas whose first argument is also
|
||
`Critical_Error' will be disabled.
|
||
|
||
The check policy is `OFF' to turn off corresponding checks, and `ON' to
|
||
turn on corresponding checks. The default for a set of checks for which
|
||
no `Check_Policy' is given is `OFF' unless the compiler switch `-gnata'
|
||
is given, which turns on all checks by default.
|
||
|
||
The check policy settings `CHECK' and `IGNORE' are recognized as
|
||
synonyms for `ON' and `OFF'. These synonyms are provided for
|
||
compatibility with the standard `Assertion_Policy' pragma. The check
|
||
policy setting `DISABLE' causes the second argument of a corresponding
|
||
`Check' pragma to be completely ignored and not analyzed.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Comment" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Comment (static_string_EXPRESSION);
|
||
|
||
This is almost identical in effect to pragma `Ident'. It allows the
|
||
placement of a comment into the object file and hence into the
|
||
executable file if the operating system permits such usage. The
|
||
difference is that `Comment', unlike `Ident', has no limitations on
|
||
placement of the pragma (it can be placed anywhere in the main source
|
||
unit), and if more than one pragma is used, all comments are retained.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Common_Object" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Common_Object (
|
||
[Internal =>] LOCAL_NAME
|
||
[, [External =>] EXTERNAL_SYMBOL]
|
||
[, [Size =>] EXTERNAL_SYMBOL] );
|
||
|
||
EXTERNAL_SYMBOL ::=
|
||
IDENTIFIER
|
||
| static_string_EXPRESSION
|
||
|
||
This pragma enables the shared use of variables stored in overlaid
|
||
linker areas corresponding to the use of `COMMON' in Fortran. The
|
||
single object `LOCAL_NAME' is assigned to the area designated by the
|
||
`External' argument. You may define a record to correspond to a series
|
||
of fields. The `Size' argument is syntax checked in GNAT, but
|
||
otherwise ignored.
|
||
|
||
`Common_Object' is not supported on all platforms. If no support is
|
||
available, then the code generator will issue a message indicating that
|
||
the necessary attribute for implementation of this pragma is not
|
||
available.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Compile_Time_Error" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Compile_Time_Error
|
||
(boolean_EXPRESSION, static_string_EXPRESSION);
|
||
|
||
This pragma can be used to generate additional compile time error
|
||
messages. It is particularly useful in generics, where errors can be
|
||
issued for specific problematic instantiations. The first parameter is
|
||
a boolean expression. The pragma ensures that the value of an expression
|
||
is known at compile time, and has the value False. The set of
|
||
expressions whose values are known at compile time includes all static
|
||
boolean expressions, and also other values which the compiler can
|
||
determine at compile time (e.g., the size of a record type set by an
|
||
explicit size representation clause, or the value of a variable which
|
||
was initialized to a constant and is known not to have been modified).
|
||
If these conditions are not met, an error message is generated using
|
||
the value given as the second argument. This string value may contain
|
||
embedded ASCII.LF characters to break the message into multiple lines.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Compile_Time_Warning" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Compile_Time_Warning
|
||
(boolean_EXPRESSION, static_string_EXPRESSION);
|
||
|
||
Same as pragma Compile_Time_Error, except a warning is issued instead
|
||
of an error message. If switch `-gnatw_C' is used, a warning is only
|
||
issued if the value of the expression is known to be True at compile
|
||
time, not when the value of the expression is not known at compile time.
|
||
Note that if this pragma is used in a package that is with’ed by a
|
||
client, the client will get the warning even though it is issued by a
|
||
with’ed package (normally warnings in with’ed units are suppressed,
|
||
but this is a special exception to that rule).
|
||
|
||
One typical use is within a generic where compile time known
|
||
characteristics of formal parameters are tested, and warnings given
|
||
appropriately. Another use with a first parameter of True is to warn a
|
||
client about use of a package, for example that it is not fully
|
||
implemented.
|
||
|
||
In previous versions of the compiler, combining `-gnatwe' with
|
||
Compile_Time_Warning resulted in a fatal error. Now the compiler always
|
||
emits a warning. You can use *note Pragma Compile_Time_Error: 3d. to
|
||
force the generation of an error.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Complete_Representation" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Complete_Representation;
|
||
|
||
This pragma must appear immediately within a record representation
|
||
clause. Typical placements are before the first component clause or
|
||
after the last component clause. The effect is to give an error message
|
||
if any component is missing a component clause. This pragma may be used
|
||
to ensure that a record representation clause is complete, and that
|
||
this invariant is maintained if fields are added to the record in the
|
||
future.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Complex_Representation" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Complex_Representation
|
||
([Entity =>] LOCAL_NAME);
|
||
|
||
The `Entity' argument must be the name of a record type which has two
|
||
fields of the same floating-point type. The effect of this pragma is
|
||
to force gcc to use the special internal complex representation form for
|
||
this record, which may be more efficient. Note that this may result in
|
||
the code for this type not conforming to standard ABI (application
|
||
binary interface) requirements for the handling of record types. For
|
||
example, in some environments, there is a requirement for passing
|
||
records by pointer, and the use of this pragma may result in passing
|
||
this type in floating-point registers.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Component_Alignment" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Component_Alignment (
|
||
[Form =>] ALIGNMENT_CHOICE
|
||
[, [Name =>] type_LOCAL_NAME]);
|
||
|
||
ALIGNMENT_CHOICE ::=
|
||
Component_Size
|
||
| Component_Size_4
|
||
| Storage_Unit
|
||
| Default
|
||
|
||
Specifies the alignment of components in array or record types. The
|
||
meaning of the `Form' argument is as follows:
|
||
|
||
|
||
`Component_Size'
|
||
Aligns scalar components and subcomponents of the array or record
|
||
type on boundaries appropriate to their inherent size (naturally
|
||
aligned). For example, 1-byte components are aligned on byte
|
||
boundaries, 2-byte integer components are aligned on 2-byte
|
||
boundaries, 4-byte integer components are aligned on 4-byte
|
||
boundaries and so on. These alignment rules correspond to the
|
||
normal rules for C compilers on all machines except the VAX.
|
||
|
||
`Component_Size_4'
|
||
Naturally aligns components with a size of four or fewer bytes.
|
||
Components that are larger than 4 bytes are placed on the next
|
||
-byte boundary.
|
||
|
||
`Storage_Unit'
|
||
Specifies that array or record components are byte aligned, i.e.,
|
||
aligned on boundaries determined by the value of the constant
|
||
`System.Storage_Unit'.
|
||
|
||
`Default'
|
||
Specifies that array or record components are aligned on default
|
||
boundaries, appropriate to the underlying hardware or operating
|
||
system or both. The `Default' choice is the same as
|
||
`Component_Size' (natural alignment).
|
||
|
||
If the `Name' parameter is present, `type_LOCAL_NAME' must refer to a
|
||
local record or array type, and the specified alignment choice applies
|
||
to the specified type. The use of `Component_Alignment' together with
|
||
a pragma `Pack' causes the `Component_Alignment' pragma to be ignored.
|
||
The use of `Component_Alignment' together with a record representation
|
||
clause is only effective for fields not specified by the representation
|
||
clause.
|
||
|
||
If the `Name' parameter is absent, the pragma can be used as either a
|
||
configuration pragma, in which case it applies to one or more units in
|
||
accordance with the normal rules for configuration pragmas, or it can be
|
||
used within a declarative part, in which case it applies to types that
|
||
are declared within this declarative part, or within any nested scope
|
||
within this declarative part. In either case it specifies the alignment
|
||
to be applied to any record or array type which has otherwise standard
|
||
representation.
|
||
|
||
If the alignment for a record or array type is not specified (using
|
||
pragma `Pack', pragma `Component_Alignment', or a record rep clause),
|
||
the GNAT uses the default alignment as described previously.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Conflict_Check_Policy" origin="Ada RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Conflict_Check_Policy;</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Constant_After_Elaboration" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Constant_After_Elaboration [ (static_boolean_EXPRESSION) ];
|
||
|
||
For the semantics of this pragma, see the entry for aspect
|
||
`Constant_After_Elaboration' in the SPARK 2014 Reference Manual,
|
||
section 3.3.1.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Contract_Cases" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Contract_Cases (CONTRACT_CASE {, CONTRACT_CASE});
|
||
|
||
CONTRACT_CASE ::= CASE_GUARD => CONSEQUENCE
|
||
|
||
CASE_GUARD ::= boolean_EXPRESSION | others
|
||
|
||
CONSEQUENCE ::= boolean_EXPRESSION
|
||
|
||
The `Contract_Cases' pragma allows defining fine-grain specifications
|
||
that can complement or replace the contract given by a precondition and
|
||
a postcondition. Additionally, the `Contract_Cases' pragma can be used
|
||
by testing and formal verification tools. The compiler checks its
|
||
validity and, depending on the assertion policy at the point of
|
||
declaration of the pragma, it may insert a check in the executable. For
|
||
code generation, the contract cases
|
||
|
||
pragma Contract_Cases (
|
||
Cond1 => Pred1,
|
||
Cond2 => Pred2);
|
||
|
||
are equivalent to
|
||
|
||
C1 : constant Boolean := Cond1; -- evaluated at subprogram entry
|
||
C2 : constant Boolean := Cond2; -- evaluated at subprogram entry
|
||
pragma Precondition ((C1 and not C2) or (C2 and not C1));
|
||
pragma Postcondition (if C1 then Pred1);
|
||
pragma Postcondition (if C2 then Pred2);
|
||
|
||
The precondition ensures that one and only one of the case guards is
|
||
satisfied on entry to the subprogram. The postcondition ensures that
|
||
for the case guard that was True on entry, the corresponding
|
||
consequence is True on exit. Other consequence expressions are not
|
||
evaluated.
|
||
|
||
A precondition `P' and postcondition `Q' can also be expressed as
|
||
contract cases:
|
||
|
||
pragma Contract_Cases (P => Q);
|
||
|
||
The placement and visibility rules for `Contract_Cases' pragmas are
|
||
identical to those described for preconditions and postconditions.
|
||
|
||
The compiler checks that boolean expressions given in case guards and
|
||
consequences are valid, where the rules for case guards are the same as
|
||
the rule for an expression in `Precondition' and the rules for
|
||
consequences are the same as the rule for an expression in
|
||
`Postcondition'. In particular, attributes `'Old' and `'Result' can
|
||
only be used within consequence expressions. The case guard for the
|
||
last contract case may be `others', to denote any case not captured by
|
||
the previous cases. The following is an example of use within a package
|
||
spec:
|
||
|
||
package Math_Functions is
|
||
|
||
function Sqrt (Arg : Float) return Float;
|
||
pragma Contract_Cases (((Arg in 0.0 .. 99.0) => Sqrt'Result < 10.0,
|
||
Arg >= 100.0 => Sqrt'Result >= 10.0,
|
||
others => Sqrt'Result = 0.0));
|
||
|
||
end Math_Functions;
|
||
|
||
The meaning of contract cases is that only one case should apply at each
|
||
call, as determined by the corresponding case guard evaluating to True,
|
||
and that the consequence for this case should hold when the subprogram
|
||
returns.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Convention" origin="Ada RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Convention ([Convention=>]convention_identifier,[Entity=>]local_name);</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Convention_Identifier" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Convention_Identifier (
|
||
[Name =>] IDENTIFIER,
|
||
[Convention =>] convention_IDENTIFIER);
|
||
|
||
This pragma provides a mechanism for supplying synonyms for existing
|
||
convention identifiers. The `Name' identifier can subsequently be used
|
||
as a synonym for the given convention in other pragmas (including for
|
||
example pragma `Import' or another `Convention_Identifier' pragma). As
|
||
an example of the use of this, suppose you had legacy code which used
|
||
Fortran77 as the identifier for Fortran. Then the pragma:
|
||
|
||
pragma Convention_Identifier (Fortran77, Fortran);
|
||
|
||
would allow the use of the convention identifier `Fortran77' in
|
||
subsequent code, avoiding the need to modify the sources. As another
|
||
example, you could use this to parameterize convention requirements
|
||
according to systems. Suppose you needed to use `Stdcall' on windows
|
||
systems, and `C' on some other system, then you could define a
|
||
convention identifier `Library' and use a single
|
||
`Convention_Identifier' pragma to specify which convention would be
|
||
used system-wide.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Deadline_Floor" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Deadline_Floor (time_span_EXPRESSION);
|
||
|
||
This pragma applies only to protected types and specifies the floor
|
||
deadline inherited by a task when the task enters a protected object.
|
||
It is effective only when the EDF scheduling policy is used.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Debug" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Debug ([CONDITION, ]PROCEDURE_CALL_WITHOUT_SEMICOLON);
|
||
|
||
PROCEDURE_CALL_WITHOUT_SEMICOLON ::=
|
||
PROCEDURE_NAME
|
||
| PROCEDURE_PREFIX ACTUAL_PARAMETER_PART
|
||
|
||
The procedure call argument has the syntactic form of an expression,
|
||
meeting the syntactic requirements for pragmas.
|
||
|
||
If debug pragmas are not enabled or if the condition is present and
|
||
evaluates to False, this pragma has no effect. If debug pragmas are
|
||
enabled, the semantics of the pragma is exactly equivalent to the
|
||
procedure call statement corresponding to the argument with a
|
||
terminating semicolon. Pragmas are permitted in sequences of
|
||
declarations, so you can use pragma `Debug' to intersperse calls to
|
||
debug procedures in the middle of declarations. Debug pragmas can be
|
||
enabled either by use of the command line switch `-gnata' or by use of
|
||
the pragma `Check_Policy' with a first argument of `Debug'.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Debug_Policy" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Debug_Policy (CHECK | DISABLE | IGNORE | ON | OFF);
|
||
|
||
This pragma is equivalent to a corresponding `Check_Policy' pragma with
|
||
a first argument of `Debug'. It is retained for historical
|
||
compatibility reasons.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Default_Initial_Condition" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Default_Initial_Condition [ (null | boolean_EXPRESSION) ];
|
||
|
||
For the semantics of this pragma, see the entry for aspect
|
||
`Default_Initial_Condition' in the SPARK 2014 Reference Manual, section
|
||
7.3.3.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Default_Scalar_Storage_Order" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Default_Scalar_Storage_Order (High_Order_First | Low_Order_First);
|
||
|
||
Normally if no explicit `Scalar_Storage_Order' is given for a record
|
||
type or array type, then the scalar storage order defaults to the
|
||
ordinary default for the target. But this default may be overridden
|
||
using this pragma. The pragma may appear as a configuration pragma, or
|
||
locally within a package spec or declarative part. In the latter case,
|
||
it applies to all subsequent types declared within that package spec or
|
||
declarative part.
|
||
|
||
The following example shows the use of this pragma:
|
||
|
||
pragma Default_Scalar_Storage_Order (High_Order_First);
|
||
with System; use System;
|
||
package DSSO1 is
|
||
type H1 is record
|
||
a : Integer;
|
||
end record;
|
||
|
||
type L2 is record
|
||
a : Integer;
|
||
end record;
|
||
for L2'Scalar_Storage_Order use Low_Order_First;
|
||
|
||
type L2a is new L2;
|
||
|
||
package Inner is
|
||
type H3 is record
|
||
a : Integer;
|
||
end record;
|
||
|
||
pragma Default_Scalar_Storage_Order (Low_Order_First);
|
||
|
||
type L4 is record
|
||
a : Integer;
|
||
end record;
|
||
end Inner;
|
||
|
||
type H4a is new Inner.L4;
|
||
|
||
type H5 is record
|
||
a : Integer;
|
||
end record;
|
||
end DSSO1;
|
||
|
||
In this example record types with names starting with `L' have
|
||
`Low_Order_First' scalar storage order, and record types with names
|
||
starting with `H' have `High_Order_First'. Note that in the case of
|
||
`H4a', the order is not inherited from the parent type. Only an
|
||
explicitly set `Scalar_Storage_Order' gets inherited on type derivation.
|
||
|
||
If this pragma is used as a configuration pragma which appears within a
|
||
configuration pragma file (as opposed to appearing explicitly at the
|
||
start of a single unit), then the binder will require that all units in
|
||
a partition be compiled in a similar manner, other than run-time units,
|
||
which are not affected by this pragma. Note that the use of this form
|
||
is discouraged because it may significantly degrade the run-time
|
||
performance of the software, instead the default scalar storage order
|
||
ought to be changed only on a local basis.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Default_Storage_Pool" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Default_Storage_Pool (storage_pool_NAME | null);
|
||
|
||
This pragma is standard in Ada 2012, but is available in all earlier
|
||
versions of Ada as an implementation-defined pragma. See Ada 2012
|
||
Reference Manual for details.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Depends" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Depends (DEPENDENCY_RELATION);
|
||
|
||
DEPENDENCY_RELATION ::=
|
||
null
|
||
| (DEPENDENCY_CLAUSE {, DEPENDENCY_CLAUSE})
|
||
|
||
DEPENDENCY_CLAUSE ::=
|
||
OUTPUT_LIST =>[+] INPUT_LIST
|
||
| NULL_DEPENDENCY_CLAUSE
|
||
|
||
NULL_DEPENDENCY_CLAUSE ::= null => INPUT_LIST
|
||
|
||
OUTPUT_LIST ::= OUTPUT | (OUTPUT {, OUTPUT})
|
||
|
||
INPUT_LIST ::= null | INPUT | (INPUT {, INPUT})
|
||
|
||
OUTPUT ::= NAME | FUNCTION_RESULT
|
||
INPUT ::= NAME
|
||
|
||
where FUNCTION_RESULT is a function Result attribute_reference
|
||
|
||
For the semantics of this pragma, see the entry for aspect `Depends' in
|
||
the SPARK 2014 Reference Manual, section 6.1.5.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Detect_Blocking" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Detect_Blocking;
|
||
|
||
This is a standard pragma in Ada 2005, that is available in all earlier
|
||
versions of Ada as an implementation-defined pragma.
|
||
|
||
This is a configuration pragma that forces the detection of potentially
|
||
blocking operations within a protected operation, and to raise
|
||
Program_Error if that happens.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Disable_Atomic_Synchronization" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Disable_Atomic_Synchronization [(Entity)];
|
||
|
||
pragma Enable_Atomic_Synchronization [(Entity)];
|
||
|
||
Ada requires that accesses (reads or writes) of an atomic variable be
|
||
regarded as synchronization points in the case of multiple tasks.
|
||
Particularly in the case of multi-processors this may require special
|
||
handling, e.g. the generation of memory barriers. This synchronization
|
||
is performed by default, but can be turned off using pragma
|
||
`Disable_Atomic_Synchronization'. The `Enable_Atomic_Synchronization'
|
||
pragma turns it back on.
|
||
|
||
The placement and scope rules for these pragmas are the same as those
|
||
for `pragma Suppress'. In particular they can be used as configuration
|
||
pragmas, or in a declaration sequence where they apply until the end of
|
||
the scope. If an `Entity' argument is present, the action applies only
|
||
to that entity.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Discard_Names" origin="Ada RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Discard_Names [([On => ] local_name)];</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Dispatching_Domain" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Dispatching_Domain (EXPRESSION);
|
||
|
||
This pragma is standard in Ada 2012, but is available in all earlier
|
||
versions of Ada as an implementation-defined pragma. See Ada 2012
|
||
Reference Manual for details.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Effective_Reads" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Effective_Reads [ (static_boolean_EXPRESSION) ];
|
||
|
||
For the semantics of this pragma, see the entry for aspect
|
||
`Effective_Reads' in the SPARK 2014 Reference Manual, section 7.1.2.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Effective_Writes" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Effective_Writes [ (static_boolean_EXPRESSION) ];
|
||
|
||
For the semantics of this pragma, see the entry for aspect
|
||
`Effective_Writes' in the SPARK 2014 Reference Manual, section 7.1.2.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Elaborate" origin="Ada RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Elaborate (library_unit_name{, library_unit_name});</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Elaborate_All" origin="Ada RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Elaborate_All (library_unit_name{, library_unit_name});</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Elaborate_Body" origin="Ada RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Elaborate_Body [(library_unit_name)];</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Elaboration_Checks" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Elaboration_Checks (Dynamic | Static);
|
||
|
||
This is a configuration pragma which specifies the elaboration model to
|
||
be used during compilation. For more information on the elaboration
|
||
models of GNAT, consult the chapter on elaboration order handling in
|
||
the `GNAT User’s Guide'.
|
||
|
||
The pragma may appear in the following contexts:
|
||
|
||
* Configuration pragmas file
|
||
|
||
* Prior to the context clauses of a compilation unit’s initial
|
||
declaration
|
||
|
||
Any other placement of the pragma will result in a warning and the
|
||
effects of the offending pragma will be ignored.
|
||
|
||
If the pragma argument is `Dynamic', then the dynamic elaboration model
|
||
is in effect. If the pragma argument is `Static', then the static
|
||
elaboration model is in effect.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Eliminate" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Eliminate (
|
||
[ Unit_Name => ] IDENTIFIER | SELECTED_COMPONENT ,
|
||
[ Entity => ] IDENTIFIER |
|
||
SELECTED_COMPONENT |
|
||
STRING_LITERAL
|
||
[, Source_Location => SOURCE_TRACE ] );
|
||
|
||
SOURCE_TRACE ::= STRING_LITERAL
|
||
|
||
This pragma indicates that the given entity is not used in the program
|
||
to be compiled and built, thus allowing the compiler to eliminate the
|
||
code or data associated with the named entity. Any reference to an
|
||
eliminated entity causes a compile-time or link-time error.
|
||
|
||
The pragma has the following semantics, where `U' is the unit specified
|
||
by the `Unit_Name' argument and `E' is the entity specified by the
|
||
`Entity' argument:
|
||
|
||
* `E' must be a subprogram that is explicitly declared either:
|
||
|
||
* Within `U', or
|
||
|
||
* Within a generic package that is instantiated in `U', or
|
||
|
||
* As an instance of generic subprogram instantiated in `U'.
|
||
|
||
Otherwise the pragma is ignored.
|
||
|
||
* If `E' is overloaded within `U' then, in the absence of a
|
||
`Source_Location' argument, all overloadings are eliminated.
|
||
|
||
* If `E' is overloaded within `U' and only some overloadings are to
|
||
be eliminated, then each overloading to be eliminated must be
|
||
specified in a corresponding pragma `Eliminate' with a
|
||
`Source_Location' argument identifying the line where the
|
||
declaration appears, as described below.
|
||
|
||
* If `E' is declared as the result of a generic instantiation, then
|
||
a `Source_Location' argument is needed, as described below.
|
||
|
||
Pragma `Eliminate' allows a program to be compiled in a
|
||
system-independent manner, so that unused entities are eliminated but
|
||
without needing to modify the source text. Normally the required set of
|
||
`Eliminate' pragmas is constructed automatically using the `gnatelim'
|
||
tool.
|
||
|
||
Any source file change that removes, splits, or adds lines may make the
|
||
set of `Eliminate' pragmas invalid because their `Source_Location'
|
||
argument values may get out of date.
|
||
|
||
Pragma `Eliminate' may be used where the referenced entity is a
|
||
dispatching operation. In this case all the subprograms to which the
|
||
given operation can dispatch are considered to be unused (are never
|
||
called as a result of a direct or a dispatching call).
|
||
|
||
The string literal given for the source location specifies the line
|
||
number of the declaration of the entity, using the following syntax for
|
||
`SOURCE_TRACE':
|
||
|
||
SOURCE_TRACE ::= SOURCE_REFERENCE [ LBRACKET SOURCE_TRACE RBRACKET ]
|
||
|
||
LBRACKET ::= '['
|
||
RBRACKET ::= ']'
|
||
|
||
SOURCE_REFERENCE ::= FILE_NAME : LINE_NUMBER
|
||
|
||
LINE_NUMBER ::= DIGIT {DIGIT}
|
||
|
||
Spaces around the colon in a `SOURCE_REFERENCE' are optional.
|
||
|
||
The source trace that is given as the `Source_Location' must obey the
|
||
following rules (or else the pragma is ignored), where `U' is the unit
|
||
`U' specified by the `Unit_Name' argument and `E' is the subprogram
|
||
specified by the `Entity' argument:
|
||
|
||
* `FILE_NAME' is the short name (with no directory information) of
|
||
the Ada source file for `U', using the required syntax for the
|
||
underlying file system (e.g. case is significant if the underlying
|
||
operating system is case sensitive). If `U' is a package and `E'
|
||
is a subprogram declared in the package specification and its full
|
||
declaration appears in the package body, then the relevant source
|
||
file is the one for the package specification; analogously if `U'
|
||
is a generic package.
|
||
|
||
* If `E' is not declared in a generic instantiation (this includes
|
||
generic subprogram instances), the source trace includes only one
|
||
source line reference. `LINE_NUMBER' gives the line number of the
|
||
occurrence of the declaration of `E' within the source file (as a
|
||
decimal literal without an exponent or point).
|
||
|
||
* If `E' is declared by a generic instantiation, its source trace
|
||
(from left to right) starts with the source location of the
|
||
declaration of `E' in the generic unit and ends with the source
|
||
location of the instantiation, given in square brackets. This
|
||
approach is applied recursively with nested instantiations: the
|
||
rightmost (nested most deeply in square brackets) element of the
|
||
source trace is the location of the outermost instantiation, and
|
||
the leftmost element (that is, outside of any square brackets) is
|
||
the location of the declaration of `E' in the generic unit.
|
||
|
||
Examples:
|
||
|
||
pragma Eliminate (Pkg0, Proc);
|
||
-- Eliminate (all overloadings of) Proc in Pkg0
|
||
|
||
pragma Eliminate (Pkg1, Proc,
|
||
Source_Location => "pkg1.ads:8");
|
||
-- Eliminate overloading of Proc at line 8 in pkg1.ads
|
||
|
||
-- Assume the following file contents:
|
||
-- gen_pkg.ads
|
||
-- 1: generic
|
||
-- 2: type T is private;
|
||
-- 3: package Gen_Pkg is
|
||
-- 4: procedure Proc(N : T);
|
||
-- ... ...
|
||
-- ... end Gen_Pkg;
|
||
--
|
||
-- q.adb
|
||
-- 1: with Gen_Pkg;
|
||
-- 2: procedure Q is
|
||
-- 3: package Inst_Pkg is new Gen_Pkg(Integer);
|
||
-- ... -- No calls on Inst_Pkg.Proc
|
||
-- ... end Q;
|
||
|
||
-- The following pragma eliminates Inst_Pkg.Proc from Q
|
||
pragma Eliminate (Q, Proc,
|
||
Source_Location => "gen_pkg.ads:4[q.adb:3]");</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Enable_Atomic_Synchronization" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Enable_Atomic_Synchronization [(Entity)];
|
||
|
||
Reenables atomic synchronization; see `pragma
|
||
Disable_Atomic_Synchronization' for details.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Exceptional_Cases" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Exceptional_Cases (EXCEPTIONAL_CASE_LIST);
|
||
|
||
EXCEPTIONAL_CASE_LIST ::= EXCEPTIONAL_CASE {, EXCEPTIONAL_CASE}
|
||
EXCEPTIONAL_CASE ::= exception_choice {'|' exception_choice} => CONSEQUENCE
|
||
CONSEQUENCE ::= Boolean_expression
|
||
|
||
For the semantics of this aspect, see the SPARK 2014 Reference Manual,
|
||
section 6.1.9.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Exit_Cases" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Exit_Cases (EXIT_CASE_LIST);
|
||
|
||
EXIT_CASE_LIST ::= EXIT_CASE {, EXIT_CASE}
|
||
EXIT_CASE ::= GUARD => EXIT_KIND
|
||
EXIT_KIND ::= Normal_Return
|
||
| Exception_Raised
|
||
| (Exception_Raised => exception_name)
|
||
| Program_Exit
|
||
GUARD ::= Boolean_expression
|
||
|
||
For the semantics of this aspect, see the SPARK 2014 Reference Manual,
|
||
section 6.1.10.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Export" origin="Ada RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Export ([Convention=>]convention_identifier,[Entity=>]local_name;</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Export_Function" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Export_Function (
|
||
[Internal =>] LOCAL_NAME
|
||
[, [External =>] EXTERNAL_SYMBOL]
|
||
[, [Parameter_Types =>] PARAMETER_TYPES]
|
||
[, [Result_Type =>] result_SUBTYPE_MARK]
|
||
[, [Mechanism =>] MECHANISM]
|
||
[, [Result_Mechanism =>] MECHANISM_NAME]);
|
||
|
||
EXTERNAL_SYMBOL ::=
|
||
IDENTIFIER
|
||
| static_string_EXPRESSION
|
||
| ""
|
||
|
||
PARAMETER_TYPES ::=
|
||
null
|
||
| TYPE_DESIGNATOR {, TYPE_DESIGNATOR}
|
||
|
||
TYPE_DESIGNATOR ::=
|
||
subtype_NAME
|
||
| subtype_Name ' Access
|
||
|
||
MECHANISM ::=
|
||
MECHANISM_NAME
|
||
| (MECHANISM_ASSOCIATION {, MECHANISM_ASSOCIATION})
|
||
|
||
MECHANISM_ASSOCIATION ::=
|
||
[formal_parameter_NAME =>] MECHANISM_NAME
|
||
|
||
MECHANISM_NAME ::= Value | Reference
|
||
|
||
Use this pragma to make a function externally callable and optionally
|
||
provide information on mechanisms to be used for passing parameter and
|
||
result values. We recommend, for the purposes of improving portability,
|
||
this pragma always be used in conjunction with a separate pragma
|
||
`Export', which must precede the pragma `Export_Function'. GNAT does
|
||
not require a separate pragma `Export', but if none is present,
|
||
`Convention Ada' is assumed, which is usually not what is wanted, so it
|
||
is usually appropriate to use this pragma in conjunction with a
|
||
`Export' or `Convention' pragma that specifies the desired foreign
|
||
convention. Pragma `Export_Function' (and `Export', if present) must
|
||
appear in the same declarative region as the function to which they
|
||
apply.
|
||
|
||
The `internal_name' must uniquely designate the function to which the
|
||
pragma applies. If more than one function name exists of this name in
|
||
the declarative part you must use the `Parameter_Types' and
|
||
`Result_Type' parameters to achieve the required unique designation.
|
||
The `subtype_mark's in these parameters must exactly match the subtypes
|
||
in the corresponding function specification, using positional notation
|
||
to match parameters with subtype marks. The form with an `'Access'
|
||
attribute can be used to match an anonymous access parameter.
|
||
|
||
Special treatment is given if the EXTERNAL is an explicit null string
|
||
or a static string expressions that evaluates to the null string. In
|
||
this case, no external name is generated. This form still allows the
|
||
specification of parameter mechanisms.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Export_Object" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Export_Object (
|
||
[Internal =>] LOCAL_NAME
|
||
[, [External =>] EXTERNAL_SYMBOL]
|
||
[, [Size =>] EXTERNAL_SYMBOL]);
|
||
|
||
EXTERNAL_SYMBOL ::=
|
||
IDENTIFIER
|
||
| static_string_EXPRESSION
|
||
|
||
This pragma designates an object as exported, and apart from the
|
||
extended rules for external symbols, is identical in effect to the use
|
||
of the normal `Export' pragma applied to an object. You may use a
|
||
separate Export pragma (and you probably should from the point of view
|
||
of portability), but it is not required. `Size' is syntax checked, but
|
||
otherwise ignored by GNAT.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Export_Procedure" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Export_Procedure (
|
||
[Internal =>] LOCAL_NAME
|
||
[, [External =>] EXTERNAL_SYMBOL]
|
||
[, [Parameter_Types =>] PARAMETER_TYPES]
|
||
[, [Mechanism =>] MECHANISM]);
|
||
|
||
EXTERNAL_SYMBOL ::=
|
||
IDENTIFIER
|
||
| static_string_EXPRESSION
|
||
| ""
|
||
|
||
PARAMETER_TYPES ::=
|
||
null
|
||
| TYPE_DESIGNATOR {, TYPE_DESIGNATOR}
|
||
|
||
TYPE_DESIGNATOR ::=
|
||
subtype_NAME
|
||
| subtype_Name ' Access
|
||
|
||
MECHANISM ::=
|
||
MECHANISM_NAME
|
||
| (MECHANISM_ASSOCIATION {, MECHANISM_ASSOCIATION})
|
||
|
||
MECHANISM_ASSOCIATION ::=
|
||
[formal_parameter_NAME =>] MECHANISM_NAME
|
||
|
||
MECHANISM_NAME ::= Value | Reference
|
||
|
||
This pragma is identical to `Export_Function' except that it applies to
|
||
a procedure rather than a function and the parameters `Result_Type' and
|
||
`Result_Mechanism' are not permitted. GNAT does not require a separate
|
||
pragma `Export', but if none is present, `Convention Ada' is assumed,
|
||
which is usually not what is wanted, so it is usually appropriate to
|
||
use this pragma in conjunction with a `Export' or `Convention' pragma
|
||
that specifies the desired foreign convention.
|
||
|
||
Special treatment is given if the EXTERNAL is an explicit null string
|
||
or a static string expressions that evaluates to the null string. In
|
||
this case, no external name is generated. This form still allows the
|
||
specification of parameter mechanisms.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Export_Valued_Procedure" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Export_Valued_Procedure (
|
||
[Internal =>] LOCAL_NAME
|
||
[, [External =>] EXTERNAL_SYMBOL]
|
||
[, [Parameter_Types =>] PARAMETER_TYPES]
|
||
[, [Mechanism =>] MECHANISM]);
|
||
|
||
EXTERNAL_SYMBOL ::=
|
||
IDENTIFIER
|
||
| static_string_EXPRESSION
|
||
| ""
|
||
|
||
PARAMETER_TYPES ::=
|
||
null
|
||
| TYPE_DESIGNATOR {, TYPE_DESIGNATOR}
|
||
|
||
TYPE_DESIGNATOR ::=
|
||
subtype_NAME
|
||
| subtype_Name ' Access
|
||
|
||
MECHANISM ::=
|
||
MECHANISM_NAME
|
||
| (MECHANISM_ASSOCIATION {, MECHANISM_ASSOCIATION})
|
||
|
||
MECHANISM_ASSOCIATION ::=
|
||
[formal_parameter_NAME =>] MECHANISM_NAME
|
||
|
||
MECHANISM_NAME ::= Value | Reference
|
||
|
||
This pragma is identical to `Export_Procedure' except that the first
|
||
parameter of `LOCAL_NAME', which must be present, must be of mode
|
||
`out', and externally the subprogram is treated as a function with this
|
||
parameter as the result of the function. GNAT provides for this
|
||
capability to allow the use of `out' and `in out' parameters in
|
||
interfacing to external functions (which are not permitted in Ada
|
||
functions). GNAT does not require a separate pragma `Export', but if
|
||
none is present, `Convention Ada' is assumed, which is almost certainly
|
||
not what is wanted since the whole point of this pragma is to interface
|
||
with foreign language functions, so it is usually appropriate to use
|
||
this pragma in conjunction with a `Export' or `Convention' pragma that
|
||
specifies the desired foreign convention.
|
||
|
||
Special treatment is given if the EXTERNAL is an explicit null string
|
||
or a static string expressions that evaluates to the null string. In
|
||
this case, no external name is generated. This form still allows the
|
||
specification of parameter mechanisms.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Extend_System" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Extend_System ([Name =>] IDENTIFIER);
|
||
|
||
This pragma is used to provide backwards compatibility with other
|
||
implementations that extend the facilities of package `System'. In
|
||
GNAT, `System' contains only the definitions that are present in the
|
||
Ada RM. However, other implementations, notably the DEC Ada 83
|
||
implementation, provide many extensions to package `System'.
|
||
|
||
For each such implementation accommodated by this pragma, GNAT provides
|
||
a package `Aux_XXX', e.g., `Aux_DEC' for the DEC Ada 83 implementation,
|
||
which provides the required additional definitions. You can use this
|
||
package in two ways. You can `with' it in the normal way and access
|
||
entities either by selection or using a `use' clause. In this case no
|
||
special processing is required.
|
||
|
||
However, if existing code contains references such as `System.XXX'
|
||
where `xxx' is an entity in the extended definitions provided in
|
||
package `System', you may use this pragma to extend visibility in
|
||
`System' in a non-standard way that provides greater compatibility with
|
||
the existing code. Pragma `Extend_System' is a configuration pragma
|
||
whose single argument is the name of the package containing the
|
||
extended definition (e.g., `Aux_DEC' for the DEC Ada case). A unit
|
||
compiled under control of this pragma will be processed using special
|
||
visibility processing that looks in package `System.Aux_XXX' where
|
||
`Aux_XXX' is the pragma argument for any entity referenced in package
|
||
`System', but not found in package `System'.
|
||
|
||
You can use this pragma either to access a predefined `System'
|
||
extension supplied with the compiler, for example `Aux_DEC' or you can
|
||
construct your own extension unit following the above definition. Note
|
||
that such a package is a child of `System' and thus is considered part
|
||
of the implementation. To compile it you will have to use the `-gnatg'
|
||
switch for compiling System units, as explained in the GNAT User’s
|
||
Guide.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Extensions_Allowed" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Extensions_Allowed (On | Off | All_Extensions);
|
||
|
||
This configuration pragma enables (via the “On” or
|
||
“All_Extensions” argument) or disables (via the “Off” argument)
|
||
the implementation extension mode; the pragma takes precedence over the
|
||
`-gnatX' and `-gnatX0' command switches.
|
||
|
||
If an argument of `"On"' is specified, the latest version of the Ada
|
||
language is implemented (currently Ada 2022) and, in addition, a
|
||
curated set of GNAT specific extensions are recognized. (See the list
|
||
here *note here: 6a.)
|
||
|
||
An argument of `"All_Extensions"' has the same effect except that some
|
||
extra experimental extensions are enabled (See the list here *note
|
||
here: 6b.)</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Extensions_Visible" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Extensions_Visible [ (static_boolean_EXPRESSION) ];
|
||
|
||
For the semantics of this pragma, see the entry for aspect
|
||
`Extensions_Visible' in the SPARK 2014 Reference Manual, section 6.1.7.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="External" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma External (
|
||
[ Convention =>] convention_IDENTIFIER,
|
||
[ Entity =>] LOCAL_NAME
|
||
[, [External_Name =>] static_string_EXPRESSION ]
|
||
[, [Link_Name =>] static_string_EXPRESSION ]);
|
||
|
||
This pragma is identical in syntax and semantics to pragma `Export' as
|
||
defined in the Ada Reference Manual. It is provided for compatibility
|
||
with some Ada 83 compilers that used this pragma for exactly the same
|
||
purposes as pragma `Export' before the latter was standardized.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="External_Name_Casing" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma External_Name_Casing (
|
||
Uppercase | Lowercase
|
||
[, Uppercase | Lowercase | As_Is]);
|
||
|
||
This pragma provides control over the casing of external names
|
||
associated with Import and Export pragmas. There are two cases to
|
||
consider:
|
||
|
||
* Implicit external names
|
||
|
||
Implicit external names are derived from identifiers. The most
|
||
common case arises when a standard Ada Import or Export pragma is
|
||
used with only two arguments, as in:
|
||
|
||
pragma Import (C, C_Routine);
|
||
|
||
Since Ada is a case-insensitive language, the spelling of the
|
||
identifier in the Ada source program does not provide any
|
||
information on the desired casing of the external name, and so a
|
||
convention is needed. In GNAT the default treatment is that such
|
||
names are converted to all lower case letters. This corresponds
|
||
to the normal C style in many environments. The first argument of
|
||
pragma `External_Name_Casing' can be used to control this
|
||
treatment. If `Uppercase' is specified, then the name will be
|
||
forced to all uppercase letters. If `Lowercase' is specified,
|
||
then the normal default of all lower case letters will be used.
|
||
|
||
This same implicit treatment is also used in the case of extended
|
||
DEC Ada 83 compatible Import and Export pragmas where an external
|
||
name is explicitly specified using an identifier rather than a
|
||
string.
|
||
|
||
* Explicit external names
|
||
|
||
Explicit external names are given as string literals. The most
|
||
common case arises when a standard Ada Import or Export pragma is
|
||
used with three arguments, as in:
|
||
|
||
pragma Import (C, C_Routine, "C_routine");
|
||
|
||
In this case, the string literal normally provides the exact
|
||
casing required for the external name. The second argument of
|
||
pragma `External_Name_Casing' may be used to modify this behavior.
|
||
If `Uppercase' is specified, then the name will be forced to all
|
||
uppercase letters. If `Lowercase' is specified, then the name
|
||
will be forced to all lowercase letters. A specification of
|
||
`As_Is' provides the normal default behavior in which the casing is
|
||
taken from the string provided.
|
||
|
||
This pragma may appear anywhere that a pragma is valid. In particular,
|
||
it can be used as a configuration pragma in the `gnat.adc' file, in
|
||
which case it applies to all subsequent compilations, or it can be used
|
||
as a program unit pragma, in which case it only applies to the current
|
||
unit, or it can be used more locally to control individual
|
||
Import/Export pragmas.
|
||
|
||
It was primarily intended for use with OpenVMS systems, where many
|
||
compilers convert all symbols to upper case by default. For
|
||
interfacing to such compilers (e.g., the DEC C compiler), it may be
|
||
convenient to use the pragma:
|
||
|
||
pragma External_Name_Casing (Uppercase, Uppercase);
|
||
|
||
to enforce the upper casing of all external symbols.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Fast_Math" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Fast_Math;
|
||
|
||
This is a configuration pragma which activates a mode in which speed is
|
||
considered more important for floating-point operations than absolutely
|
||
accurate adherence to the requirements of the standard. Currently the
|
||
following operations are affected:
|
||
|
||
`Complex Multiplication'
|
||
The normal simple formula for complex multiplication can result in
|
||
intermediate overflows for numbers near the end of the range. The
|
||
Ada standard requires that this situation be detected and
|
||
corrected by scaling, but in Fast_Math mode such cases will simply
|
||
result in overflow. Note that to take advantage of this you must
|
||
instantiate your own version of
|
||
`Ada.Numerics.Generic_Complex_Types' under control of the pragma,
|
||
rather than use the preinstantiated versions.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Favor_Top_Level" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Favor_Top_Level (type_LOCAL_NAME);
|
||
|
||
The argument of pragma `Favor_Top_Level' must be a named
|
||
access-to-subprogram type. This pragma is an efficiency hint to the
|
||
compiler, regarding the use of `'Access' or `'Unrestricted_Access' on
|
||
nested (non-library-level) subprograms. The pragma means that nested
|
||
subprograms are not used with this type, or are rare, so that the
|
||
generated code should be efficient in the top-level case. When this
|
||
pragma is used, dynamically generated trampolines may be used on some
|
||
targets for nested subprograms. See restriction
|
||
`No_Implicit_Dynamic_Code'.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Finalize_Storage_Only" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Finalize_Storage_Only (first_subtype_LOCAL_NAME);
|
||
|
||
The argument of pragma `Finalize_Storage_Only' must denote a local type
|
||
which is derived from `Ada.Finalization.Controlled' or
|
||
`Limited_Controlled'. The pragma suppresses the call to `Finalize' for
|
||
declared library-level objects of the argument type. This is mostly
|
||
useful for types where finalization is only used to deal with storage
|
||
reclamation since in most environments it is not necessary to reclaim
|
||
memory just before terminating execution, hence the name. Note that
|
||
this pragma does not suppress Finalize calls for library-level
|
||
heap-allocated objects (see pragma `No_Heap_Finalization').</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Float_Representation" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Float_Representation (FLOAT_REP[, float_type_LOCAL_NAME]);
|
||
|
||
FLOAT_REP ::= VAX_Float | IEEE_Float
|
||
|
||
In the one argument form, this pragma is a configuration pragma which
|
||
allows control over the internal representation chosen for the
|
||
predefined floating point types declared in the packages `Standard' and
|
||
`System'. This pragma is only provided for compatibility and has no
|
||
effect.
|
||
|
||
The two argument form specifies the representation to be used for the
|
||
specified floating-point type. The argument must be `IEEE_Float' to
|
||
specify the use of IEEE format, as follows:
|
||
|
||
* For a digits value of 6, 32-bit IEEE short format will be used.
|
||
|
||
* For a digits value of 15, 64-bit IEEE long format will be used.
|
||
|
||
* No other value of digits is permitted.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Generate_Deadlines" origin="Ada RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Generate_Deadlines;</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Ghost" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Ghost [ (static_boolean_EXPRESSION) ];
|
||
|
||
For the semantics of this pragma, see the entry for aspect `Ghost' in
|
||
the SPARK 2014 Reference Manual, section 6.9.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Global" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Global (GLOBAL_SPECIFICATION);
|
||
|
||
GLOBAL_SPECIFICATION ::=
|
||
null
|
||
| (GLOBAL_LIST)
|
||
| (MODED_GLOBAL_LIST {, MODED_GLOBAL_LIST})
|
||
|
||
MODED_GLOBAL_LIST ::= MODE_SELECTOR => GLOBAL_LIST
|
||
|
||
MODE_SELECTOR ::= In_Out | Input | Output | Proof_In
|
||
GLOBAL_LIST ::= GLOBAL_ITEM | (GLOBAL_ITEM {, GLOBAL_ITEM})
|
||
GLOBAL_ITEM ::= NAME
|
||
|
||
For the semantics of this pragma, see the entry for aspect `Global' in
|
||
the SPARK 2014 Reference Manual, section 6.1.4.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Ident" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Ident (static_string_EXPRESSION);
|
||
|
||
This pragma is identical in effect to pragma `Comment'. It is provided
|
||
for compatibility with other Ada compilers providing this pragma.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Ignore_Pragma" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Ignore_Pragma (pragma_IDENTIFIER);
|
||
|
||
This is a configuration pragma that takes a single argument that is a
|
||
simple identifier. Any subsequent use of a pragma whose pragma
|
||
identifier matches this argument will be silently ignored. Any
|
||
preceding use of a pragma whose pragma identifier matches this argument
|
||
will be parsed and then ignored. This may be useful when legacy code
|
||
or code intended for compilation with some other compiler contains
|
||
pragmas that match the name, but not the exact implementation, of a
|
||
GNAT pragma. The use of this pragma allows such pragmas to be ignored,
|
||
which may be useful in CodePeer mode, or during porting of legacy code.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Implementation_Defined" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Implementation_Defined (local_NAME);
|
||
|
||
This pragma marks a previously declared entity as
|
||
implementation-defined. For an overloaded entity, applies to the most
|
||
recent homonym.
|
||
|
||
pragma Implementation_Defined;
|
||
|
||
The form with no arguments appears anywhere within a scope, most
|
||
typically a package spec, and indicates that all entities that are
|
||
defined within the package spec are Implementation_Defined.
|
||
|
||
This pragma is used within the GNAT runtime library to identify
|
||
implementation-defined entities introduced in language-defined units,
|
||
for the purpose of implementing the No_Implementation_Identifiers
|
||
restriction.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Implemented" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Implemented (procedure_LOCAL_NAME, implementation_kind);
|
||
|
||
implementation_kind ::= By_Entry | By_Protected_Procedure | By_Any
|
||
|
||
This is an Ada 2012 representation pragma which applies to protected,
|
||
task and synchronized interface primitives. The use of pragma
|
||
Implemented provides a way to impose a static requirement on the
|
||
overriding operation by adhering to one of the three implementation
|
||
kinds: entry, protected procedure or any of the above. This pragma is
|
||
available in all earlier versions of Ada as an implementation-defined
|
||
pragma.
|
||
|
||
type Synch_Iface is synchronized interface;
|
||
procedure Prim_Op (Obj : in out Iface) is abstract;
|
||
pragma Implemented (Prim_Op, By_Protected_Procedure);
|
||
|
||
protected type Prot_1 is new Synch_Iface with
|
||
procedure Prim_Op; -- Legal
|
||
end Prot_1;
|
||
|
||
protected type Prot_2 is new Synch_Iface with
|
||
entry Prim_Op; -- Illegal
|
||
end Prot_2;
|
||
|
||
task type Task_Typ is new Synch_Iface with
|
||
entry Prim_Op; -- Illegal
|
||
end Task_Typ;
|
||
|
||
When applied to the procedure_or_entry_NAME of a requeue statement,
|
||
pragma Implemented determines the runtime behavior of the requeue.
|
||
Implementation kind By_Entry guarantees that the action of requeueing
|
||
will proceed from an entry to another entry. Implementation kind
|
||
By_Protected_Procedure transforms the requeue into a dispatching call,
|
||
thus eliminating the chance of blocking. Kind By_Any shares the
|
||
behavior of By_Entry and By_Protected_Procedure depending on the
|
||
target’s overriding subprogram kind.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Implicit_Packing" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Implicit_Packing;
|
||
|
||
This is a configuration pragma that requests implicit packing for packed
|
||
arrays for which a size clause is given but no explicit pragma Pack or
|
||
specification of Component_Size is present. It also applies to records
|
||
where no record representation clause is present. Consider this example:
|
||
|
||
type R is array (0 .. 7) of Boolean;
|
||
for R'Size use 8;
|
||
|
||
In accordance with the recommendation in the RM (RM 13.3(53)), a Size
|
||
clause does not change the layout of a composite object. So the Size
|
||
clause in the above example is normally rejected, since the default
|
||
layout of the array uses 8-bit components, and thus the array requires
|
||
a minimum of 64 bits.
|
||
|
||
If this declaration is compiled in a region of code covered by an
|
||
occurrence of the configuration pragma Implicit_Packing, then the Size
|
||
clause in this and similar examples will cause implicit packing and
|
||
thus be accepted. For this implicit packing to occur, the type in
|
||
question must be an array of small components whose size is known at
|
||
compile time, and the Size clause must specify the exact size that
|
||
corresponds to the number of elements in the array multiplied by the
|
||
size in bits of the component type (both single and multi-dimensioned
|
||
arrays can be controlled with this pragma).
|
||
|
||
Similarly, the following example shows the use in the record case
|
||
|
||
type r is record
|
||
a, b, c, d, e, f, g, h : boolean;
|
||
chr : character;
|
||
end record;
|
||
for r'size use 16;
|
||
|
||
Without a pragma Pack, each Boolean field requires 8 bits, so the
|
||
minimum size is 72 bits, but with a pragma Pack, 16 bits would be
|
||
sufficient. The use of pragma Implicit_Packing allows this record
|
||
declaration to compile without an explicit pragma Pack.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Import" origin="Ada RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Import ([Convention=>]convention_identifier,[Entity=>]local_name;</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Import_Function" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Import_Function (
|
||
[Internal =>] LOCAL_NAME,
|
||
[, [External =>] EXTERNAL_SYMBOL]
|
||
[, [Parameter_Types =>] PARAMETER_TYPES]
|
||
[, [Result_Type =>] SUBTYPE_MARK]
|
||
[, [Mechanism =>] MECHANISM]
|
||
[, [Result_Mechanism =>] MECHANISM_NAME]);
|
||
|
||
EXTERNAL_SYMBOL ::=
|
||
IDENTIFIER
|
||
| static_string_EXPRESSION
|
||
|
||
PARAMETER_TYPES ::=
|
||
null
|
||
| TYPE_DESIGNATOR {, TYPE_DESIGNATOR}
|
||
|
||
TYPE_DESIGNATOR ::=
|
||
subtype_NAME
|
||
| subtype_Name ' Access
|
||
|
||
MECHANISM ::=
|
||
MECHANISM_NAME
|
||
| (MECHANISM_ASSOCIATION {, MECHANISM_ASSOCIATION})
|
||
|
||
MECHANISM_ASSOCIATION ::=
|
||
[formal_parameter_NAME =>] MECHANISM_NAME
|
||
|
||
MECHANISM_NAME ::=
|
||
Value
|
||
| Reference
|
||
|
||
This pragma is used in conjunction with a pragma `Import' to specify
|
||
additional information for an imported function. The pragma `Import'
|
||
(or equivalent pragma `Interface') must precede the `Import_Function'
|
||
pragma and both must appear in the same declarative part as the
|
||
function specification.
|
||
|
||
The `Internal' argument must uniquely designate the function to which
|
||
the pragma applies. If more than one function name exists of this name
|
||
in the declarative part you must use the `Parameter_Types' and
|
||
`Result_Type' parameters to achieve the required unique designation.
|
||
Subtype marks in these parameters must exactly match the subtypes in
|
||
the corresponding function specification, using positional notation to
|
||
match parameters with subtype marks. The form with an `'Access'
|
||
attribute can be used to match an anonymous access parameter.
|
||
|
||
You may optionally use the `Mechanism' and `Result_Mechanism'
|
||
parameters to specify passing mechanisms for the parameters and result.
|
||
If you specify a single mechanism name, it applies to all parameters.
|
||
Otherwise you may specify a mechanism on a parameter by parameter basis
|
||
using either positional or named notation. If the mechanism is not
|
||
specified, the default mechanism is used.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Import_Object" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Import_Object (
|
||
[Internal =>] LOCAL_NAME
|
||
[, [External =>] EXTERNAL_SYMBOL]
|
||
[, [Size =>] EXTERNAL_SYMBOL]);
|
||
|
||
EXTERNAL_SYMBOL ::=
|
||
IDENTIFIER
|
||
| static_string_EXPRESSION
|
||
|
||
This pragma designates an object as imported, and apart from the
|
||
extended rules for external symbols, is identical in effect to the use
|
||
of the normal `Import' pragma applied to an object. Unlike the
|
||
subprogram case, you need not use a separate `Import' pragma, although
|
||
you may do so (and probably should do so from a portability point of
|
||
view). `size' is syntax checked, but otherwise ignored by GNAT.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Import_Procedure" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Import_Procedure (
|
||
[Internal =>] LOCAL_NAME
|
||
[, [External =>] EXTERNAL_SYMBOL]
|
||
[, [Parameter_Types =>] PARAMETER_TYPES]
|
||
[, [Mechanism =>] MECHANISM]);
|
||
|
||
EXTERNAL_SYMBOL ::=
|
||
IDENTIFIER
|
||
| static_string_EXPRESSION
|
||
|
||
PARAMETER_TYPES ::=
|
||
null
|
||
| TYPE_DESIGNATOR {, TYPE_DESIGNATOR}
|
||
|
||
TYPE_DESIGNATOR ::=
|
||
subtype_NAME
|
||
| subtype_Name ' Access
|
||
|
||
MECHANISM ::=
|
||
MECHANISM_NAME
|
||
| (MECHANISM_ASSOCIATION {, MECHANISM_ASSOCIATION})
|
||
|
||
MECHANISM_ASSOCIATION ::=
|
||
[formal_parameter_NAME =>] MECHANISM_NAME
|
||
|
||
MECHANISM_NAME ::= Value | Reference
|
||
|
||
This pragma is identical to `Import_Function' except that it applies to
|
||
a procedure rather than a function and the parameters `Result_Type' and
|
||
`Result_Mechanism' are not permitted.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Import_Valued_Procedure" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Import_Valued_Procedure (
|
||
[Internal =>] LOCAL_NAME
|
||
[, [External =>] EXTERNAL_SYMBOL]
|
||
[, [Parameter_Types =>] PARAMETER_TYPES]
|
||
[, [Mechanism =>] MECHANISM]);
|
||
|
||
EXTERNAL_SYMBOL ::=
|
||
IDENTIFIER
|
||
| static_string_EXPRESSION
|
||
|
||
PARAMETER_TYPES ::=
|
||
null
|
||
| TYPE_DESIGNATOR {, TYPE_DESIGNATOR}
|
||
|
||
TYPE_DESIGNATOR ::=
|
||
subtype_NAME
|
||
| subtype_Name ' Access
|
||
|
||
MECHANISM ::=
|
||
MECHANISM_NAME
|
||
| (MECHANISM_ASSOCIATION {, MECHANISM_ASSOCIATION})
|
||
|
||
MECHANISM_ASSOCIATION ::=
|
||
[formal_parameter_NAME =>] MECHANISM_NAME
|
||
|
||
MECHANISM_NAME ::= Value | Reference
|
||
|
||
This pragma is identical to `Import_Procedure' except that the first
|
||
parameter of `LOCAL_NAME', which must be present, must be of mode
|
||
`out', and externally the subprogram is treated as a function with this
|
||
parameter as the result of the function. The purpose of this
|
||
capability is to allow the use of `out' and `in out' parameters in
|
||
interfacing to external functions (which are not permitted in Ada
|
||
functions). You may optionally use the `Mechanism' parameters to
|
||
specify passing mechanisms for the parameters. If you specify a single
|
||
mechanism name, it applies to all parameters. Otherwise you may
|
||
specify a mechanism on a parameter by parameter basis using either
|
||
positional or named notation. If the mechanism is not specified, the
|
||
default mechanism is used.
|
||
|
||
Note that it is important to use this pragma in conjunction with a
|
||
separate pragma Import that specifies the desired convention, since
|
||
otherwise the default convention is Ada, which is almost certainly not
|
||
what is required.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Independent" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Independent (component_LOCAL_NAME);
|
||
|
||
This pragma is standard in Ada 2012 mode (which also provides an aspect
|
||
of the same name). It is also available as an implementation-defined
|
||
pragma in all earlier versions. It specifies that the designated object
|
||
or all objects of the designated type must be independently
|
||
addressable. This means that separate tasks can safely manipulate such
|
||
objects. For example, if two components of a record are independent,
|
||
then two separate tasks may access these two components. This may place
|
||
constraints on the representation of the object (for instance
|
||
prohibiting tight packing).</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Independent_Components" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Independent_Components (Local_NAME);
|
||
|
||
This pragma is standard in Ada 2012 mode (which also provides an aspect
|
||
of the same name). It is also available as an implementation-defined
|
||
pragma in all earlier versions. It specifies that the components of the
|
||
designated object, or the components of each object of the designated
|
||
type, must be independently addressable. This means that separate tasks
|
||
can safely manipulate separate components in the composite object. This
|
||
may place constraints on the representation of the object (for instance
|
||
prohibiting tight packing).</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Initial_Condition" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Initial_Condition (boolean_EXPRESSION);
|
||
|
||
For the semantics of this pragma, see the entry for aspect
|
||
`Initial_Condition' in the SPARK 2014 Reference Manual, section 7.1.6.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Initialize_Scalars" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Initialize_Scalars
|
||
[ ( TYPE_VALUE_PAIR {, TYPE_VALUE_PAIR} ) ];
|
||
|
||
TYPE_VALUE_PAIR ::=
|
||
SCALAR_TYPE => static_EXPRESSION
|
||
|
||
SCALAR_TYPE :=
|
||
Short_Float
|
||
| Float
|
||
| Long_Float
|
||
| Long_Long_Flat
|
||
| Signed_8
|
||
| Signed_16
|
||
| Signed_32
|
||
| Signed_64
|
||
| Unsigned_8
|
||
| Unsigned_16
|
||
| Unsigned_32
|
||
| Unsigned_64
|
||
|
||
This pragma is similar to `Normalize_Scalars' conceptually but has two
|
||
important differences.
|
||
|
||
First, there is no requirement for the pragma to be used uniformly in
|
||
all units of a partition. In particular, it is fine to use this just
|
||
for some or all of the application units of a partition, without
|
||
needing to recompile the run-time library. In the case where some units
|
||
are compiled with the pragma, and some without, then a declaration of a
|
||
variable where the type is defined in package Standard or is locally
|
||
declared will always be subject to initialization, as will any
|
||
declaration of a scalar variable. For composite variables, whether the
|
||
variable is initialized may also depend on whether the package in which
|
||
the type of the variable is declared is compiled with the pragma.
|
||
|
||
The other important difference is that the programmer can control the
|
||
value used for initializing scalar objects. This effect can be achieved
|
||
in several different ways:
|
||
|
||
* At compile time, the programmer can specify the invalid value for a
|
||
particular family of scalar types using the optional arguments of
|
||
the pragma.
|
||
|
||
The compile-time approach is intended to optimize the generated
|
||
code for the pragma, by possibly using fast operations such as
|
||
`memset'. Note that such optimizations require using values where
|
||
the bytes all have the same binary representation.
|
||
|
||
* At bind time, the programmer has several options:
|
||
|
||
* Initialization with invalid values (similar to
|
||
Normalize_Scalars, though for Initialize_Scalars it is not
|
||
always possible to determine the invalid values in complex
|
||
cases like signed component fields with nonstandard sizes).
|
||
|
||
* Initialization with high values.
|
||
|
||
* Initialization with low values.
|
||
|
||
* Initialization with a specific bit pattern.
|
||
|
||
See the GNAT User’s Guide for binder options for specifying
|
||
these cases.
|
||
|
||
The bind-time approach is intended to provide fast turnaround for
|
||
testing with different values, without having to recompile the
|
||
program.
|
||
|
||
* At execution time, the programmer can specify the invalid values
|
||
using an environment variable. See the GNAT User’s Guide for
|
||
details.
|
||
|
||
The execution-time approach is intended to provide fast turnaround
|
||
for testing with different values, without having to recompile and
|
||
rebind the program.
|
||
|
||
Note that pragma `Initialize_Scalars' is particularly useful in
|
||
conjunction with the enhanced validity checking that is now provided in
|
||
GNAT, which checks for invalid values under more conditions. Using this
|
||
feature (see description of the `-gnatV' flag in the GNAT User’s
|
||
Guide) in conjunction with pragma `Initialize_Scalars' provides a
|
||
powerful new tool to assist in the detection of problems caused by
|
||
uninitialized variables.
|
||
|
||
Note: the use of `Initialize_Scalars' has a fairly extensive effect on
|
||
the generated code. This may cause your code to be substantially
|
||
larger. It may also cause an increase in the amount of stack required,
|
||
so it is probably a good idea to turn on stack checking (see
|
||
description of stack checking in the GNAT User’s Guide) when using
|
||
this pragma.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Initializes" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Initializes (INITIALIZATION_LIST);
|
||
|
||
INITIALIZATION_LIST ::=
|
||
null
|
||
| (INITIALIZATION_ITEM {, INITIALIZATION_ITEM})
|
||
|
||
INITIALIZATION_ITEM ::= name [=> INPUT_LIST]
|
||
|
||
INPUT_LIST ::=
|
||
null
|
||
| INPUT
|
||
| (INPUT {, INPUT})
|
||
|
||
INPUT ::= name
|
||
|
||
For the semantics of this pragma, see the entry for aspect
|
||
`Initializes' in the SPARK 2014 Reference Manual, section 7.1.5.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Inline" origin="Ada RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Inline;</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Inline_Always" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Inline_Always (NAME [, NAME]);
|
||
|
||
Similar to pragma `Inline' except that inlining is unconditional.
|
||
Inline_Always instructs the compiler to inline every direct call to the
|
||
subprogram or else to emit a compilation error, independently of any
|
||
option, in particular `-gnatn' or `-gnatN' or the optimization level.
|
||
It is an error to take the address or access of `NAME'. It is also an
|
||
error to apply this pragma to a primitive operation of a tagged type.
|
||
Thanks to such restrictions, the compiler is allowed to remove the
|
||
out-of-line body of `NAME'.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Inline_Generic" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Inline_Generic (GNAME {, GNAME});
|
||
|
||
GNAME ::= generic_unit_NAME | generic_instance_NAME
|
||
|
||
This pragma is provided for compatibility with Dec Ada 83. It has no
|
||
effect in GNAT (which always inlines generics), other than to check
|
||
that the given names are all names of generic units or generic
|
||
instances.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Inspection_Point" origin="Ada RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Inspection_Point [(object_name {, object_name})];</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Interface" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Interface (
|
||
[Convention =>] convention_identifier,
|
||
[Entity =>] local_NAME
|
||
[, [External_Name =>] static_string_expression]
|
||
[, [Link_Name =>] static_string_expression]);
|
||
|
||
This pragma is identical in syntax and semantics to the standard Ada
|
||
pragma `Import'. It is provided for compatibility with Ada 83. The
|
||
definition is upwards compatible both with pragma `Interface' as
|
||
defined in the Ada 83 Reference Manual, and also with some extended
|
||
implementations of this pragma in certain Ada 83 implementations. The
|
||
only difference between pragma `Interface' and pragma `Import' is that
|
||
there is special circuitry to allow both pragmas to appear for the same
|
||
subprogram entity (normally it is illegal to have multiple `Import'
|
||
pragmas). This is useful in maintaining Ada 83/Ada 95 compatibility and
|
||
is compatible with other Ada 83 compilers.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Interface_Name" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Interface_Name (
|
||
[Entity =>] LOCAL_NAME
|
||
[, [External_Name =>] static_string_EXPRESSION]
|
||
[, [Link_Name =>] static_string_EXPRESSION]);
|
||
|
||
This pragma provides an alternative way of specifying the interface name
|
||
for an interfaced subprogram, and is provided for compatibility with Ada
|
||
83 compilers that use the pragma for this purpose. You must provide at
|
||
least one of `External_Name' or `Link_Name'.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Interrupt_Handler" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Interrupt_Handler (procedure_LOCAL_NAME);
|
||
|
||
This program unit pragma is supported for parameterless protected
|
||
procedures as described in Annex C of the Ada Reference Manual.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Interrupt_Priority" origin="Ada RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Interrupt_Priority;</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Interrupt_State" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Interrupt_State
|
||
([Name =>] value,
|
||
[State =>] SYSTEM | RUNTIME | USER);
|
||
|
||
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 an `Ctrl-C' interrupt. Normally this
|
||
interrupt is reserved to the implementation, so that `Ctrl-C' can be
|
||
used to interrupt execution. Additionally, signals such as `SIGSEGV',
|
||
`SIGABRT', `SIGFPE' and `SIGILL' are often mapped to specific Ada
|
||
exceptions, or used to implement run-time functions such as the `abort'
|
||
statement and stack overflow checking.
|
||
|
||
Pragma `Interrupt_State' provides a general mechanism for overriding
|
||
such uses of interrupts. It subsumes the functionality of pragma
|
||
`Unreserve_All_Interrupts'. Pragma `Interrupt_State' is not available
|
||
on Windows. On all other platforms than VxWorks, it applies to
|
||
signals; on VxWorks, it applies to vectored hardware interrupts and may
|
||
be used to mark interrupts required by the board support package as
|
||
reserved.
|
||
|
||
Interrupts can be in one of three states:
|
||
|
||
* System
|
||
|
||
The interrupt is reserved (no Ada handler can be installed), and
|
||
the Ada run-time may not install a handler. As a result you are
|
||
guaranteed standard system default action if this interrupt is
|
||
raised. This also allows installing a low level handler via C APIs
|
||
such as sigaction(), outside of Ada control.
|
||
|
||
* Runtime
|
||
|
||
The interrupt is reserved (no Ada handler can be installed). The
|
||
run time is allowed to install a handler for internal control
|
||
purposes, but is not required to do so.
|
||
|
||
* User
|
||
|
||
The interrupt is unreserved. The user may install an Ada handler
|
||
via Ada.Interrupts and pragma Interrupt_Handler or Attach_Handler
|
||
to provide some other action.
|
||
|
||
These states are the allowed values of the `State' parameter of the
|
||
pragma. The `Name' parameter is a value of the type
|
||
`Ada.Interrupts.Interrupt_ID'. Typically, it is a name declared in
|
||
`Ada.Interrupts.Names'.
|
||
|
||
This is a configuration pragma, and the binder will check that there
|
||
are no inconsistencies between different units in a partition in how a
|
||
given interrupt is specified. It may appear anywhere a pragma is legal.
|
||
|
||
The effect is to move the interrupt to the specified state.
|
||
|
||
By declaring interrupts to be SYSTEM, you guarantee the standard system
|
||
action, such as a core dump.
|
||
|
||
By declaring interrupts to be USER, you guarantee that you can install
|
||
a handler.
|
||
|
||
Note that certain signals on many operating systems cannot be caught and
|
||
handled by applications. In such cases, the pragma is ignored. See the
|
||
operating system documentation, or the value of the array `Reserved'
|
||
declared in the spec of package `System.OS_Interface'.
|
||
|
||
Overriding the default state of signals used by the Ada runtime may
|
||
interfere with an application’s runtime behavior in the cases of the
|
||
synchronous signals, and in the case of the signal used to implement
|
||
the `abort' statement.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Interrupts_System_By_Default" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Interrupts_System_By_Default;
|
||
|
||
Default all interrupts to the System state as defined above in pragma
|
||
`Interrupt_State'. This is a configuration pragma.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Invariant" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Invariant
|
||
([Entity =>] private_type_LOCAL_NAME,
|
||
[Check =>] EXPRESSION
|
||
[,[Message =>] String_Expression]);
|
||
|
||
This pragma provides exactly the same capabilities as the
|
||
Type_Invariant aspect defined in AI05-0146-1, and in the Ada 2012
|
||
Reference Manual. The Type_Invariant aspect is fully implemented in Ada
|
||
2012 mode, but since it requires the use of the aspect syntax, which is
|
||
not available except in 2012 mode, it is not possible to use the
|
||
Type_Invariant aspect in earlier versions of Ada. However the Invariant
|
||
pragma may be used in any version of Ada. Also note that the aspect
|
||
Invariant is a synonym in GNAT for the aspect Type_Invariant, but there
|
||
is no pragma Type_Invariant.
|
||
|
||
The pragma must appear within the visible part of the package
|
||
specification, after the type to which its Entity argument appears. As
|
||
with the Invariant aspect, the Check expression is not analyzed until
|
||
the end of the visible part of the package, so it may contain forward
|
||
references. The Message argument, if present, provides the exception
|
||
message used if the invariant is violated. If no Message parameter is
|
||
provided, a default message that identifies the line on which the
|
||
pragma appears is used.
|
||
|
||
It is permissible to have multiple Invariants for the same type entity,
|
||
in which case they are and’ed together. It is permissible to use this
|
||
pragma in Ada 2012 mode, but you cannot have both an invariant aspect
|
||
and an invariant pragma for the same entity.
|
||
|
||
For further details on the use of this pragma, see the Ada 2012
|
||
documentation of the Type_Invariant aspect.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Keep_Names" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Keep_Names ([On =>] enumeration_first_subtype_LOCAL_NAME);
|
||
|
||
The `LOCAL_NAME' argument must refer to an enumeration first subtype in
|
||
the current declarative part. The effect is to retain the enumeration
|
||
literal names for use by `Image' and `Value' even if a global
|
||
`Discard_Names' pragma applies. This is useful when you want to
|
||
generally suppress enumeration literal names and for example you
|
||
therefore use a `Discard_Names' pragma in the `gnat.adc' file, but you
|
||
want to retain the names for specific enumeration types.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="License" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma License (Unrestricted | GPL | Modified_GPL | Restricted);
|
||
|
||
This pragma is provided to allow automated checking for appropriate
|
||
license conditions with respect to the standard and modified GPL. A
|
||
pragma `License', which is a configuration pragma that typically
|
||
appears at the start of a source file or in a separate `gnat.adc' file,
|
||
specifies the licensing conditions of a unit as follows:
|
||
|
||
* Unrestricted This is used for a unit that can be freely used with
|
||
no license restrictions. Examples of such units are public domain
|
||
units, and units from the Ada Reference Manual.
|
||
|
||
* GPL This is used for a unit that is licensed under the unmodified
|
||
GPL, and which therefore cannot be `with'ed by a restricted unit.
|
||
|
||
* Modified_GPL This is used for a unit licensed under the GNAT
|
||
modified GPL that includes a special exception paragraph that
|
||
specifically permits the inclusion of the unit in programs without
|
||
requiring the entire program to be released under the GPL.
|
||
|
||
* Restricted This is used for a unit that is restricted in that it
|
||
is not permitted to depend on units that are licensed under the
|
||
GPL. Typical examples are proprietary code that is to be released
|
||
under more restrictive license conditions. Note that restricted
|
||
units are permitted to `with' units which are licensed under the
|
||
modified GPL (this is the whole point of the modified GPL).
|
||
|
||
Normally a unit with no `License' pragma is considered to have an
|
||
unknown license, and no checking is done. However, standard GNAT
|
||
headers are recognized, and license information is derived from them as
|
||
follows.
|
||
|
||
A GNAT license header starts with a line containing 78 hyphens. The
|
||
following comment text is searched for the appearance of any of the
|
||
following strings.
|
||
|
||
If the string ‘GNU General Public License’ is found, then the unit
|
||
is assumed to have GPL license, unless the string ‘As a special
|
||
exception’ follows, in which case the license is assumed to be
|
||
modified GPL.
|
||
|
||
If one of the strings ‘This specification is adapted from the Ada
|
||
Semantic Interface’ or ‘This specification is derived from the Ada
|
||
Reference Manual’ is found then the unit is assumed to be
|
||
unrestricted.
|
||
|
||
These default actions means that a program with a restricted license
|
||
pragma will automatically get warnings if a GPL unit is inappropriately
|
||
`with'ed. For example, the program:
|
||
|
||
with Sem_Ch3;
|
||
with GNAT.Sockets;
|
||
procedure Secret_Stuff is
|
||
|
||
end Secret_Stuff
|
||
|
||
if compiled with pragma `License' (`Restricted') in a `gnat.adc' file
|
||
will generate the warning:
|
||
|
||
with Sem_Ch3;
|
||
|
|
||
>>> license of withed unit "Sem_Ch3" is incompatible
|
||
|
||
with GNAT.Sockets;
|
||
procedure Secret_Stuff is
|
||
|
||
Here we get a warning on `Sem_Ch3' since it is part of the GNAT
|
||
compiler and is licensed under the GPL, but no warning for
|
||
`GNAT.Sockets' which is part of the GNAT run time, and is therefore
|
||
licensed under the modified GPL.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Link_With" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Link_With (static_string_EXPRESSION {,static_string_EXPRESSION});
|
||
|
||
This pragma is provided for compatibility with certain Ada 83 compilers.
|
||
It has exactly the same effect as pragma `Linker_Options' except that
|
||
spaces occurring within one of the string expressions are treated as
|
||
separators. For example, in the following case:
|
||
|
||
pragma Link_With ("-labc -ldef");
|
||
|
||
results in passing the strings `-labc' and `-ldef' as two separate
|
||
arguments to the linker. In addition pragma Link_With allows multiple
|
||
arguments, with the same effect as successive pragmas.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Linker_Alias" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Linker_Alias (
|
||
[Entity =>] LOCAL_NAME,
|
||
[Target =>] static_string_EXPRESSION);
|
||
|
||
`LOCAL_NAME' must refer to an object that is declared at the library
|
||
level. This pragma establishes the given entity as a linker alias for
|
||
the given target. It is equivalent to `__attribute__((alias))' in GNU C
|
||
and causes `LOCAL_NAME' to be emitted as an alias for the symbol
|
||
`static_string_EXPRESSION' in the object file, that is to say no space
|
||
is reserved for `LOCAL_NAME' by the assembler and it will be resolved
|
||
to the same address as `static_string_EXPRESSION' by the linker.
|
||
|
||
The actual linker name for the target must be used (e.g., the fully
|
||
encoded name with qualification in Ada, or the mangled name in C++), or
|
||
it must be declared using the C convention with `pragma Import' or
|
||
`pragma Export'.
|
||
|
||
Not all target machines support this pragma. On some of them it is
|
||
accepted only if `pragma Weak_External' has been applied to
|
||
`LOCAL_NAME'.
|
||
|
||
-- Example of the use of pragma Linker_Alias
|
||
|
||
package p is
|
||
i : Integer := 1;
|
||
pragma Export (C, i);
|
||
|
||
new_name_for_i : Integer;
|
||
pragma Linker_Alias (new_name_for_i, "i");
|
||
end p;</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Linker_Constructor" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Linker_Constructor (procedure_LOCAL_NAME);
|
||
|
||
`procedure_LOCAL_NAME' must refer to a parameterless procedure that is
|
||
declared at the library level. A procedure to which this pragma is
|
||
applied will be treated as an initialization routine by the linker. It
|
||
is equivalent to `__attribute__((constructor))' in GNU C and causes
|
||
`procedure_LOCAL_NAME' to be invoked before the entry point of the
|
||
executable is called (or immediately after the shared library is loaded
|
||
if the procedure is linked in a shared library), in particular before
|
||
the Ada run-time environment is set up.
|
||
|
||
Because of these specific contexts, the set of operations such a
|
||
procedure can perform is very limited and the type of objects it can
|
||
manipulate is essentially restricted to the elementary types. In
|
||
particular, it must only contain code to which pragma Restrictions
|
||
(No_Elaboration_Code) applies.
|
||
|
||
This pragma is used by GNAT to implement auto-initialization of shared
|
||
Stand Alone Libraries, which provides a related capability without the
|
||
restrictions listed above. Where possible, the use of Stand Alone
|
||
Libraries is preferable to the use of this pragma.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Linker_Destructor" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Linker_Destructor (procedure_LOCAL_NAME);
|
||
|
||
`procedure_LOCAL_NAME' must refer to a parameterless procedure that is
|
||
declared at the library level. A procedure to which this pragma is
|
||
applied will be treated as a finalization routine by the linker. It is
|
||
equivalent to `__attribute__((destructor))' in GNU C and causes
|
||
`procedure_LOCAL_NAME' to be invoked after the entry point of the
|
||
executable has exited (or immediately before the shared library is
|
||
unloaded if the procedure is linked in a shared library), in particular
|
||
after the Ada run-time environment is shut down.
|
||
|
||
See `pragma Linker_Constructor' for the set of restrictions that apply
|
||
because of these specific contexts.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Linker_Options" origin="Ada RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Linker_Options (string_expression);</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Linker_Section" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Linker_Section (
|
||
[Entity =>] LOCAL_NAME,
|
||
[Section =>] static_string_EXPRESSION);
|
||
|
||
`LOCAL_NAME' must refer to an object, type, or subprogram that is
|
||
declared at the library level. This pragma specifies the name of the
|
||
linker section for the given entity. It is equivalent to
|
||
`__attribute__((section))' in GNU C and causes `LOCAL_NAME' to be
|
||
placed in the `static_string_EXPRESSION' section of the executable
|
||
(assuming the linker doesn’t rename the section). GNAT also provides
|
||
an implementation defined aspect of the same name.
|
||
|
||
In the case of specifying this aspect for a type, the effect is to
|
||
specify the corresponding section for all library-level objects of the
|
||
type that do not have an explicit linker section set. Note that this
|
||
only applies to whole objects, not to components of composite objects.
|
||
|
||
In the case of a subprogram, the linker section applies to all
|
||
previously declared matching overloaded subprograms in the current
|
||
declarative part which do not already have a linker section assigned.
|
||
The linker section aspect is useful in this case for specifying
|
||
different linker sections for different elements of such an overloaded
|
||
set.
|
||
|
||
Note that an empty string specifies that no linker section is specified.
|
||
This is not quite the same as omitting the pragma or aspect, since it
|
||
can be used to specify that one element of an overloaded set of
|
||
subprograms has the default linker section, or that one object of a
|
||
type for which a linker section is specified should has the default
|
||
linker section.
|
||
|
||
The compiler normally places library-level entities in standard sections
|
||
depending on the class: procedures and functions generally go in the
|
||
`.text' section, initialized variables in the `.data' section and
|
||
uninitialized variables in the `.bss' section.
|
||
|
||
Other, special sections may exist on given target machines to map
|
||
special hardware, for example I/O ports or flash memory. This pragma is
|
||
a means to defer the final layout of the executable to the linker, thus
|
||
fully working at the symbolic level with the compiler.
|
||
|
||
Some file formats do not support arbitrary sections so not all target
|
||
machines support this pragma. The use of this pragma may cause a program
|
||
execution to be erroneous if it is used to place an entity into an
|
||
inappropriate section (e.g., a modified variable into the `.text'
|
||
section). See also `pragma Persistent_BSS'.
|
||
|
||
-- Example of the use of pragma Linker_Section
|
||
|
||
package IO_Card is
|
||
Port_A : Integer;
|
||
pragma Volatile (Port_A);
|
||
pragma Linker_Section (Port_A, ".bss.port_a");
|
||
|
||
Port_B : Integer;
|
||
pragma Volatile (Port_B);
|
||
pragma Linker_Section (Port_B, ".bss.port_b");
|
||
|
||
type Port_Type is new Integer with Linker_Section => ".bss";
|
||
PA : Port_Type with Linker_Section => ".bss.PA";
|
||
PB : Port_Type; -- ends up in linker section ".bss"
|
||
|
||
procedure Q with Linker_Section => "Qsection";
|
||
end IO_Card;</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="List" origin="Ada RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma List (identifier);</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Lock_Free" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Lock_Free [ (static_boolean_EXPRESSION) ];
|
||
|
||
This pragma may be specified for protected types or objects. It
|
||
specifies that the implementation of protected operations must be
|
||
implemented without locks. Compilation fails if the compiler cannot
|
||
generate lock-free code for the operations.
|
||
|
||
The current conditions required to support this pragma are:
|
||
|
||
* Protected type declarations may not contain entries
|
||
|
||
* Protected subprogram declarations may not have nonelementary
|
||
parameters
|
||
|
||
In addition, each protected subprogram body must satisfy:
|
||
|
||
* May reference only one protected component
|
||
|
||
* May not reference nonconstant entities outside the protected
|
||
subprogram scope
|
||
|
||
* May not contain address representation items, allocators, or
|
||
quantified expressions
|
||
|
||
* May not contain delay, goto, loop, or procedure-call statements
|
||
|
||
* May not contain exported and imported entities
|
||
|
||
* May not dereferenced access values
|
||
|
||
* Function calls and attribute references must be static
|
||
|
||
If the Lock_Free aspect is specified to be True for a protected unit
|
||
and the Ceiling_Locking locking policy is in effect, then the run-time
|
||
actions associated with the Ceiling_Locking locking policy (described in
|
||
Ada RM D.3) are not performed when a protected operation of the
|
||
protected unit is executed.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Locking_Policy" origin="Ada RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Locking_Policy (policy_identifier);</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Loop_Invariant" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Loop_Invariant ( boolean_EXPRESSION );
|
||
|
||
The effect of this pragma is similar to that of pragma `Assert', except
|
||
that in an `Assertion_Policy' pragma, the identifier `Loop_Invariant'
|
||
is used to control whether it is ignored or checked (or disabled).
|
||
|
||
`Loop_Invariant' can only appear as 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. The intention is
|
||
that it be used to represent a “loop invariant” assertion, i.e.
|
||
something that is true each time through the loop, and which can be
|
||
used to show that the loop is achieving its purpose.
|
||
|
||
Multiple `Loop_Invariant' and `Loop_Variant' pragmas that apply to the
|
||
same loop should be grouped in the same sequence of statements.
|
||
|
||
To aid in writing such invariants, the special attribute `Loop_Entry'
|
||
may be used to refer to the value of an expression on entry to the
|
||
loop. This attribute can only be used within the expression of a
|
||
`Loop_Invariant' pragma. For full details, see documentation of
|
||
attribute `Loop_Entry'.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Loop_Optimize" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Loop_Optimize (OPTIMIZATION_HINT {, OPTIMIZATION_HINT});
|
||
|
||
OPTIMIZATION_HINT ::= Ivdep | No_Unroll | Unroll | No_Vector | Vector
|
||
|
||
This pragma must appear immediately within a loop statement. It allows
|
||
the programmer to specify optimization hints for the enclosing loop.
|
||
The hints are not mutually exclusive and can be freely mixed, but not
|
||
all combinations will yield a sensible outcome.
|
||
|
||
There are five supported optimization hints for a loop:
|
||
|
||
* Ivdep
|
||
|
||
The programmer asserts that there are no loop-carried dependencies
|
||
which would prevent consecutive iterations of the loop from being
|
||
executed simultaneously.
|
||
|
||
* No_Unroll
|
||
|
||
The loop must not be unrolled. This is a strong hint: the
|
||
compiler will not unroll a loop marked with this hint.
|
||
|
||
* Unroll
|
||
|
||
The loop should be unrolled. This is a weak hint: the compiler
|
||
will try to apply unrolling to this loop preferably to other
|
||
optimizations, notably vectorization, but there is no guarantee
|
||
that the loop will be unrolled.
|
||
|
||
* No_Vector
|
||
|
||
The loop must not be vectorized. This is a strong hint: the
|
||
compiler will not vectorize a loop marked with this hint.
|
||
|
||
* Vector
|
||
|
||
The loop should be vectorized. This is a weak hint: the compiler
|
||
will try to apply vectorization to this loop preferably to other
|
||
optimizations, notably unrolling, but there is no guarantee that
|
||
the loop will be vectorized.
|
||
|
||
These hints do not remove the need to pass the appropriate switches to
|
||
the compiler in order to enable the relevant optimizations, that is to
|
||
say `-funroll-loops' for unrolling and `-ftree-vectorize' for
|
||
vectorization.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Loop_Variant" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Loop_Variant ( LOOP_VARIANT_ITEM {, LOOP_VARIANT_ITEM } );
|
||
LOOP_VARIANT_ITEM ::= CHANGE_DIRECTION => discrete_EXPRESSION
|
||
CHANGE_DIRECTION ::= Increases | Decreases
|
||
|
||
`Loop_Variant' can only appear as 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. It allows the
|
||
specification of quantities which must always decrease or increase in
|
||
successive iterations of the loop. In its simplest form, just one
|
||
expression is specified, whose value must increase or decrease on each
|
||
iteration of the loop.
|
||
|
||
In a more complex form, multiple arguments can be given which are
|
||
interpreted in a nesting lexicographic manner. For example:
|
||
|
||
pragma Loop_Variant (Increases => X, Decreases => Y);
|
||
|
||
specifies that each time through the loop either X increases, or X stays
|
||
the same and Y decreases. A `Loop_Variant' pragma ensures that the loop
|
||
is making progress. It can be useful in helping to show informally or
|
||
prove formally that the loop always terminates.
|
||
|
||
`Loop_Variant' is an assertion whose effect can be controlled using an
|
||
`Assertion_Policy' with a check name of `Loop_Variant'. The policy can
|
||
be `Check' to enable the loop variant check, `Ignore' to ignore the
|
||
check (in which case the pragma has no effect on the program), or
|
||
`Disable' in which case the pragma is not even checked for correct
|
||
syntax.
|
||
|
||
Multiple `Loop_Invariant' and `Loop_Variant' pragmas that apply to the
|
||
same loop should be grouped in the same sequence of statements.
|
||
|
||
The `Loop_Entry' attribute may be used within the expressions of the
|
||
`Loop_Variant' pragma to refer to values on entry to the loop.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Machine_Attribute" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Machine_Attribute (
|
||
[Entity =>] LOCAL_NAME,
|
||
[Attribute_Name =>] static_string_EXPRESSION
|
||
[, [Info =>] static_EXPRESSION {, static_EXPRESSION}] );
|
||
|
||
Machine-dependent attributes can be specified for types and/or
|
||
declarations. This pragma is semantically equivalent to
|
||
`__attribute__((ATTRIBUTE_NAME))' (if `info' is not specified) or
|
||
`__attribute__((ATTRIBUTE_NAME(INFO)))' or
|
||
`__attribute__((ATTRIBUTE_NAME(INFO,...)))' in GNU C, where
|
||
`attribute_name' is recognized by the compiler middle-end or the
|
||
`TARGET_ATTRIBUTE_TABLE' machine specific macro. Note that a string
|
||
literal for the optional parameter `info' or the following ones is
|
||
transformed by default into an identifier, which may make this pragma
|
||
unusable for some attributes. For further information see `GNU
|
||
Compiler Collection (GCC) Internals'.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Main" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Main
|
||
(MAIN_OPTION [, MAIN_OPTION]);
|
||
|
||
MAIN_OPTION ::=
|
||
[Stack_Size =>] static_integer_EXPRESSION
|
||
| [Task_Stack_Size_Default =>] static_integer_EXPRESSION
|
||
| [Time_Slicing_Enabled =>] static_boolean_EXPRESSION
|
||
|
||
This pragma is provided for compatibility with OpenVMS VAX Systems. It
|
||
has no effect in GNAT, other than being syntax checked.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Main_Storage" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Main_Storage
|
||
(MAIN_STORAGE_OPTION [, MAIN_STORAGE_OPTION]);
|
||
|
||
MAIN_STORAGE_OPTION ::=
|
||
[WORKING_STORAGE =>] static_SIMPLE_EXPRESSION
|
||
| [TOP_GUARD =>] static_SIMPLE_EXPRESSION
|
||
|
||
This pragma is provided for compatibility with OpenVMS VAX Systems. It
|
||
has no effect in GNAT, other than being syntax checked.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Max_Queue_Length" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Max_Queue_Length (static_integer_EXPRESSION);
|
||
|
||
This pragma is used to specify the maximum callers per entry queue for
|
||
individual protected entries and entry families. It accepts a single
|
||
integer (-1 or more) as a parameter and must appear after the
|
||
declaration of an entry.
|
||
|
||
A value of -1 represents no additional restriction on queue length.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="No_Body" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma No_Body;
|
||
|
||
There are a number of cases in which a package spec does not require a
|
||
body, and in fact a body is not permitted. GNAT will not permit the
|
||
spec to be compiled if there is a body around. The pragma No_Body
|
||
allows you to provide a body file, even in a case where no body is
|
||
allowed. The body file must contain only comments and a single No_Body
|
||
pragma. This is recognized by the compiler as indicating that no body
|
||
is logically present.
|
||
|
||
This is particularly useful during maintenance when a package is
|
||
modified in such a way that a body needed before is no longer needed.
|
||
The provision of a dummy body with a No_Body pragma ensures that there
|
||
is no interference from earlier versions of the package body.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="No_Caching" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma No_Caching [ (static_boolean_EXPRESSION) ];
|
||
|
||
For the semantics of this pragma, see the entry for aspect `No_Caching'
|
||
in the SPARK 2014 Reference Manual, section 7.1.2.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="No_Component_Reordering" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma No_Component_Reordering [([Entity =>] type_LOCAL_NAME)];
|
||
|
||
`type_LOCAL_NAME' must refer to a record type declaration in the current
|
||
declarative part. The effect is to preclude any reordering of components
|
||
for the layout of the record, i.e. the record is laid out by the
|
||
compiler in the order in which the components are declared textually.
|
||
The form with no argument is a configuration pragma which applies to
|
||
all record types declared in units to which the pragma applies and
|
||
there is a requirement that this pragma be used consistently within a
|
||
partition.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="No_Elaboration_Code_All" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma No_Elaboration_Code_All [(program_unit_NAME)];
|
||
|
||
This is a program unit pragma (there is also an equivalent aspect of the
|
||
same name) that establishes the restriction `No_Elaboration_Code' for
|
||
the current unit and any extended main source units (body and subunits).
|
||
It also has the effect of enforcing a transitive application of this
|
||
aspect, so that if any unit is implicitly or explicitly with’ed by the
|
||
current unit, it must also have the `No_Elaboration_Code_All' aspect
|
||
set. It may be applied to package or subprogram specs or their generic
|
||
versions.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="No_Heap_Finalization" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma No_Heap_Finalization [ (first_subtype_LOCAL_NAME) ];
|
||
|
||
Pragma `No_Heap_Finalization' may be used as a configuration pragma or
|
||
as a type-specific pragma.
|
||
|
||
In its configuration form, the pragma must appear within a
|
||
configuration file such as gnat.adc, without an argument. The pragma
|
||
suppresses the call to `Finalize' for heap-allocated objects created
|
||
through library-level named access-to-object types in cases where the
|
||
designated type requires finalization actions.
|
||
|
||
In its type-specific form, the argument of the pragma must denote a
|
||
library-level named access-to-object type. The pragma suppresses the
|
||
call to `Finalize' for heap-allocated objects created through the
|
||
specific access type in cases where the designated type requires
|
||
finalization actions.
|
||
|
||
It is still possible to finalize such heap-allocated objects by
|
||
explicitly deallocating them.
|
||
|
||
A library-level named access-to-object type declared within a generic
|
||
unit will lose its `No_Heap_Finalization' pragma when the corresponding
|
||
instance does not appear at the library level.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="No_Inline" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma No_Inline (NAME {, NAME});
|
||
|
||
This pragma suppresses inlining for the callable entity or the
|
||
instances of the generic subprogram designated by `NAME', including
|
||
inlining that results from the use of pragma `Inline'. This pragma is
|
||
always active, in particular it is not subject to the use of option
|
||
`-gnatn' or `-gnatN'. It is illegal to specify both pragma `No_Inline'
|
||
and pragma `Inline_Always' for the same `NAME'.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="No_Raise" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma No_Raise (subprogram_LOCAL_NAME {, subprogram_LOCAL_NAME});
|
||
|
||
Each `subprogram_LOCAL_NAME' argument must refer to one or more
|
||
subprogram declarations in the current declarative part. A subprogram
|
||
to which this pragma is applied may not raise an exception that is not
|
||
caught within it. An implementation-defined check named `Raise_Check'
|
||
is associated with the pragma, and `Program_Error' is raised upon its
|
||
failure (see RM 11.5(19/5)).</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="No_Return" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma No_Return (procedure_LOCAL_NAME {, procedure_LOCAL_NAME});
|
||
|
||
Each `procedure_LOCAL_NAME' argument must refer to one or more procedure
|
||
declarations in the current declarative part. A procedure to which this
|
||
pragma is applied may not contain any explicit `return' statements. In
|
||
addition, if the procedure contains any implicit returns from falling
|
||
off the end of a statement sequence, then execution of that implicit
|
||
return will cause Program_Error to be raised.
|
||
|
||
One use of this pragma is to identify procedures whose only purpose is
|
||
to raise an exception. Another use of this pragma is to suppress
|
||
incorrect warnings about missing returns in functions, where the last
|
||
statement of a function statement sequence is a call to such a
|
||
procedure.
|
||
|
||
Note that in Ada 2005 mode, this pragma is part of the language. It is
|
||
available in all earlier versions of Ada as an implementation-defined
|
||
pragma.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="No_Strict_Aliasing" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma No_Strict_Aliasing [([Entity =>] type_LOCAL_NAME)];
|
||
|
||
`type_LOCAL_NAME' must refer to an access type declaration in the
|
||
current declarative part. The effect is to inhibit strict aliasing
|
||
optimization for the given type. The form with no arguments is a
|
||
configuration pragma which applies to all access types declared in
|
||
units to which the pragma applies. For a detailed description of the
|
||
strict aliasing optimization, and the situations in which it must be
|
||
suppressed, see the section on Optimization and Strict Aliasing in the
|
||
`GNAT User’s Guide'.
|
||
|
||
This pragma currently has no effects on access to unconstrained array
|
||
types.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="No_Tagged_Streams" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma No_Tagged_Streams [([Entity =>] tagged_type_LOCAL_NAME)];
|
||
|
||
Normally when a tagged type is introduced using a full type declaration,
|
||
part of the processing includes generating stream access routines to be
|
||
used by stream attributes referencing the type (or one of its subtypes
|
||
or derived types). This can involve the generation of significant
|
||
amounts of code which is wasted space if stream routines are not needed
|
||
for the type in question.
|
||
|
||
The `No_Tagged_Streams' pragma causes the generation of these stream
|
||
routines to be skipped, and any attempt to use stream operations on
|
||
types subject to this pragma will be statically rejected as illegal.
|
||
|
||
There are two forms of the pragma. The form with no arguments must
|
||
appear in a declarative sequence or in the declarations of a package
|
||
spec. This pragma affects all subsequent root tagged types declared in
|
||
the declaration sequence, and specifies that no stream routines be
|
||
generated. The form with an argument (for which there is also a
|
||
corresponding aspect) specifies a single root tagged type for which
|
||
stream routines are not to be generated.
|
||
|
||
Once the pragma has been given for a particular root tagged type, all
|
||
subtypes and derived types of this type inherit the pragma
|
||
automatically, so the effect applies to a complete hierarchy (this is
|
||
necessary to deal with the class-wide dispatching versions of the
|
||
stream routines).
|
||
|
||
When pragmas `Discard_Names' and `No_Tagged_Streams' are simultaneously
|
||
applied to a tagged type its Expanded_Name and External_Tag are
|
||
initialized with empty strings. This is useful to avoid exposing entity
|
||
names at binary level but has a negative impact on the debuggability of
|
||
tagged types.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Normalize_Scalars" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Normalize_Scalars;
|
||
|
||
This is a language defined pragma which is fully implemented in GNAT.
|
||
The effect is to cause all scalar objects that are not otherwise
|
||
initialized to be initialized. The initial values are implementation
|
||
dependent and are as follows:
|
||
|
||
`Standard.Character'
|
||
Objects whose root type is Standard.Character are initialized to
|
||
Character’Last unless the subtype range excludes NUL (in which
|
||
case NUL is used). This choice will always generate an invalid
|
||
value if one exists.
|
||
|
||
`Standard.Wide_Character'
|
||
Objects whose root type is Standard.Wide_Character are initialized
|
||
to Wide_Character’Last unless the subtype range excludes NUL (in
|
||
which case NUL is used). This choice will always generate an
|
||
invalid value if one exists.
|
||
|
||
`Standard.Wide_Wide_Character'
|
||
Objects whose root type is Standard.Wide_Wide_Character are
|
||
initialized to the invalid value 16#FFFF_FFFF# unless the subtype
|
||
range excludes NUL (in which case NUL is used). This choice will
|
||
always generate an invalid value if one exists.
|
||
|
||
`Integer types'
|
||
Objects of an integer type are treated differently depending on
|
||
whether negative values are present in the subtype. If no negative
|
||
values are present, then all one bits is used as the initial value
|
||
except in the special case where zero is excluded from the
|
||
subtype, in which case all zero bits are used. This choice will
|
||
always generate an invalid value if one exists.
|
||
|
||
For subtypes with negative values present, the largest negative
|
||
number is used, except in the unusual case where this largest
|
||
negative number is in the subtype, and the largest positive number
|
||
is not, in which case the largest positive value is used. This
|
||
choice will always generate an invalid value if one exists.
|
||
|
||
`Floating-Point Types'
|
||
Objects of all floating-point types are initialized to all 1-bits.
|
||
For standard IEEE format, this corresponds to a NaN (not a number)
|
||
which is indeed an invalid value.
|
||
|
||
`Fixed-Point Types'
|
||
Objects of all fixed-point types are treated as described above
|
||
for integers, with the rules applying to the underlying integer
|
||
value used to represent the fixed-point value.
|
||
|
||
`Modular types'
|
||
Objects of a modular type are initialized to all one bits, except
|
||
in the special case where zero is excluded from the subtype, in
|
||
which case all zero bits are used. This choice will always
|
||
generate an invalid value if one exists.
|
||
|
||
`Enumeration types'
|
||
Objects of an enumeration type are initialized to all one-bits,
|
||
i.e., to the value `2 ** typ'Size - 1' unless the subtype excludes
|
||
the literal whose Pos value is zero, in which case a code of zero
|
||
is used. This choice will always generate an invalid value if one
|
||
exists.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Obsolescent" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Obsolescent;
|
||
|
||
pragma Obsolescent (
|
||
[Message =>] static_string_EXPRESSION
|
||
[,[Version =>] Ada_05]);
|
||
|
||
pragma Obsolescent (
|
||
[Entity =>] NAME
|
||
[,[Message =>] static_string_EXPRESSION
|
||
[,[Version =>] Ada_05]]);
|
||
|
||
This pragma can occur immediately following a declaration of an entity,
|
||
including the case of a record component. If no Entity argument is
|
||
present, then this declaration is the one to which the pragma applies.
|
||
If an Entity parameter is present, it must either match the name of the
|
||
entity in this declaration, or alternatively, the pragma can
|
||
immediately follow an enumeration type declaration, where the Entity
|
||
argument names one of the enumeration literals.
|
||
|
||
This pragma is used to indicate that the named entity is considered
|
||
obsolescent and should not be used. Typically this is used when an API
|
||
must be modified by eventually removing or modifying existing
|
||
subprograms or other entities. The pragma can be used at an
|
||
intermediate stage when the entity is still present, but will be
|
||
removed later.
|
||
|
||
The effect of this pragma is to output a warning message on a reference
|
||
to an entity thus marked that the subprogram is obsolescent if the
|
||
appropriate warning option in the compiler is activated. If the
|
||
`Message' parameter is present, then a second warning message is given
|
||
containing this text. In addition, a reference to the entity is
|
||
considered to be a violation of pragma `Restrictions
|
||
(No_Obsolescent_Features)'.
|
||
|
||
This pragma can also be used as a program unit pragma for a package, in
|
||
which case the entity name is the name of the package, and the pragma
|
||
indicates that the entire package is considered obsolescent. In this
|
||
case a client `with'ing such a package violates the restriction, and
|
||
the `with' clause is flagged with warnings if the warning option is set.
|
||
|
||
If the `Version' parameter is present (which must be exactly the
|
||
identifier `Ada_05', no other argument is allowed), then the indication
|
||
of obsolescence applies only when compiling in Ada 2005 mode. This is
|
||
primarily intended for dealing with the situations in the predefined
|
||
library where subprograms or packages have become defined as
|
||
obsolescent in Ada 2005 (e.g., in `Ada.Characters.Handling'), but may
|
||
be used anywhere.
|
||
|
||
The following examples show typical uses of this pragma:
|
||
|
||
package p is
|
||
pragma Obsolescent (p, Message => "use pp instead of p");
|
||
end p;
|
||
|
||
package q is
|
||
procedure q2;
|
||
pragma Obsolescent ("use q2new instead");
|
||
|
||
type R is new integer;
|
||
pragma Obsolescent
|
||
(Entity => R,
|
||
Message => "use RR in Ada 2005",
|
||
Version => Ada_05);
|
||
|
||
type M is record
|
||
F1 : Integer;
|
||
F2 : Integer;
|
||
pragma Obsolescent;
|
||
F3 : Integer;
|
||
end record;
|
||
|
||
type E is (a, bc, 'd', quack);
|
||
pragma Obsolescent (Entity => bc)
|
||
pragma Obsolescent (Entity => 'd')
|
||
|
||
function "+"
|
||
(a, b : character) return character;
|
||
pragma Obsolescent (Entity => "+");
|
||
end;
|
||
|
||
Note that, as for all pragmas, if you use a pragma argument identifier,
|
||
then all subsequent parameters must also use a pragma argument
|
||
identifier. So if you specify `Entity =>' for the `Entity' argument,
|
||
and a `Message' argument is present, it must be preceded by `Message
|
||
=>'.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Optimize" origin="Ada RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Optimize (identifier);</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Optimize_Alignment" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Optimize_Alignment (TIME | SPACE | OFF);
|
||
|
||
This is a configuration pragma which affects the choice of default
|
||
alignments for types and objects where no alignment is explicitly
|
||
specified. There is a time/space trade-off in the selection of these
|
||
values. Large alignments result in more efficient code, at the expense
|
||
of larger data space, since sizes have to be increased to match these
|
||
alignments. Smaller alignments save space, but the access code is
|
||
slower. The normal choice of default alignments for types and
|
||
individual alignment promotions for objects (which is what you get if
|
||
you do not use this pragma, or if you use an argument of OFF), tries to
|
||
balance these two requirements.
|
||
|
||
Specifying SPACE causes smaller default alignments to be chosen in two
|
||
cases. First any packed record is given an alignment of 1. Second, if
|
||
a size is given for the type, then the alignment is chosen to avoid
|
||
increasing this size. For example, consider:
|
||
|
||
type R is record
|
||
X : Integer;
|
||
Y : Character;
|
||
end record;
|
||
|
||
for R'Size use 5*8;
|
||
|
||
In the default mode, this type gets an alignment of 4, so that access
|
||
to the Integer field X are efficient. But this means that objects of
|
||
the type end up with a size of 8 bytes. This is a valid choice, since
|
||
sizes of objects are allowed to be bigger than the size of the type,
|
||
but it can waste space if for example fields of type R appear in an
|
||
enclosing record. If the above type is compiled in `Optimize_Alignment
|
||
(Space)' mode, the alignment is set to 1.
|
||
|
||
However, there is one case in which SPACE is ignored. If a variable
|
||
length record (that is a discriminated record with a component which is
|
||
an array whose length depends on a discriminant), has a pragma Pack,
|
||
then it is not in general possible to set the alignment of such a
|
||
record to one, so the pragma is ignored in this case (with a warning).
|
||
|
||
Specifying SPACE also disables alignment promotions for standalone
|
||
objects, which occur when the compiler increases the alignment of a
|
||
specific object without changing the alignment of its type.
|
||
|
||
Specifying SPACE also disables component reordering in unpacked record
|
||
types, which can result in larger sizes in order to meet alignment
|
||
requirements.
|
||
|
||
Specifying TIME causes larger default alignments to be chosen in the
|
||
case of small types with sizes that are not a power of 2. For example,
|
||
consider:
|
||
|
||
type R is record
|
||
A : Character;
|
||
B : Character;
|
||
C : Boolean;
|
||
end record;
|
||
|
||
pragma Pack (R);
|
||
for R'Size use 17;
|
||
|
||
The default alignment for this record is normally 1, but if this type is
|
||
compiled in `Optimize_Alignment (Time)' mode, then the alignment is set
|
||
to 4, which wastes space for objects of the type, since they are now 4
|
||
bytes long, but results in more efficient access when the whole record
|
||
is referenced.
|
||
|
||
As noted above, this is a configuration pragma, and there is a
|
||
requirement that all units in a partition be compiled with a consistent
|
||
setting of the optimization setting. This would normally be achieved by
|
||
use of a configuration pragma file containing the appropriate setting.
|
||
The exception to this rule is that units with an explicit configuration
|
||
pragma in the same file as the source unit are excluded from the
|
||
consistency check, as are all predefined units. The latter are compiled
|
||
by default in pragma Optimize_Alignment (Off) mode if no pragma appears
|
||
at the start of the file.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Ordered" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Ordered (enumeration_first_subtype_LOCAL_NAME);
|
||
|
||
Most enumeration types are from a conceptual point of view unordered.
|
||
For example, consider:
|
||
|
||
type Color is (Red, Blue, Green, Yellow);
|
||
|
||
By Ada semantics `Blue > Red' and `Green > Blue', but really these
|
||
relations make no sense; the enumeration type merely specifies a set of
|
||
possible colors, and the order is unimportant.
|
||
|
||
For unordered enumeration types, it is generally a good idea if clients
|
||
avoid comparisons (other than equality or inequality) and explicit
|
||
ranges. (A `client' is a unit where the type is referenced, other than
|
||
the unit where the type is declared, its body, and its subunits.) For
|
||
example, if code buried in some client says:
|
||
|
||
if Current_Color < Yellow then ...
|
||
if Current_Color in Blue .. Green then ...
|
||
|
||
then the client code is relying on the order, which is undesirable. It
|
||
makes the code hard to read and creates maintenance difficulties if
|
||
entries have to be added to the enumeration type. Instead, the code in
|
||
the client should list the possibilities, or an appropriate subtype
|
||
should be declared in the unit that declares the original enumeration
|
||
type. E.g., the following subtype could be declared along with the type
|
||
`Color':
|
||
|
||
subtype RBG is Color range Red .. Green;
|
||
|
||
and then the client could write:
|
||
|
||
if Current_Color in RBG then ...
|
||
if Current_Color = Blue or Current_Color = Green then ...
|
||
|
||
However, some enumeration types are legitimately ordered from a
|
||
conceptual point of view. For example, if you declare:
|
||
|
||
type Day is (Mon, Tue, Wed, Thu, Fri, Sat, Sun);
|
||
|
||
then the ordering imposed by the language is reasonable, and clients
|
||
can depend on it, writing for example:
|
||
|
||
if D in Mon .. Fri then ...
|
||
if D < Wed then ...
|
||
|
||
The pragma `Ordered' is provided to mark enumeration types that are
|
||
conceptually ordered, alerting the reader that clients may depend on
|
||
the ordering. GNAT provides a pragma to mark enumerations as ordered
|
||
rather than one to mark them as unordered, since in our experience, the
|
||
great majority of enumeration types are conceptually unordered.
|
||
|
||
The types `Boolean', `Character', `Wide_Character', and
|
||
`Wide_Wide_Character' are considered to be ordered types, so each is
|
||
declared with a pragma `Ordered' in package `Standard'.
|
||
|
||
Normally pragma `Ordered' serves only as documentation and a guide for
|
||
coding standards, but GNAT provides a warning switch `-gnatw.u' that
|
||
requests warnings for inappropriate uses (comparisons and explicit
|
||
subranges) for unordered types. If this switch is used, then any
|
||
enumeration type not marked with pragma `Ordered' will be considered as
|
||
unordered, and will generate warnings for inappropriate uses.
|
||
|
||
Note that generic types are not considered ordered or unordered (since
|
||
the template can be instantiated for both cases), so we never generate
|
||
warnings for the case of generic enumerated types.
|
||
|
||
For additional information please refer to the description of the
|
||
`-gnatw.u' switch in the GNAT User’s Guide.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Overflow_Mode" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Overflow_Mode
|
||
( [General =>] MODE
|
||
[,[Assertions =>] MODE]);
|
||
|
||
MODE ::= STRICT | MINIMIZED | ELIMINATED
|
||
|
||
This pragma sets the current overflow mode to the given setting. For
|
||
details of the meaning of these modes, please refer to the ‘Overflow
|
||
Check Handling in GNAT’ appendix in the GNAT User’s Guide. If only
|
||
the `General' parameter is present, the given mode applies to all
|
||
expressions. If both parameters are present, the `General' mode applies
|
||
to expressions outside assertions, and the `Eliminated' mode applies to
|
||
expressions within assertions.
|
||
|
||
The case of the `MODE' parameter is ignored, so `MINIMIZED',
|
||
`Minimized' and `minimized' all have the same effect.
|
||
|
||
The `Overflow_Mode' pragma has the same scoping and placement rules as
|
||
pragma `Suppress', so it can occur either as a configuration pragma,
|
||
specifying a default for the whole program, or in a declarative scope,
|
||
where it applies to the remaining declarations and statements in that
|
||
scope.
|
||
|
||
The pragma `Suppress (Overflow_Check)' suppresses overflow checking,
|
||
but does not affect the overflow mode.
|
||
|
||
The pragma `Unsuppress (Overflow_Check)' unsuppresses (enables)
|
||
overflow checking, but does not affect the overflow mode.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Overriding_Renamings" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Overriding_Renamings;
|
||
|
||
This is a GNAT configuration pragma to simplify porting legacy code
|
||
accepted by the Rational Ada compiler. In the presence of this pragma,
|
||
a renaming declaration that renames an inherited operation declared in
|
||
the same scope is legal if selected notation is used as in:
|
||
|
||
pragma Overriding_Renamings;
|
||
|
||
package R is
|
||
function F (..);
|
||
|
||
function F (..) renames R.F;
|
||
end R;
|
||
|
||
even though RM 8.3 (15) stipulates that an overridden operation is not
|
||
visible within the declaration of the overriding operation.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Pack" origin="Ada RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Pack;</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Page" origin="Ada RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Page;</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Part_Of" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Part_Of (ABSTRACT_STATE);
|
||
|
||
ABSTRACT_STATE ::= NAME
|
||
|
||
For the semantics of this pragma, see the entry for aspect `Part_Of' in
|
||
the SPARK 2014 Reference Manual, section 7.2.6.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Partition_Elaboration_Policy" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Partition_Elaboration_Policy (POLICY_IDENTIFIER);
|
||
|
||
POLICY_IDENTIFIER ::= Concurrent | Sequential
|
||
|
||
This pragma is standard in Ada 2005, but is available in all earlier
|
||
versions of Ada as an implementation-defined pragma. See Ada 2012
|
||
Reference Manual for details.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Passive" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Passive [(Semaphore | No)];
|
||
|
||
Syntax checked, but otherwise ignored by GNAT. This is recognized for
|
||
compatibility with DEC Ada 83 implementations, where it is used within a
|
||
task definition to request that a task be made passive. If the argument
|
||
`Semaphore' is present, or the argument is omitted, then DEC Ada 83
|
||
treats the pragma as an assertion that the containing task is passive
|
||
and that optimization of context switch with this task is permitted and
|
||
desired. If the argument `No' is present, the task must not be
|
||
optimized. GNAT does not attempt to optimize any tasks in this manner
|
||
(since protected objects are available in place of passive tasks).
|
||
|
||
For more information on the subject of passive tasks, see the section
|
||
‘Passive Task Optimization’ in the GNAT Users Guide.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Persistent_BSS" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Persistent_BSS [(object_LOCAL_NAME)]
|
||
|
||
This pragma allows selected objects to be placed in the
|
||
`.persistent_bss' section. On some targets the linker and loader
|
||
provide for special treatment of this section, allowing a program to be
|
||
reloaded without affecting the contents of this data (hence the name
|
||
persistent).
|
||
|
||
There are two forms of usage. If an argument is given, it must be the
|
||
local name of a library-level object, with no explicit initialization
|
||
and whose type is potentially persistent. If no argument is given, then
|
||
the pragma is a configuration pragma, and applies to all library-level
|
||
objects with no explicit initialization of potentially persistent types.
|
||
|
||
A potentially persistent type is a scalar type, or an untagged,
|
||
non-discriminated record, all of whose components have no explicit
|
||
initialization and are themselves of a potentially persistent type, or
|
||
an array, all of whose constraints are static, and whose component type
|
||
is potentially persistent.
|
||
|
||
If this pragma is used on a target where this feature is not supported,
|
||
then the pragma will be ignored. See also `pragma Linker_Section'.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Post" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Post (Boolean_Expression);
|
||
|
||
The `Post' pragma is intended to be an exact replacement for the
|
||
language-defined `Post' aspect, and shares its restrictions and
|
||
semantics. It must appear either immediately following the
|
||
corresponding subprogram declaration (only other pragmas may
|
||
intervene), or if there is no separate subprogram declaration, then it
|
||
can appear at the start of the declarations in a subprogram body
|
||
(preceded only by other pragmas).</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Post_Class" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Post_Class (Boolean_Expression);
|
||
|
||
The `Post_Class' pragma is intended to be an exact replacement for the
|
||
language-defined `Post'Class' aspect, and shares its restrictions and
|
||
semantics. It must appear either immediately following the
|
||
corresponding subprogram declaration (only other pragmas may
|
||
intervene), or if there is no separate subprogram declaration, then it
|
||
can appear at the start of the declarations in a subprogram body
|
||
(preceded only by other pragmas).
|
||
|
||
Note: This pragma is called `Post_Class' rather than `Post'Class'
|
||
because the latter would not be strictly conforming to the allowed
|
||
syntax for pragmas. The motivation for providing pragmas equivalent to
|
||
the aspects is to allow a program to be written using the pragmas, and
|
||
then compiled if necessary using an Ada compiler that does not
|
||
recognize the pragmas or aspects, but is prepared to ignore the
|
||
pragmas. The assertion policy that controls this pragma is
|
||
`Post'Class', not `Post_Class'.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Postcondition" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Postcondition (
|
||
[Check =>] Boolean_Expression
|
||
[,[Message =>] String_Expression]);
|
||
|
||
The `Postcondition' pragma allows specification of automatic
|
||
postcondition checks for subprograms. These checks are similar to
|
||
assertions, but are automatically inserted just prior to the return
|
||
statements of the subprogram with which they are associated (including
|
||
implicit returns at the end of procedure bodies and associated
|
||
exception handlers).
|
||
|
||
In addition, the boolean expression which is the condition which must
|
||
be true may contain references to function’Result in the case of a
|
||
function to refer to the returned value.
|
||
|
||
`Postcondition' pragmas may appear either immediately following the
|
||
(separate) declaration of a subprogram, or at the start of the
|
||
declarations of a subprogram body. Only other pragmas may intervene
|
||
(that is appear between the subprogram declaration and its
|
||
postconditions, or appear before the postcondition in the declaration
|
||
sequence in a subprogram body). In the case of a postcondition
|
||
appearing after a subprogram declaration, the formal arguments of the
|
||
subprogram are visible, and can be referenced in the postcondition
|
||
expressions.
|
||
|
||
The postconditions are collected and automatically tested just before
|
||
any return (implicit or explicit) in the subprogram body. A
|
||
postcondition is only recognized if postconditions are active at the
|
||
time the pragma is encountered. The compiler switch `gnata' turns on
|
||
all postconditions by default, and pragma `Check_Policy' with an
|
||
identifier of `Postcondition' can also be used to control whether
|
||
postconditions are active.
|
||
|
||
The general approach is that postconditions are placed in the spec if
|
||
they represent functional aspects which make sense to the client. For
|
||
example we might have:
|
||
|
||
function Direction return Integer;
|
||
pragma Postcondition
|
||
(Direction'Result = +1
|
||
or else
|
||
Direction'Result = -1);
|
||
|
||
which serves to document that the result must be +1 or -1, and will
|
||
test that this is the case at run time if postcondition checking is
|
||
active.
|
||
|
||
Postconditions within the subprogram body can be used to check that
|
||
some internal aspect of the implementation, not visible to the client,
|
||
is operating as expected. For instance if a square root routine keeps
|
||
an internal counter of the number of times it is called, then we might
|
||
have the following postcondition:
|
||
|
||
Sqrt_Calls : Natural := 0;
|
||
|
||
function Sqrt (Arg : Float) return Float is
|
||
pragma Postcondition
|
||
(Sqrt_Calls = Sqrt_Calls'Old + 1);
|
||
|
||
end Sqrt
|
||
|
||
As this example, shows, the use of the `Old' attribute is often useful
|
||
in postconditions to refer to the state on entry to the subprogram.
|
||
|
||
Note that postconditions are only checked on normal returns from the
|
||
subprogram. If an abnormal return results from raising an exception,
|
||
then the postconditions are not checked.
|
||
|
||
If a postcondition fails, then the exception
|
||
`System.Assertions.Assert_Failure' is raised. If a message argument was
|
||
supplied, then the given string will be used as the exception message.
|
||
If no message argument was supplied, then the default message has the
|
||
form “Postcondition failed at file_name:line”. The exception is
|
||
raised in the context of the subprogram body, so it is possible to
|
||
catch postcondition failures within the subprogram body itself.
|
||
|
||
Within a package spec, normal visibility rules in Ada would prevent
|
||
forward references within a postcondition pragma to functions defined
|
||
later in the same package. This would introduce undesirable ordering
|
||
constraints. To avoid this problem, all postcondition pragmas are
|
||
analyzed at the end of the package spec, allowing forward references.
|
||
|
||
The following example shows that this even allows mutually recursive
|
||
postconditions as in:
|
||
|
||
package Parity_Functions is
|
||
function Odd (X : Natural) return Boolean;
|
||
pragma Postcondition
|
||
(Odd'Result =
|
||
(x = 1
|
||
or else
|
||
(x /= 0 and then Even (X - 1))));
|
||
|
||
function Even (X : Natural) return Boolean;
|
||
pragma Postcondition
|
||
(Even'Result =
|
||
(x = 0
|
||
or else
|
||
(x /= 1 and then Odd (X - 1))));
|
||
|
||
end Parity_Functions;
|
||
|
||
There are no restrictions on the complexity or form of conditions used
|
||
within `Postcondition' pragmas. The following example shows that it is
|
||
even possible to verify performance behavior.
|
||
|
||
package Sort is
|
||
|
||
Performance : constant Float;
|
||
-- Performance constant set by implementation
|
||
-- to match target architecture behavior.
|
||
|
||
procedure Treesort (Arg : String);
|
||
-- Sorts characters of argument using N*logN sort
|
||
pragma Postcondition
|
||
(Float (Clock - Clock'Old) <=
|
||
Float (Arg'Length) *
|
||
log (Float (Arg'Length)) *
|
||
Performance);
|
||
end Sort;
|
||
|
||
Note: postcondition pragmas associated with subprograms that are marked
|
||
as Inline_Always, or those marked as Inline with front-end inlining
|
||
(-gnatN option set) are accepted and legality-checked by the compiler,
|
||
but are ignored at run-time even if postcondition checking is enabled.
|
||
|
||
Note that pragma `Postcondition' differs from the language-defined
|
||
`Post' aspect (and corresponding `Post' pragma) in allowing multiple
|
||
occurrences, allowing occurences in the body even if there is a
|
||
separate spec, and allowing a second string parameter, and the use of
|
||
the pragma identifier `Check'. Historically, pragma `Postcondition' was
|
||
implemented prior to the development of Ada 2012, and has been retained
|
||
in its original form for compatibility purposes.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Pre" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Pre (Boolean_Expression);
|
||
|
||
The `Pre' pragma is intended to be an exact replacement for the
|
||
language-defined `Pre' aspect, and shares its restrictions and
|
||
semantics. It must appear either immediately following the
|
||
corresponding subprogram declaration (only other pragmas may
|
||
intervene), or if there is no separate subprogram declaration, then it
|
||
can appear at the start of the declarations in a subprogram body
|
||
(preceded only by other pragmas).</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Pre_Class" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Pre_Class (Boolean_Expression);
|
||
|
||
The `Pre_Class' pragma is intended to be an exact replacement for the
|
||
language-defined `Pre'Class' aspect, and shares its restrictions and
|
||
semantics. It must appear either immediately following the
|
||
corresponding subprogram declaration (only other pragmas may
|
||
intervene), or if there is no separate subprogram declaration, then it
|
||
can appear at the start of the declarations in a subprogram body
|
||
(preceded only by other pragmas).
|
||
|
||
Note: This pragma is called `Pre_Class' rather than `Pre'Class' because
|
||
the latter would not be strictly conforming to the allowed syntax for
|
||
pragmas. The motivation for providing pragmas equivalent to the aspects
|
||
is to allow a program to be written using the pragmas, and then
|
||
compiled if necessary using an Ada compiler that does not recognize the
|
||
pragmas or aspects, but is prepared to ignore the pragmas. The assertion
|
||
policy that controls this pragma is `Pre'Class', not `Pre_Class'.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Precondition" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Precondition (
|
||
[Check =>] Boolean_Expression
|
||
[,[Message =>] String_Expression]);
|
||
|
||
The `Precondition' pragma is similar to `Postcondition' except that the
|
||
corresponding checks take place immediately upon entry to the
|
||
subprogram, and if a precondition fails, the exception is raised in the
|
||
context of the caller, and the attribute ‘Result cannot be used
|
||
within the precondition expression.
|
||
|
||
Otherwise, the placement and visibility rules are identical to those
|
||
described for postconditions. The following is an example of use within
|
||
a package spec:
|
||
|
||
package Math_Functions is
|
||
|
||
function Sqrt (Arg : Float) return Float;
|
||
pragma Precondition (Arg >= 0.0)
|
||
|
||
end Math_Functions;
|
||
|
||
`Precondition' pragmas may appear either immediately following the
|
||
(separate) declaration of a subprogram, or at the start of the
|
||
declarations of a subprogram body. Only other pragmas may intervene
|
||
(that is appear between the subprogram declaration and its
|
||
postconditions, or appear before the postcondition in the declaration
|
||
sequence in a subprogram body).
|
||
|
||
Note: precondition pragmas associated with subprograms that are marked
|
||
as Inline_Always, or those marked as Inline with front-end inlining
|
||
(-gnatN option set) are accepted and legality-checked by the compiler,
|
||
but are ignored at run-time even if precondition checking is enabled.
|
||
|
||
Note that pragma `Precondition' differs from the language-defined `Pre'
|
||
aspect (and corresponding `Pre' pragma) in allowing multiple
|
||
occurrences, allowing occurences in the body even if there is a
|
||
separate spec, and allowing a second string parameter, and the use of
|
||
the pragma identifier `Check'. Historically, pragma `Precondition' was
|
||
implemented prior to the development of Ada 2012, and has been retained
|
||
in its original form for compatibility purposes.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Predicate" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Predicate
|
||
([Entity =>] type_LOCAL_NAME,
|
||
[Check =>] EXPRESSION);
|
||
|
||
This pragma (available in all versions of Ada in GNAT) encompasses both
|
||
the `Static_Predicate' and `Dynamic_Predicate' aspects in Ada 2012. A
|
||
predicate is regarded as static if it has an allowed form for
|
||
`Static_Predicate' and is otherwise treated as a `Dynamic_Predicate'.
|
||
Otherwise, predicates specified by this pragma behave exactly as
|
||
described in the Ada 2012 reference manual. For example, if we have
|
||
|
||
type R is range 1 .. 10;
|
||
subtype S is R;
|
||
pragma Predicate (Entity => S, Check => S not in 4 .. 6);
|
||
subtype Q is R
|
||
pragma Predicate (Entity => Q, Check => F(Q) or G(Q));
|
||
|
||
the effect is identical to the following Ada 2012 code:
|
||
|
||
type R is range 1 .. 10;
|
||
subtype S is R with
|
||
Static_Predicate => S not in 4 .. 6;
|
||
subtype Q is R with
|
||
Dynamic_Predicate => F(Q) or G(Q);
|
||
|
||
Note that there are no pragmas `Dynamic_Predicate' or
|
||
`Static_Predicate'. That is because these pragmas would affect legality
|
||
and semantics of the program and thus do not have a neutral effect if
|
||
ignored. The motivation behind providing pragmas equivalent to
|
||
corresponding aspects is to allow a program to be written using the
|
||
pragmas, and then compiled with a compiler that will ignore the
|
||
pragmas. That doesn’t work in the case of static and dynamic
|
||
predicates, since if the corresponding pragmas are ignored, then the
|
||
behavior of the program is fundamentally changed (for example a
|
||
membership test `A in B' would not take into account a predicate
|
||
defined for subtype B). When following this approach, the use of
|
||
predicates should be avoided.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Predicate_Failure" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Predicate_Failure
|
||
([Entity =>] type_LOCAL_NAME,
|
||
[Message =>] String_Expression);
|
||
|
||
The `Predicate_Failure' pragma is intended to be an exact replacement
|
||
for the language-defined `Predicate_Failure' aspect, and shares its
|
||
restrictions and semantics.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Preelaborable_Initialization" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Preelaborable_Initialization (DIRECT_NAME);
|
||
|
||
This pragma is standard in Ada 2005, but is available in all earlier
|
||
versions of Ada as an implementation-defined pragma. See Ada 2012
|
||
Reference Manual for details.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Preelaborate" origin="Ada RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Preelaborate [(library_unit_name)];</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Prefix_Exception_Messages" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Prefix_Exception_Messages;
|
||
|
||
This is an implementation-defined configuration pragma that affects the
|
||
behavior of raise statements with a message given as a static string
|
||
constant (typically a string literal). In such cases, the string will
|
||
be automatically prefixed by the name of the enclosing entity (giving
|
||
the package and subprogram containing the raise statement). This helps
|
||
to identify where messages are coming from, and this mode is automatic
|
||
for the run-time library.
|
||
|
||
The pragma has no effect if the message is computed with an expression
|
||
other than a static string constant, since the assumption in this case
|
||
is that the program computes exactly the string it wants. If you still
|
||
want the prefixing in this case, you can always call
|
||
`GNAT.Source_Info.Enclosing_Entity' and prepend the string manually.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Priority" origin="Ada RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Priority;</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Priority_Specific_Dispatching" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Priority_Specific_Dispatching (
|
||
POLICY_IDENTIFIER,
|
||
first_priority_EXPRESSION,
|
||
last_priority_EXPRESSION)
|
||
|
||
POLICY_IDENTIFIER ::=
|
||
EDF_Across_Priorities |
|
||
FIFO_Within_Priorities |
|
||
Non_Preemptive_Within_Priorities |
|
||
Round_Robin_Within_Priorities
|
||
|
||
This pragma is standard in Ada 2005, but is available in all earlier
|
||
versions of Ada as an implementation-defined pragma. See Ada 2012
|
||
Reference Manual for details.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Profile" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Profile (Ravenscar | Restricted | Rational | Jorvik |
|
||
GNAT_Extended_Ravenscar | GNAT_Ravenscar_EDF );
|
||
|
||
This pragma is standard in Ada 2005, but is available in all earlier
|
||
versions of Ada as an implementation-defined pragma. This is a
|
||
configuration pragma that establishes a set of configuration pragmas
|
||
that depend on the argument. `Ravenscar' is standard in Ada 2005.
|
||
`Jorvik' is standard in Ada 202x. The other possibilities
|
||
(`Restricted', `Rational', `GNAT_Extended_Ravenscar',
|
||
`GNAT_Ravenscar_EDF') are implementation-defined.
|
||
`GNAT_Extended_Ravenscar' is an alias for `Jorvik'.
|
||
|
||
The set of configuration pragmas is defined in the following sections.
|
||
|
||
* Pragma Profile (Ravenscar)
|
||
|
||
The `Ravenscar' profile is standard in Ada 2005, but is available
|
||
in all earlier versions of Ada as an implementation-defined
|
||
pragma. This profile establishes the following set of
|
||
configuration pragmas:
|
||
|
||
* `Task_Dispatching_Policy (FIFO_Within_Priorities)'
|
||
|
||
[RM D.2.2] Tasks are dispatched following a preemptive
|
||
priority-ordered scheduling policy.
|
||
|
||
* `Locking_Policy (Ceiling_Locking)'
|
||
|
||
[RM D.3] While tasks and interrupts execute a protected
|
||
action, they inherit the ceiling priority of the
|
||
corresponding protected object.
|
||
|
||
* `Detect_Blocking'
|
||
|
||
This pragma forces the detection of potentially blocking
|
||
operations within a protected operation, and to raise
|
||
Program_Error if that happens.
|
||
|
||
plus the following set of restrictions:
|
||
|
||
* `Max_Entry_Queue_Length => 1'
|
||
|
||
No task can be queued on a protected entry.
|
||
|
||
* `Max_Protected_Entries => 1'
|
||
|
||
* `Max_Task_Entries => 0'
|
||
|
||
No rendezvous statements are allowed.
|
||
|
||
* `No_Abort_Statements'
|
||
|
||
* `No_Dynamic_Attachment'
|
||
|
||
* `No_Dynamic_Priorities'
|
||
|
||
* `No_Implicit_Heap_Allocations'
|
||
|
||
* `No_Local_Protected_Objects'
|
||
|
||
* `No_Local_Timing_Events'
|
||
|
||
* `No_Protected_Type_Allocators'
|
||
|
||
* `No_Relative_Delay'
|
||
|
||
* `No_Requeue_Statements'
|
||
|
||
* `No_Select_Statements'
|
||
|
||
* `No_Specific_Termination_Handlers'
|
||
|
||
* `No_Task_Allocators'
|
||
|
||
* `No_Task_Hierarchy'
|
||
|
||
* `No_Task_Termination'
|
||
|
||
* `Simple_Barriers'
|
||
|
||
The Ravenscar profile also includes the following restrictions
|
||
that specify that there are no semantic dependencies on the
|
||
corresponding predefined packages:
|
||
|
||
* `No_Dependence => Ada.Asynchronous_Task_Control'
|
||
|
||
* `No_Dependence => Ada.Calendar'
|
||
|
||
* `No_Dependence => Ada.Execution_Time.Group_Budget'
|
||
|
||
* `No_Dependence => Ada.Execution_Time.Timers'
|
||
|
||
* `No_Dependence => Ada.Task_Attributes'
|
||
|
||
* `No_Dependence => System.Multiprocessors.Dispatching_Domains'
|
||
|
||
This set of configuration pragmas and restrictions correspond to
|
||
the definition of the ‘Ravenscar Profile’ for limited tasking,
|
||
devised and published by the `International Real-Time Ada
|
||
Workshop, 1997'. A description is also available at
|
||
<http://www-users.cs.york.ac.uk/~burns/ravenscar.ps>.
|
||
|
||
The original definition of the profile was revised at subsequent
|
||
IRTAW meetings. It has been included in the ISO `Guide for the Use
|
||
of the Ada Programming Language in High Integrity Systems', and
|
||
was made part of the Ada 2005 standard. The formal definition
|
||
given by the Ada Rapporteur Group (ARG) can be found in two Ada
|
||
Issues (AI-249 and AI-305) available at
|
||
<http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ais/ai-00249.txt> and
|
||
<http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ais/ai-00305.txt>.
|
||
|
||
The above set is a superset of the restrictions provided by pragma
|
||
`Profile (Restricted)', it includes six additional restrictions
|
||
(`Simple_Barriers', `No_Select_Statements', `No_Calendar',
|
||
`No_Implicit_Heap_Allocations', `No_Relative_Delay' and
|
||
`No_Task_Termination'). This means that pragma `Profile
|
||
(Ravenscar)', like the pragma `Profile (Restricted)',
|
||
automatically causes the use of a simplified, more efficient
|
||
version of the tasking run-time library.
|
||
|
||
* Pragma Profile (Jorvik)
|
||
|
||
`Jorvik' is the new profile added to the Ada 202x draft standard,
|
||
previously implemented under the name `GNAT_Extended_Ravenscar'.
|
||
|
||
The `No_Implicit_Heap_Allocations' restriction has been replaced
|
||
by `No_Implicit_Task_Allocations' and
|
||
`No_Implicit_Protected_Object_Allocations'.
|
||
|
||
The `Simple_Barriers' restriction has been replaced by
|
||
`Pure_Barriers'.
|
||
|
||
The `Max_Protected_Entries', `Max_Entry_Queue_Length', and
|
||
`No_Relative_Delay' restrictions have been removed.
|
||
|
||
Details on the rationale for `Jorvik' and implications for use may
|
||
be found in `A New Ravenscar-Based Profile' by P. Rogers, J. Ruiz,
|
||
T. Gingold and P. Bernardi, in `Reliable Software Technologies –
|
||
Ada Europe 2017', Springer-Verlag Lecture Notes in Computer
|
||
Science, Number 10300.
|
||
|
||
* Pragma Profile (GNAT_Ravenscar_EDF)
|
||
|
||
This profile corresponds to the Ravenscar profile but using
|
||
EDF_Across_Priority as the Task_Scheduling_Policy.
|
||
|
||
* Pragma Profile (Restricted)
|
||
|
||
This profile corresponds to the GNAT restricted run time. It
|
||
establishes the following set of restrictions:
|
||
|
||
* `No_Abort_Statements'
|
||
|
||
* `No_Entry_Queue'
|
||
|
||
* `No_Task_Hierarchy'
|
||
|
||
* `No_Task_Allocators'
|
||
|
||
* `No_Dynamic_Priorities'
|
||
|
||
* `No_Terminate_Alternatives'
|
||
|
||
* `No_Dynamic_Attachment'
|
||
|
||
* `No_Protected_Type_Allocators'
|
||
|
||
* `No_Local_Protected_Objects'
|
||
|
||
* `No_Requeue_Statements'
|
||
|
||
* `No_Task_Attributes_Package'
|
||
|
||
* `Max_Asynchronous_Select_Nesting = 0'
|
||
|
||
* `Max_Task_Entries = 0'
|
||
|
||
* `Max_Protected_Entries = 1'
|
||
|
||
* `Max_Select_Alternatives = 0'
|
||
|
||
This set of restrictions causes the automatic selection of a
|
||
simplified version of the run time that provides improved
|
||
performance for the limited set of tasking functionality permitted
|
||
by this set of restrictions.
|
||
|
||
* Pragma Profile (Rational)
|
||
|
||
The Rational profile is intended to facilitate porting legacy code
|
||
that compiles with the Rational APEX compiler, even when the code
|
||
includes non- conforming Ada constructs. The profile enables the
|
||
following three pragmas:
|
||
|
||
* `pragma Implicit_Packing'
|
||
|
||
* `pragma Overriding_Renamings'
|
||
|
||
* `pragma Use_VADS_Size'</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Profile_Warnings" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Profile_Warnings (Ravenscar | Restricted | Rational);
|
||
|
||
This is an implementation-defined pragma that is similar in effect to
|
||
`pragma Profile' except that instead of generating `Restrictions'
|
||
pragmas, it generates `Restriction_Warnings' pragmas. The result is that
|
||
violations of the profile generate warning messages instead of error
|
||
messages.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Program_Exit" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Program_Exit [ (boolean_EXPRESSION) ];
|
||
|
||
For the semantics of this pragma, see the entry for aspect
|
||
`Program_Exit' in the SPARK 2014 Reference Manual, section 6.1.10.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Propagate_Exceptions" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Propagate_Exceptions;
|
||
|
||
This pragma is now obsolete and, other than generating a warning if
|
||
warnings on obsolescent features are enabled, is ignored. It is
|
||
retained for compatibility purposes. It used to be used in connection
|
||
with optimization of a now-obsolete mechanism for implementation of
|
||
exceptions.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Provide_Shift_Operators" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Provide_Shift_Operators (integer_first_subtype_LOCAL_NAME);
|
||
|
||
This pragma can be applied to a first subtype local name that specifies
|
||
either an unsigned or signed type. It has the effect of providing the
|
||
five shift operators (Shift_Left, Shift_Right, Shift_Right_Arithmetic,
|
||
Rotate_Left and Rotate_Right) for the given type. It is similar to
|
||
including the function declarations for these five operators, together
|
||
with the pragma Import (Intrinsic, …) statements.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Psect_Object" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Psect_Object (
|
||
[Internal =>] LOCAL_NAME,
|
||
[, [External =>] EXTERNAL_SYMBOL]
|
||
[, [Size =>] EXTERNAL_SYMBOL]);
|
||
|
||
EXTERNAL_SYMBOL ::=
|
||
IDENTIFIER
|
||
| static_string_EXPRESSION
|
||
|
||
This pragma is identical in effect to pragma `Common_Object'.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Pure" origin="Ada RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Pure [(library_unit_name)];</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Pure_Function" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Pure_Function ([Entity =>] function_LOCAL_NAME);
|
||
|
||
This pragma appears in the same declarative part as a function
|
||
declaration (or a set of function declarations if more than one
|
||
overloaded declaration exists, in which case the pragma applies to all
|
||
entities). It specifies that the function `Entity' is to be considered
|
||
pure for the purposes of code generation. This means that the compiler
|
||
can assume that there are no side effects, and in particular that two
|
||
identical calls produce the same result in the same context. It also
|
||
means that the function can be used in an address clause.
|
||
|
||
Note that, quite deliberately, there are no static checks to try to
|
||
ensure that this promise is met, so `Pure_Function' can be used with
|
||
functions that are conceptually pure, even if they do modify global
|
||
variables. For example, a square root function that is instrumented to
|
||
count the number of times it is called is still conceptually pure, and
|
||
can still be optimized, even though it modifies a global variable (the
|
||
count). Memo functions are another example (where a table of previous
|
||
calls is kept and consulted to avoid re-computation).
|
||
|
||
Note also that the normal rules excluding optimization of subprograms
|
||
in pure units (when parameter types are descended from System.Address,
|
||
or when the full view of a parameter type is limited), do not apply for
|
||
the Pure_Function case. If you explicitly specify Pure_Function, the
|
||
compiler may optimize away calls with identical arguments, and if that
|
||
results in unexpected behavior, the proper action is not to use the
|
||
pragma for subprograms that are not (conceptually) pure.
|
||
|
||
Note: Most functions in a `Pure' package are automatically pure, and
|
||
there is no need to use pragma `Pure_Function' for such functions. One
|
||
exception is any function that has at least one formal of type
|
||
`System.Address' or a type derived from it. Such functions are not
|
||
considered pure by default, since the compiler assumes that the
|
||
`Address' parameter may be functioning as a pointer and that the
|
||
referenced data may change even if the address value does not.
|
||
Similarly, imported functions are not considered to be pure by default,
|
||
since there is no way of checking that they are in fact pure. The use
|
||
of pragma `Pure_Function' for such a function will override these
|
||
default assumption, and cause the compiler to treat a designated
|
||
subprogram as pure in these cases.
|
||
|
||
Note: If pragma `Pure_Function' is applied to a renamed function, it
|
||
applies to the underlying renamed function. This can be used to
|
||
disambiguate cases of overloading where some but not all functions in a
|
||
set of overloaded functions are to be designated as pure.
|
||
|
||
If pragma `Pure_Function' is applied to a library-level function, the
|
||
function is also considered pure from an optimization point of view,
|
||
but the unit is not a Pure unit in the categorization sense. So for
|
||
example, a function thus marked is free to `with' non-pure units.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Queuing_Policy" origin="Ada RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Queuing_Policy (policy_identifier);</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Rational" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Rational;
|
||
|
||
This pragma is considered obsolescent, but is retained for
|
||
compatibility purposes. It is equivalent to:
|
||
|
||
pragma Profile (Rational);</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Ravenscar" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Ravenscar;
|
||
|
||
This pragma is considered obsolescent, but is retained for
|
||
compatibility purposes. It is equivalent to:
|
||
|
||
pragma Profile (Ravenscar);
|
||
|
||
which is the preferred method of setting the `Ravenscar' profile.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Refined_Depends" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Refined_Depends (DEPENDENCY_RELATION);
|
||
|
||
DEPENDENCY_RELATION ::=
|
||
null
|
||
| (DEPENDENCY_CLAUSE {, DEPENDENCY_CLAUSE})
|
||
|
||
DEPENDENCY_CLAUSE ::=
|
||
OUTPUT_LIST =>[+] INPUT_LIST
|
||
| NULL_DEPENDENCY_CLAUSE
|
||
|
||
NULL_DEPENDENCY_CLAUSE ::= null => INPUT_LIST
|
||
|
||
OUTPUT_LIST ::= OUTPUT | (OUTPUT {, OUTPUT})
|
||
|
||
INPUT_LIST ::= null | INPUT | (INPUT {, INPUT})
|
||
|
||
OUTPUT ::= NAME | FUNCTION_RESULT
|
||
INPUT ::= NAME
|
||
|
||
where FUNCTION_RESULT is a function Result attribute_reference
|
||
|
||
For the semantics of this pragma, see the entry for aspect
|
||
`Refined_Depends' in the SPARK 2014 Reference Manual, section 6.1.5.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Refined_Global" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Refined_Global (GLOBAL_SPECIFICATION);
|
||
|
||
GLOBAL_SPECIFICATION ::=
|
||
null
|
||
| (GLOBAL_LIST)
|
||
| (MODED_GLOBAL_LIST {, MODED_GLOBAL_LIST})
|
||
|
||
MODED_GLOBAL_LIST ::= MODE_SELECTOR => GLOBAL_LIST
|
||
|
||
MODE_SELECTOR ::= In_Out | Input | Output | Proof_In
|
||
GLOBAL_LIST ::= GLOBAL_ITEM | (GLOBAL_ITEM {, GLOBAL_ITEM})
|
||
GLOBAL_ITEM ::= NAME
|
||
|
||
For the semantics of this pragma, see the entry for aspect
|
||
`Refined_Global' in the SPARK 2014 Reference Manual, section 6.1.4.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Refined_Post" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Refined_Post (boolean_EXPRESSION);
|
||
|
||
For the semantics of this pragma, see the entry for aspect
|
||
`Refined_Post' in the SPARK 2014 Reference Manual, section 7.2.7.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Refined_State" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Refined_State (REFINEMENT_LIST);
|
||
|
||
REFINEMENT_LIST ::=
|
||
(REFINEMENT_CLAUSE {, REFINEMENT_CLAUSE})
|
||
|
||
REFINEMENT_CLAUSE ::= state_NAME => CONSTITUENT_LIST
|
||
|
||
CONSTITUENT_LIST ::=
|
||
null
|
||
| CONSTITUENT
|
||
| (CONSTITUENT {, CONSTITUENT})
|
||
|
||
CONSTITUENT ::= object_NAME | state_NAME
|
||
|
||
For the semantics of this pragma, see the entry for aspect
|
||
`Refined_State' in the SPARK 2014 Reference Manual, section 7.2.2.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Relative_Deadline" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Relative_Deadline (time_span_EXPRESSION);
|
||
|
||
This pragma is standard in Ada 2005, but is available in all earlier
|
||
versions of Ada as an implementation-defined pragma. See Ada 2012
|
||
Reference Manual for details.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Remote_Access_Type" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Remote_Access_Type ([Entity =>] formal_access_type_LOCAL_NAME);
|
||
|
||
This pragma appears in the formal part of a generic declaration. It
|
||
specifies an exception to the RM rule from E.2.2(17/2), which forbids
|
||
the use of a remote access to class-wide type as actual for a formal
|
||
access type.
|
||
|
||
When this pragma applies to a formal access type `Entity', that type is
|
||
treated as a remote access to class-wide type in the generic. It must
|
||
be a formal general access type, and its designated type must be the
|
||
class-wide type of a formal tagged limited private type from the same
|
||
generic declaration.
|
||
|
||
In the generic unit, the formal type is subject to all restrictions
|
||
pertaining to remote access to class-wide types. At instantiation, the
|
||
actual type must be a remote access to class-wide type.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Remote_Call_Interface" origin="Ada RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Remote_Call_Interface [(library_unit_name)];</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Remote_Types" origin="Ada RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Remote_Types [(library_unit_name)];</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Rename_Pragma" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Rename_Pragma (
|
||
[New_Name =>] IDENTIFIER,
|
||
[Renamed =>] pragma_IDENTIFIER);
|
||
|
||
This pragma provides a mechanism for supplying new names for existing
|
||
pragmas. The `New_Name' identifier can subsequently be used as a
|
||
synonym for the Renamed pragma. For example, suppose you have code that
|
||
was originally developed on a compiler that supports Inline_Only as an
|
||
implementation defined pragma. And suppose the semantics of pragma
|
||
Inline_Only are identical to (or at least very similar to) the GNAT
|
||
implementation defined pragma Inline_Always. You could globally replace
|
||
Inline_Only with Inline_Always.
|
||
|
||
However, to avoid that source modification, you could instead add a
|
||
configuration pragma:
|
||
|
||
pragma Rename_Pragma (
|
||
New_Name => Inline_Only,
|
||
Renamed => Inline_Always);
|
||
|
||
Then GNAT will treat “pragma Inline_Only …” as if you had written
|
||
“pragma Inline_Always …”.
|
||
|
||
Pragma Inline_Only will not necessarily mean the same thing as the
|
||
other Ada compiler; it’s up to you to make sure the semantics are
|
||
close enough.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Restricted_Run_Time" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Restricted_Run_Time;
|
||
|
||
This pragma is considered obsolescent, but is retained for
|
||
compatibility purposes. It is equivalent to:
|
||
|
||
pragma Profile (Restricted);
|
||
|
||
which is the preferred method of setting the restricted run time
|
||
profile.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Restriction_Warnings" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Restriction_Warnings
|
||
(restriction_IDENTIFIER {, restriction_IDENTIFIER});
|
||
|
||
This pragma allows a series of restriction identifiers to be specified
|
||
(the list of allowed identifiers is the same as for pragma
|
||
`Restrictions'). For each of these identifiers the compiler checks for
|
||
violations of the restriction, but generates a warning message rather
|
||
than an error message if the restriction is violated.
|
||
|
||
One use of this is in situations where you want to know about
|
||
violations of a restriction, but you want to ignore some of these
|
||
violations. Consider this example, where you want to set Ada_95 mode
|
||
and enable style checks, but you want to know about any other use of
|
||
implementation pragmas:
|
||
|
||
pragma Restriction_Warnings (No_Implementation_Pragmas);
|
||
pragma Warnings (Off, "violation of No_Implementation_Pragmas");
|
||
pragma Ada_95;
|
||
pragma Style_Checks ("2bfhkM160");
|
||
pragma Warnings (On, "violation of No_Implementation_Pragmas");
|
||
|
||
By including the above lines in a configuration pragmas file, the
|
||
Ada_95 and Style_Checks pragmas are accepted without generating a
|
||
warning, but any other use of implementation defined pragmas will cause
|
||
a warning to be generated.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Restrictions" origin="Ada RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Restrictions (restriction{, restriction});</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Reviewable" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Reviewable;
|
||
|
||
This pragma is an RM-defined standard pragma, but has no effect on the
|
||
program being compiled, or on the code generated for the program.
|
||
|
||
To obtain the required output specified in RM H.3.1, the compiler must
|
||
be run with various special switches as follows:
|
||
|
||
* `Where compiler-generated run-time checks remain'
|
||
|
||
The switch `-gnatGL' may be used to list the expanded code in
|
||
pseudo-Ada form. Runtime checks show up in the listing either as
|
||
explicit checks or operators marked with {} to indicate a check is
|
||
present.
|
||
|
||
* `An identification of known exceptions at compile time'
|
||
|
||
If the program is compiled with `-gnatwa', the compiler warning
|
||
messages will indicate all cases where the compiler detects that
|
||
an exception is certain to occur at run time.
|
||
|
||
* `Possible reads of uninitialized variables'
|
||
|
||
The compiler warns of many such cases, but its output is
|
||
incomplete.
|
||
|
||
The CodePeer analysis tool may be used to obtain a comprehensive list
|
||
of all possible points at which uninitialized data may be read.
|
||
|
||
* `Where run-time support routines are implicitly invoked'
|
||
|
||
In the output from `-gnatGL', run-time calls are explicitly listed
|
||
as calls to the relevant run-time routine.
|
||
|
||
* `Object code listing'
|
||
|
||
This may be obtained either by using the `-S' switch, or the
|
||
objdump utility.
|
||
|
||
* `Constructs known to be erroneous at compile time'
|
||
|
||
These are identified by warnings issued by the compiler (use
|
||
`-gnatwa').
|
||
|
||
* `Stack usage information'
|
||
|
||
Static stack usage data (maximum per-subprogram) can be obtained
|
||
via the `-fstack-usage' switch to the compiler. Dynamic stack
|
||
usage data (per task) can be obtained via the `-u' switch to
|
||
gnatbind
|
||
|
||
The gnatstack utility can be used to provide additional information on
|
||
stack usage.
|
||
|
||
* `Object code listing of entire partition'
|
||
|
||
This can be obtained by compiling the partition with `-S', or by
|
||
applying objdump to all the object files that are part of the
|
||
partition.
|
||
|
||
* `A description of the run-time model'
|
||
|
||
The full sources of the run-time are available, and the
|
||
documentation of these routines describes how these run-time
|
||
routines interface to the underlying operating system facilities.
|
||
|
||
* `Control and data-flow information'
|
||
|
||
The CodePeer tool may be used to obtain complete control and data-flow
|
||
information, as well as comprehensive messages identifying possible
|
||
problems based on this information.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="SPARK_Mode" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma SPARK_Mode [(On | Off)] ;
|
||
|
||
In general a program can have some parts that are in SPARK 2014 (and
|
||
follow all the rules in the SPARK Reference Manual), and some parts
|
||
that are full Ada 2012.
|
||
|
||
The SPARK_Mode pragma is used to identify which parts are in SPARK 2014
|
||
(by default programs are in full Ada). The SPARK_Mode pragma can be
|
||
used in the following places:
|
||
|
||
* As a configuration pragma, in which case it sets the default mode
|
||
for all units compiled with this pragma.
|
||
|
||
* Immediately following a library-level subprogram spec
|
||
|
||
* Immediately within a library-level package body
|
||
|
||
* Immediately following the `private' keyword of a library-level
|
||
package spec
|
||
|
||
* Immediately following the `begin' keyword of a library-level
|
||
package body
|
||
|
||
* Immediately within a library-level subprogram body
|
||
|
||
Normally a subprogram or package spec/body inherits the current mode
|
||
that is active at the point it is declared. But this can be overridden
|
||
by pragma within the spec or body as above.
|
||
|
||
The basic consistency rule is that you can’t turn SPARK_Mode back
|
||
`On', once you have explicitly (with a pragma) turned if `Off'. So the
|
||
following rules apply:
|
||
|
||
If a subprogram spec has SPARK_Mode `Off', then the body must also have
|
||
SPARK_Mode `Off'.
|
||
|
||
For a package, we have four parts:
|
||
|
||
* the package public declarations
|
||
|
||
* the package private part
|
||
|
||
* the body of the package
|
||
|
||
* the elaboration code after `begin'
|
||
|
||
For a package, the rule is that if you explicitly turn SPARK_Mode `Off'
|
||
for any part, then all the following parts must have SPARK_Mode `Off'.
|
||
Note that this may require repeating a pragma SPARK_Mode (`Off') in the
|
||
body. For example, if we have a configuration pragma SPARK_Mode (`On')
|
||
that turns the mode on by default everywhere, and one particular
|
||
package spec has pragma SPARK_Mode (`Off'), then that pragma will need
|
||
to be repeated in the package body.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Secondary_Stack_Size" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Secondary_Stack_Size (integer_EXPRESSION);
|
||
|
||
This pragma appears within the task definition of a single task
|
||
declaration or a task type declaration (like pragma `Storage_Size') and
|
||
applies to all task objects of that type. The argument specifies the
|
||
size of the secondary stack to be used by these task objects, and must
|
||
be of an integer type. The secondary stack is used to handle functions
|
||
that return a variable-sized result, for example a function returning
|
||
an unconstrained String.
|
||
|
||
Note this pragma only applies to targets using fixed secondary stacks,
|
||
like VxWorks 653 and bare board targets, where a fixed block for the
|
||
secondary stack is allocated from the primary stack of the task. By
|
||
default, these targets assign a percentage of the primary stack for the
|
||
secondary stack, as defined by `System.Parameter.Sec_Stack_Percentage'.
|
||
With this pragma, an `integer_EXPRESSION' of bytes is assigned from the
|
||
primary stack instead.
|
||
|
||
For most targets, the pragma does not apply as the secondary stack
|
||
grows on demand: allocated as a chain of blocks in the heap. The
|
||
default size of these blocks can be modified via the `-D' binder option
|
||
as described in `GNAT User’s Guide'.
|
||
|
||
Note that no check is made to see if the secondary stack can fit inside
|
||
the primary stack.
|
||
|
||
Note the pragma cannot appear when the restriction `No_Secondary_Stack'
|
||
is in effect.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Share_Generic" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Share_Generic (GNAME {, GNAME});
|
||
|
||
GNAME ::= generic_unit_NAME | generic_instance_NAME
|
||
|
||
This pragma is provided for compatibility with Dec Ada 83. It has no
|
||
effect in GNAT (which does not implement shared generics), other than
|
||
to check that the given names are all names of generic units or generic
|
||
instances.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Shared" origin="GNAT RM">
|
||
<DOC>This pragma is provided for compatibility with Ada 83. The syntax and
|
||
semantics are identical to pragma Atomic.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Shared_Passive" origin="Ada RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Shared_Passive [(library_unit_name)];</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Short_Circuit_And_Or" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Short_Circuit_And_Or;
|
||
|
||
This configuration pragma causes any occurrence of the AND operator
|
||
applied to operands of type Standard.Boolean to be short-circuited
|
||
(i.e. the AND operator is treated as if it were AND THEN). Or is
|
||
similarly treated as OR ELSE. This may be useful in the context of
|
||
certification protocols requiring the use of short-circuited logical
|
||
operators. If this configuration pragma occurs locally within the file
|
||
being compiled, it applies only to the file being compiled. There is
|
||
no requirement that all units in a partition use this option.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Short_Descriptors" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Short_Descriptors;
|
||
|
||
This pragma is provided for compatibility with other Ada
|
||
implementations. It is recognized but ignored by all current versions
|
||
of GNAT.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Side_Effects" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Side_Effects [ (static_boolean_EXPRESSION) ];
|
||
|
||
For the semantics of this pragma, see the entry for aspect
|
||
`Side_Effects' in the SPARK Reference Manual, section 6.1.12.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Simple_Storage_Pool_Type" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Simple_Storage_Pool_Type (type_LOCAL_NAME);
|
||
|
||
A type can be established as a ‘simple storage pool type’ by
|
||
applying the representation pragma `Simple_Storage_Pool_Type' to the
|
||
type. A type named in the pragma must be a library-level immutably
|
||
limited record type or limited tagged type declared immediately within
|
||
a package declaration. The type can also be a limited private type
|
||
whose full type is allowed as a simple storage pool type.
|
||
|
||
For a simple storage pool type `SSP', nonabstract primitive subprograms
|
||
`Allocate', `Deallocate', and `Storage_Size' can be declared that are
|
||
subtype conformant with the following subprogram declarations:
|
||
|
||
procedure Allocate
|
||
(Pool : in out SSP;
|
||
Storage_Address : out System.Address;
|
||
Size_In_Storage_Elements : System.Storage_Elements.Storage_Count;
|
||
Alignment : System.Storage_Elements.Storage_Count);
|
||
|
||
procedure Deallocate
|
||
(Pool : in out SSP;
|
||
Storage_Address : System.Address;
|
||
Size_In_Storage_Elements : System.Storage_Elements.Storage_Count;
|
||
Alignment : System.Storage_Elements.Storage_Count);
|
||
|
||
function Storage_Size (Pool : SSP)
|
||
return System.Storage_Elements.Storage_Count;
|
||
|
||
Procedure `Allocate' must be declared, whereas `Deallocate' and
|
||
`Storage_Size' are optional. If `Deallocate' is not declared, then
|
||
applying an unchecked deallocation has no effect other than to set its
|
||
actual parameter to null. If `Storage_Size' is not declared, then the
|
||
`Storage_Size' attribute applied to an access type associated with a
|
||
pool object of type SSP returns zero. Additional operations can be
|
||
declared for a simple storage pool type (such as for supporting a
|
||
mark/release storage-management discipline).
|
||
|
||
An object of a simple storage pool type can be associated with an access
|
||
type by specifying the attribute *note Simple_Storage_Pool: f2. For
|
||
example:
|
||
|
||
My_Pool : My_Simple_Storage_Pool_Type;
|
||
|
||
type Acc is access My_Data_Type;
|
||
|
||
for Acc'Simple_Storage_Pool use My_Pool;
|
||
|
||
See attribute *note Simple_Storage_Pool: f2. for further details.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Source_File_Name" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Source_File_Name (
|
||
[Unit_Name =>] unit_NAME,
|
||
Spec_File_Name => STRING_LITERAL,
|
||
[Index => INTEGER_LITERAL]);
|
||
|
||
pragma Source_File_Name (
|
||
[Unit_Name =>] unit_NAME,
|
||
Body_File_Name => STRING_LITERAL,
|
||
[Index => INTEGER_LITERAL]);
|
||
|
||
Use this to override the normal naming convention. It is a
|
||
configuration pragma, and so has the usual applicability of
|
||
configuration pragmas (i.e., it applies to either an entire partition,
|
||
or to all units in a compilation, or to a single unit, depending on how
|
||
it is used). `unit_name' is mapped to `file_name_literal'. The
|
||
identifier for the second argument is required, and indicates whether
|
||
this is the file name for the spec or for the body.
|
||
|
||
The optional Index argument should be used when a file contains multiple
|
||
units, and when you do not want to use `gnatchop' to separate then into
|
||
multiple files (which is the recommended procedure to limit the number
|
||
of recompilations that are needed when some sources change). For
|
||
instance, if the source file `source.ada' contains
|
||
|
||
package B is
|
||
|
||
end B;
|
||
|
||
with B;
|
||
procedure A is
|
||
begin
|
||
|
||
end A;
|
||
|
||
you could use the following configuration pragmas:
|
||
|
||
pragma Source_File_Name
|
||
(B, Spec_File_Name => "source.ada", Index => 1);
|
||
pragma Source_File_Name
|
||
(A, Body_File_Name => "source.ada", Index => 2);
|
||
|
||
Note that the `gnatname' utility can also be used to generate those
|
||
configuration pragmas.
|
||
|
||
Another form of the `Source_File_Name' pragma allows the specification
|
||
of patterns defining alternative file naming schemes to apply to all
|
||
files.
|
||
|
||
pragma Source_File_Name
|
||
( [Spec_File_Name =>] STRING_LITERAL
|
||
[,[Casing =>] CASING_SPEC]
|
||
[,[Dot_Replacement =>] STRING_LITERAL]);
|
||
|
||
pragma Source_File_Name
|
||
( [Body_File_Name =>] STRING_LITERAL
|
||
[,[Casing =>] CASING_SPEC]
|
||
[,[Dot_Replacement =>] STRING_LITERAL]);
|
||
|
||
pragma Source_File_Name
|
||
( [Subunit_File_Name =>] STRING_LITERAL
|
||
[,[Casing =>] CASING_SPEC]
|
||
[,[Dot_Replacement =>] STRING_LITERAL]);
|
||
|
||
CASING_SPEC ::= Lowercase | Uppercase | Mixedcase
|
||
|
||
The first argument is a pattern that contains a single asterisk
|
||
indicating the point at which the unit name is to be inserted in the
|
||
pattern string to form the file name. The second argument is optional.
|
||
If present it specifies the casing of the unit name in the resulting
|
||
file name string. The default is lower case. Finally the third
|
||
argument allows for systematic replacement of any dots in the unit name
|
||
by the specified string literal.
|
||
|
||
Note that Source_File_Name pragmas should not be used if you are using
|
||
project files. The reason for this rule is that the project manager is
|
||
not aware of these pragmas, and so other tools that use the project
|
||
file would not be aware of the intended naming conventions. If you are
|
||
using project files, file naming is controlled by
|
||
Source_File_Name_Project pragmas, which are usually supplied
|
||
automatically by the project manager. A pragma Source_File_Name cannot
|
||
appear after a *note Pragma Source_File_Name_Project: f5.
|
||
|
||
For more details on the use of the `Source_File_Name' pragma, see the
|
||
sections on `Using Other File Names' and `Alternative File Naming
|
||
Schemes' in the `GNAT User’s Guide'.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Source_File_Name_Project" origin="GNAT RM">
|
||
<DOC>This pragma has the same syntax and semantics as pragma
|
||
Source_File_Name. It is only allowed as a stand-alone configuration
|
||
pragma. It cannot appear after a *note Pragma Source_File_Name: f4, and
|
||
most importantly, once pragma Source_File_Name_Project appears, no
|
||
further Source_File_Name pragmas are allowed.
|
||
|
||
The intention is that Source_File_Name_Project pragmas are always
|
||
generated by the Project Manager in a manner consistent with the naming
|
||
specified in a project file, and when naming is controlled in this
|
||
manner, it is not permissible to attempt to modify this naming scheme
|
||
using Source_File_Name or Source_File_Name_Project pragmas (which would
|
||
not be known to the project manager).</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Source_Reference" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Source_Reference (INTEGER_LITERAL, STRING_LITERAL);
|
||
|
||
This pragma must appear as the first line of a source file.
|
||
`integer_literal' is the logical line number of the line following the
|
||
pragma line (for use in error messages and debugging information).
|
||
`string_literal' is a static string constant that specifies the file
|
||
name to be used in error messages and debugging information. This is
|
||
most notably used for the output of `gnatchop' with the `-r' switch, to
|
||
make sure that the original unchopped source file is the one referred
|
||
to.
|
||
|
||
The second argument must be a string literal, it cannot be a static
|
||
string expression other than a string literal. This is because its
|
||
value is needed for error messages issued by all phases of the compiler.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Static_Elaboration_Desired" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Static_Elaboration_Desired;
|
||
|
||
This pragma is used to indicate that the compiler should attempt to
|
||
initialize statically the objects declared in the library unit to which
|
||
the pragma applies, when these objects are initialized (explicitly or
|
||
implicitly) by an aggregate. In the absence of this pragma, aggregates
|
||
in object declarations are expanded into assignments and loops, even
|
||
when the aggregate components are static constants. When the aggregate
|
||
is present the compiler builds a static expression that requires no
|
||
run-time code, so that the initialized object can be placed in
|
||
read-only data space. If the components are not static, or the
|
||
aggregate has more that 100 components, the compiler emits a warning
|
||
that the pragma cannot be obeyed. (See also the restriction
|
||
No_Implicit_Loops, which supports static construction of larger
|
||
aggregates with static components that include an others choice.)</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Storage_Size" origin="Ada RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Storage_Size;</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Stream_Convert" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Stream_Convert (
|
||
[Entity =>] type_LOCAL_NAME,
|
||
[Read =>] function_NAME,
|
||
[Write =>] function_NAME);
|
||
|
||
This pragma provides an efficient way of providing user-defined stream
|
||
attributes. Not only is it simpler to use than specifying the
|
||
attributes directly, but more importantly, it allows the specification
|
||
to be made in such a way that the predefined unit Ada.Streams is not
|
||
loaded unless it is actually needed (i.e. unless the stream attributes
|
||
are actually used); the use of the Stream_Convert pragma adds no
|
||
overhead at all, unless the stream attributes are actually used on the
|
||
designated type.
|
||
|
||
The first argument specifies the type for which stream functions are
|
||
provided. The second parameter provides a function used to read values
|
||
of this type. It must name a function whose argument type may be any
|
||
subtype, and whose returned type must be the type given as the first
|
||
argument to the pragma.
|
||
|
||
The meaning of the `Read' parameter is that if a stream attribute
|
||
directly or indirectly specifies reading of the type given as the first
|
||
parameter, then a value of the type given as the argument to the Read
|
||
function is read from the stream, and then the Read function is used to
|
||
convert this to the required target type.
|
||
|
||
Similarly the `Write' parameter specifies how to treat write attributes
|
||
that directly or indirectly apply to the type given as the first
|
||
parameter. It must have an input parameter of the type specified by
|
||
the first parameter, and the return type must be the same as the input
|
||
type of the Read function. The effect is to first call the Write
|
||
function to convert to the given stream type, and then write the result
|
||
type to the stream.
|
||
|
||
The Read and Write functions must not be overloaded subprograms. If
|
||
necessary renamings can be supplied to meet this requirement. The
|
||
usage of this attribute is best illustrated by a simple example, taken
|
||
from the GNAT implementation of package Ada.Strings.Unbounded:
|
||
|
||
function To_Unbounded (S : String) return Unbounded_String
|
||
renames To_Unbounded_String;
|
||
|
||
pragma Stream_Convert
|
||
(Unbounded_String, To_Unbounded, To_String);
|
||
|
||
The specifications of the referenced functions, as given in the Ada
|
||
Reference Manual are:
|
||
|
||
function To_Unbounded_String (Source : String)
|
||
return Unbounded_String;
|
||
|
||
function To_String (Source : Unbounded_String)
|
||
return String;
|
||
|
||
The effect is that if the value of an unbounded string is written to a
|
||
stream, then the representation of the item in the stream is in the
|
||
same format that would be used for `Standard.String'Output', and this
|
||
same representation is expected when a value of this type is read from
|
||
the stream. Note that the value written always includes the bounds,
|
||
even for Unbounded_String’Write, since Unbounded_String is not an
|
||
array type.
|
||
|
||
Note that the `Stream_Convert' pragma is not effective in the case of a
|
||
derived type of a non-limited tagged type. If such a type is specified
|
||
then the pragma is silently ignored, and the default implementation of
|
||
the stream attributes is used instead.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Style_Checks" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Style_Checks (string_LITERAL | ALL_CHECKS |
|
||
On | Off [, LOCAL_NAME]);
|
||
|
||
This pragma is used in conjunction with compiler switches to control the
|
||
built in style 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 style options are to be
|
||
activated. These are additive, so they apply in addition to any
|
||
previously set style check options. The codes for the options are the
|
||
same as those used in the `-gnaty' switch to `gcc' or `gnatmake'. For
|
||
example the following two methods can be used to enable layout checking
|
||
and to change the maximum nesting level value:
|
||
|
||
* -- switch on layout checks
|
||
pragma Style_Checks ("l");
|
||
-- set the number of maximum allowed nesting levels to 15
|
||
pragma Style_Checks ("L15");
|
||
|
||
* gcc -c -gnatyl -gnatyL15 ...
|
||
|
||
The string literal values can be cumulatively switched on and off by
|
||
prefixing the value with `+' or `-', where:
|
||
|
||
* `+' is equivalent to no prefix. It applies the check referenced by
|
||
the literal value;
|
||
|
||
* `-' switches the referenced check off.
|
||
|
||
-- allow misaligned block by disabling layout check
|
||
pragma Style_Checks ("-l");
|
||
declare
|
||
msg : constant String := "Hello";
|
||
begin
|
||
Put_Line (msg);
|
||
end;
|
||
|
||
-- enable the layout check again
|
||
pragma Style_Checks ("l");
|
||
declare
|
||
msg : constant String := "Hello";
|
||
begin
|
||
Put_Line (msg);
|
||
end;
|
||
|
||
The code above contains two layout errors, however, only the last line
|
||
is picked up by the compiler.
|
||
|
||
Similarly, the switches containing a numeric value can be applied in
|
||
sequence. In the example below, the permitted nesting level is reduced
|
||
in in the middle block and the compiler raises a warning on the
|
||
highlighted line.
|
||
|
||
-- Permit 3 levels of nesting
|
||
pragma Style_Checks ("L3");
|
||
|
||
procedure Main is
|
||
begin
|
||
if True then
|
||
if True then
|
||
null;
|
||
end if;
|
||
end if;
|
||
-- Reduce permitted nesting levels to 2.
|
||
-- Note that "+L2" and "L2" are equivalent.
|
||
pragma Style_Checks ("+L2");
|
||
if True then
|
||
if True then
|
||
null;
|
||
end if;
|
||
end if;
|
||
-- Disable checking permitted nesting levels.
|
||
-- Note that the number after "-L" is insignificant,
|
||
-- "-L", "-L3" and "-Lx" are all equivalent.
|
||
pragma Style_Checks ("-L3");
|
||
if True then
|
||
if True then
|
||
null;
|
||
end if;
|
||
end if;
|
||
end Main;
|
||
|
||
The form `ALL_CHECKS' activates all standard checks (its use is
|
||
equivalent to the use of the `gnaty' switch with no options. See the
|
||
`GNAT User’s Guide' for details.)
|
||
|
||
Note: the behavior is slightly different in GNAT mode (`-gnatg' used).
|
||
In this case, `ALL_CHECKS' implies the standard set of GNAT mode style
|
||
check options (i.e. equivalent to `-gnatyg').
|
||
|
||
The forms with `Off' and `On' can be used to temporarily disable style
|
||
checks as shown in the following example:
|
||
|
||
pragma Style_Checks ("k"); -- requires keywords in lower case
|
||
pragma Style_Checks (Off); -- turn off style checks
|
||
NULL; -- this will not generate an error message
|
||
pragma Style_Checks (On); -- turn style checks back on
|
||
NULL; -- this will generate an error message
|
||
|
||
Finally the two argument form is allowed only if the first argument is
|
||
`On' or `Off'. The effect is to turn of semantic style checks for the
|
||
specified entity, as shown in the following example:
|
||
|
||
pragma Style_Checks ("r"); -- require consistency of identifier casing
|
||
Arg : Integer;
|
||
Rf1 : Integer := ARG; -- incorrect, wrong case
|
||
pragma Style_Checks (Off, Arg);
|
||
Rf2 : Integer := ARG; -- OK, no error</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Subprogram_Variant" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Subprogram_Variant (SUBPROGRAM_VARIANT_LIST);
|
||
|
||
SUBPROGRAM_VARIANT_LIST ::=
|
||
STRUCTURAL_SUBPROGRAM_VARIANT_ITEM
|
||
| NUMERIC_SUBPROGRAM_VARIANT_ITEMS
|
||
|
||
NUMERIC_SUBPROGRAM_VARIANT_ITEMS ::=
|
||
NUMERIC_SUBPROGRAM_VARIANT_ITEM {, NUMERIC_SUBPROGRAM_VARIANT_ITEM}
|
||
|
||
NUMERIC_SUBPROGRAM_VARIANT_ITEM ::=
|
||
CHANGE_DIRECTION => EXPRESSION
|
||
|
||
STRUCTURAL_SUBPROGRAM_VARIANT_ITEM ::=
|
||
STRUCTURAL => EXPRESSION
|
||
|
||
CHANGE_DIRECTION ::= Increases | Decreases
|
||
|
||
The `Subprogram_Variant' pragma is intended to be an exact replacement
|
||
for the implementation-defined `Subprogram_Variant' aspect, and shares
|
||
its restrictions and semantics.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Subtitle" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Subtitle ([Subtitle =>] STRING_LITERAL);
|
||
|
||
This pragma is recognized for compatibility with other Ada compilers
|
||
but is ignored by GNAT.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Suppress" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Suppress (Identifier [, [On =>] Name]);
|
||
|
||
This is a standard pragma, and supports all the check names required in
|
||
the RM. It is included here because GNAT recognizes some additional
|
||
check names that are implementation defined (as permitted by the RM):
|
||
|
||
* `Alignment_Check' can be used to suppress alignment checks on
|
||
addresses used in address clauses. Such checks can also be
|
||
suppressed by suppressing range checks, but the specific use of
|
||
`Alignment_Check' allows suppression of alignment checks without
|
||
suppressing other range checks. Note that `Alignment_Check' is
|
||
suppressed by default on machines (such as the x86) with
|
||
non-strict alignment.
|
||
|
||
* `Atomic_Synchronization' can be used to suppress the special memory
|
||
synchronization instructions that are normally generated for
|
||
access to `Atomic' variables to ensure correct synchronization
|
||
between tasks that use such variables for synchronization purposes.
|
||
|
||
* `Duplicated_Tag_Check' Can be used to suppress the check that is
|
||
generated for a duplicated tag value when a tagged type is
|
||
declared.
|
||
|
||
* `Container_Checks' Can be used to suppress all checks within
|
||
Ada.Containers and instances of its children, including
|
||
Tampering_Check.
|
||
|
||
* `Tampering_Check' Can be used to suppress tampering check in the
|
||
containers.
|
||
|
||
* `Predicate_Check' can be used to control whether predicate checks
|
||
are active. It is applicable only to predicates for which the
|
||
policy is `Check'. Unlike `Assertion_Policy', which determines if
|
||
a given predicate is ignored or checked for the whole program, the
|
||
use of `Suppress' and `Unsuppress' with this check name allows a
|
||
given predicate to be turned on and off at specific points in the
|
||
program.
|
||
|
||
* `Validity_Check' can be used specifically to control validity
|
||
checks. If `Suppress' is used to suppress validity checks, then
|
||
no validity checks are performed, including those specified by the
|
||
appropriate compiler switch or the `Validity_Checks' pragma.
|
||
|
||
* Additional check names previously introduced by use of the
|
||
`Check_Name' pragma are also allowed.
|
||
|
||
Note that pragma Suppress gives the compiler permission to omit checks,
|
||
but does not require the compiler to omit checks. The compiler will
|
||
generate checks if they are essentially free, even when they are
|
||
suppressed. In particular, if the compiler can prove that a certain
|
||
check will necessarily fail, it will generate code to do an
|
||
unconditional ‘raise’, even if checks are suppressed. The compiler
|
||
warns in this case.
|
||
|
||
Of course, run-time checks are omitted whenever the compiler can prove
|
||
that they will not fail, whether or not checks are suppressed.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Suppress_All" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Suppress_All;
|
||
|
||
This pragma can appear anywhere within a unit. The effect is to apply
|
||
`Suppress (All_Checks)' to the unit in which it appears. This pragma
|
||
is implemented for compatibility with DEC Ada 83 usage where it appears
|
||
at the end of a unit, and for compatibility with Rational Ada, where it
|
||
appears as a program unit pragma. The use of the standard Ada pragma
|
||
`Suppress (All_Checks)' as a normal configuration pragma is the
|
||
preferred usage in GNAT.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Suppress_Debug_Info" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Suppress_Debug_Info ([Entity =>] LOCAL_NAME);
|
||
|
||
This pragma can be used to suppress generation of debug information for
|
||
the specified entity. It is intended primarily for use in debugging the
|
||
debugger, and navigating around debugger problems.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Suppress_Exception_Locations" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Suppress_Exception_Locations;
|
||
|
||
In normal mode, a raise statement for an exception by default generates
|
||
an exception message giving the file name and line number for the
|
||
location of the raise. This is useful for debugging and logging
|
||
purposes, but this entails extra space for the strings for the
|
||
messages. The configuration pragma `Suppress_Exception_Locations' can
|
||
be used to suppress the generation of these strings, with the result
|
||
that space is saved, but the exception message for such raises is null.
|
||
This configuration pragma may appear in a global configuration pragma
|
||
file, or in a specific unit as usual. It is not required that this
|
||
pragma be used consistently within a partition, so it is fine to have
|
||
some units within a partition compiled with this pragma and others
|
||
compiled in normal mode without it.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Suppress_Initialization" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Suppress_Initialization ([Entity =>] variable_or_subtype_LOCAL_NAME);
|
||
|
||
Here variable_or_subtype_LOCAL_NAME is the name introduced by a type
|
||
declaration or subtype declaration or the name of a variable introduced
|
||
by an object declaration.
|
||
|
||
In the case of a type or subtype this pragma suppresses any implicit or
|
||
explicit initialization for all variables of the given type or subtype,
|
||
including initialization resulting from the use of pragmas
|
||
Normalize_Scalars or Initialize_Scalars.
|
||
|
||
This is considered a representation item, so it cannot be given after
|
||
the type is frozen. It applies to all subsequent object declarations,
|
||
and also any allocator that creates objects of the type.
|
||
|
||
If the pragma is given for the first subtype, then it is considered to
|
||
apply to the base type and all its subtypes. If the pragma is given for
|
||
other than a first subtype, then it applies only to the given subtype.
|
||
The pragma may not be given after the type is frozen.
|
||
|
||
Note that this includes eliminating initialization of discriminants for
|
||
discriminated types, and tags for tagged types. In these cases, you
|
||
will have to use some non-portable mechanism (e.g. address overlays or
|
||
unchecked conversion) to achieve required initialization of these
|
||
fields before accessing any object of the corresponding type.
|
||
|
||
For the variable case, implicit initialization for the named variable
|
||
is suppressed, just as though its subtype had been given in a pragma
|
||
Suppress_Initialization, as described above.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Task_Dispatching_Policy" origin="Ada RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Task_Dispatching_Policy (policy_identifier);</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Task_Name" origin="GNAT RM">
|
||
<DOC>Syntax
|
||
|
||
pragma Task_Name (string_EXPRESSION);
|
||
|
||
This pragma appears within a task definition (like pragma `Priority')
|
||
and applies to the task in which it appears. The argument must be of
|
||
type String, and provides a name to be used for the task instance when
|
||
the task is created. Note that this expression is not required to be
|
||
static, and in particular, it can contain references to task
|
||
discriminants. This facility can be used to provide different names
|
||
for different tasks as they are created, as illustrated in the example
|
||
below.
|
||
|
||
The task name is recorded internally in the run-time structures and is
|
||
accessible to tools like the debugger. In addition the routine
|
||
`Ada.Task_Identification.Image' will return this string, with a unique
|
||
task address appended.
|
||
|
||
-- Example of the use of pragma Task_Name
|
||
|
||
with Ada.Task_Identification;
|
||
use Ada.Task_Identification;
|
||
with Text_IO; use Text_IO;
|
||
procedure t3 is
|
||
|
||
type Astring is access String;
|
||
|
||
task type Task_Typ (Name : access String) is
|
||
pragma Task_Name (Name.all);
|
||
end Task_Typ;
|
||
|
||
task body Task_Typ is
|
||
Nam : constant String := Image (Current_Task);
|
||
begin
|
||
Put_Line ("-->" & Nam (1 .. 14) & "<--");
|
||
end Task_Typ;
|
||
|
||
type Ptr_Task is access Task_Typ;
|
||
Task_Var : Ptr_Task;
|
||
|
||
begin
|
||
Task_Var :=
|
||
new Task_Typ (new String'("This is task 1"));
|
||
Task_Var :=
|
||
new Task_Typ (new String'("This is task 2"));
|
||
end;</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Task_Storage" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Task_Storage (
|
||
[Task_Type =>] LOCAL_NAME,
|
||
[Top_Guard =>] static_integer_EXPRESSION);
|
||
|
||
This pragma specifies the length of the guard area for tasks. The guard
|
||
area is an additional storage area allocated to a task. A value of zero
|
||
means that either no guard area is created or a minimal guard area is
|
||
created, depending on the target. This pragma can appear anywhere a
|
||
`Storage_Size' attribute definition clause is allowed for a task type.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Test_Case" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Test_Case (
|
||
[Name =>] static_string_Expression
|
||
,[Mode =>] (Nominal | Robustness)
|
||
[, Requires => Boolean_Expression]
|
||
[, Ensures => Boolean_Expression]);
|
||
|
||
The `Test_Case' pragma allows defining fine-grain specifications for
|
||
use by testing tools. The compiler checks the validity of the
|
||
`Test_Case' pragma, but its presence does not lead to any modification
|
||
of the code generated by the compiler.
|
||
|
||
`Test_Case' pragmas may only appear immediately following the
|
||
(separate) declaration of a subprogram in a package declaration, inside
|
||
a package spec unit. Only other pragmas may intervene (that is appear
|
||
between the subprogram declaration and a test case).
|
||
|
||
The compiler checks that boolean expressions given in `Requires' and
|
||
`Ensures' are valid, where the rules for `Requires' are the same as the
|
||
rule for an expression in `Precondition' and the rules for `Ensures'
|
||
are the same as the rule for an expression in `Postcondition'. In
|
||
particular, attributes `'Old' and `'Result' can only be used within the
|
||
`Ensures' expression. The following is an example of use within a
|
||
package spec:
|
||
|
||
package Math_Functions is
|
||
|
||
function Sqrt (Arg : Float) return Float;
|
||
pragma Test_Case (Name => "Test 1",
|
||
Mode => Nominal,
|
||
Requires => Arg < 10000.0,
|
||
Ensures => Sqrt'Result < 10.0);
|
||
|
||
end Math_Functions;
|
||
|
||
The meaning of a test case is that there is at least one context where
|
||
`Requires' holds such that, if the associated subprogram is executed in
|
||
that context, then `Ensures' holds when the subprogram returns. Mode
|
||
`Nominal' indicates that the input context should also satisfy the
|
||
precondition of the subprogram, and the output context should also
|
||
satisfy its postcondition. Mode `Robustness' indicates that the
|
||
precondition and postcondition of the subprogram should be ignored for
|
||
this test case.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Thread_Local_Storage" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Thread_Local_Storage ([Entity =>] LOCAL_NAME);
|
||
|
||
This pragma specifies that the specified entity, which must be a
|
||
variable declared in a library-level package, is to be marked as
|
||
“Thread Local Storage” (`TLS'). On systems supporting this (which
|
||
include Windows, Solaris, GNU/Linux, and VxWorks), this causes each
|
||
thread (and hence each Ada task) to see a distinct copy of the variable.
|
||
|
||
The variable must not have default initialization, and if there is an
|
||
explicit initialization, it must be either `null' for an access
|
||
variable, a static expression for a scalar variable, or a fully static
|
||
aggregate for a composite type, that is to say, an aggregate all of
|
||
whose components are static, and which does not include packed or
|
||
discriminated components.
|
||
|
||
This provides a low-level mechanism similar to that provided by the
|
||
`Ada.Task_Attributes' package, but much more efficient and is also
|
||
useful in writing interface code that will interact with foreign
|
||
threads.
|
||
|
||
If this pragma is used on a system where `TLS' is not supported, then
|
||
an error message will be generated and the program will be rejected.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Time_Slice" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Time_Slice (static_duration_EXPRESSION);
|
||
|
||
For implementations of GNAT on operating systems where it is possible
|
||
to supply a time slice value, this pragma may be used for this purpose.
|
||
It is ignored if it is used in a system that does not allow this
|
||
control, or if it appears in other than the main program unit.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Title" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Title (TITLING_OPTION [, TITLING OPTION]);
|
||
|
||
TITLING_OPTION ::=
|
||
[Title =>] STRING_LITERAL,
|
||
| [Subtitle =>] STRING_LITERAL
|
||
|
||
Syntax checked but otherwise ignored by GNAT. This is a listing control
|
||
pragma used in DEC Ada 83 implementations to provide a title and/or
|
||
subtitle for the program listing. The program listing generated by GNAT
|
||
does not have titles or subtitles.
|
||
|
||
Unlike other pragmas, the full flexibility of named notation is allowed
|
||
for this pragma, i.e., the parameters may be given in any order if named
|
||
notation is used, and named and positional notation can be mixed
|
||
following the normal rules for procedure calls in Ada.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Type_Invariant" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Type_Invariant
|
||
([Entity =>] type_LOCAL_NAME,
|
||
[Check =>] EXPRESSION);
|
||
|
||
The `Type_Invariant' pragma is intended to be an exact replacement for
|
||
the language-defined `Type_Invariant' aspect, and shares its
|
||
restrictions and semantics. It differs from the language defined
|
||
`Invariant' pragma in that it does not permit a string parameter, and
|
||
it is controlled by the assertion identifier `Type_Invariant' rather
|
||
than `Invariant'.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Type_Invariant_Class" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Type_Invariant_Class
|
||
([Entity =>] type_LOCAL_NAME,
|
||
[Check =>] EXPRESSION);
|
||
|
||
The `Type_Invariant_Class' pragma is intended to be an exact
|
||
replacement for the language-defined `Type_Invariant'Class' aspect, and
|
||
shares its restrictions and semantics.
|
||
|
||
Note: This pragma is called `Type_Invariant_Class' rather than
|
||
`Type_Invariant'Class' because the latter would not be strictly
|
||
conforming to the allowed syntax for pragmas. The motivation for
|
||
providing pragmas equivalent to the aspects is to allow a program to be
|
||
written using the pragmas, and then compiled if necessary using an Ada
|
||
compiler that does not recognize the pragmas or aspects, but is
|
||
prepared to ignore the pragmas. The assertion policy that controls this
|
||
pragma is `Type_Invariant'Class', not `Type_Invariant_Class'.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Unchecked_Union" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Unchecked_Union (first_subtype_LOCAL_NAME);
|
||
|
||
This pragma is used to specify a representation of a record type that is
|
||
equivalent to a C union. It was introduced as a GNAT implementation
|
||
defined pragma in the GNAT Ada 95 mode. Ada 2005 includes an extended
|
||
version of this pragma, making it language defined, and GNAT fully
|
||
implements this extended version in all language modes (Ada 83, Ada 95,
|
||
and Ada 2005). For full details, consult the Ada 2012 Reference Manual,
|
||
section B.3.3.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Unevaluated_Use_Of_Old" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Unevaluated_Use_Of_Old (Error | Warn | Allow);
|
||
|
||
This pragma controls the processing of attributes Old and Loop_Entry.
|
||
If either of these attributes is used in a potentially unevaluated
|
||
expression (e.g. the then or else parts of an if expression), then
|
||
normally this usage is considered illegal if the prefix of the attribute
|
||
is other than an entity name. The language requires this behavior for
|
||
Old, and GNAT copies the same rule for Loop_Entry.
|
||
|
||
The reason for this rule is that otherwise, we can have a situation
|
||
where we save the Old value, and this results in an exception, even
|
||
though we might not evaluate the attribute. Consider this example:
|
||
|
||
package UnevalOld is
|
||
K : Character;
|
||
procedure U (A : String; C : Boolean) -- ERROR
|
||
with Post => (if C then A(1)'Old = K else True);
|
||
end;
|
||
|
||
If procedure U is called with a string with a lower bound of 2, and C
|
||
false, then an exception would be raised trying to evaluate A(1) on
|
||
entry even though the value would not be actually used.
|
||
|
||
Although the rule guarantees against this possibility, it is sometimes
|
||
too restrictive. For example if we know that the string has a lower
|
||
bound of 1, then we will never raise an exception. The pragma
|
||
`Unevaluated_Use_Of_Old' can be used to modify this behavior. If the
|
||
argument is `Error' then an error is given (this is the default RM
|
||
behavior). If the argument is `Warn' then the usage is allowed as legal
|
||
but with a warning that an exception might be raised. If the argument
|
||
is `Allow' then the usage is allowed as legal without generating a
|
||
warning.
|
||
|
||
This pragma may appear as a configuration pragma, or in a declarative
|
||
part or package specification. In the latter case it applies to uses up
|
||
to the end of the corresponding statement sequence or sequence of
|
||
package declarations.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Unimplemented_Unit" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Unimplemented_Unit;
|
||
|
||
If this pragma occurs in a unit that is processed by the compiler, GNAT
|
||
aborts with the message `xxx not implemented', where `xxx' is the name
|
||
of the current compilation unit. This pragma is intended to allow the
|
||
compiler to handle unimplemented library units in a clean manner.
|
||
|
||
The abort only happens if code is being generated. Thus you can use
|
||
specs of unimplemented packages in syntax or semantic checking mode.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Universal_Aliasing" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Universal_Aliasing [([Entity =>] type_LOCAL_NAME)];
|
||
|
||
`type_LOCAL_NAME' must refer to a type declaration in the current
|
||
declarative part. The effect is to inhibit strict type-based aliasing
|
||
optimizations for the given type. For a detailed description of the
|
||
strict type-based aliasing optimizations and the situations in which
|
||
they need to be suppressed, see the section on `Optimization and Strict
|
||
Aliasing' in the `GNAT User’s Guide'.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Unmodified" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Unmodified (LOCAL_NAME {, LOCAL_NAME});
|
||
|
||
This pragma signals that the assignable entities (variables, `out'
|
||
parameters, `in out' parameters) whose names are listed are
|
||
deliberately not assigned in the current source unit. This suppresses
|
||
warnings about the entities being referenced but not assigned, and in
|
||
addition a warning will be generated if one of these entities is in
|
||
fact assigned in the same unit as the pragma (or in the corresponding
|
||
body, or one of its subunits).
|
||
|
||
This is particularly useful for clearly signaling that a particular
|
||
parameter is not modified, 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, UNUSE, TMP, TEMP' 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 Unmodified' for such variables, though it is
|
||
harmless to do so.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Unreferenced" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Unreferenced (LOCAL_NAME {, LOCAL_NAME});
|
||
pragma Unreferenced (library_unit_NAME {, library_unit_NAME});
|
||
|
||
This pragma signals that the entities whose names are listed are
|
||
deliberately not referenced in the current source unit after the
|
||
occurrence of the pragma. This suppresses warnings about the entities
|
||
being unreferenced, and in addition a warning will be generated if one
|
||
of these entities is in fact subsequently referenced in the same unit
|
||
as the pragma (or in the corresponding body, or one of its subunits).
|
||
|
||
This is particularly useful for clearly signaling that a particular
|
||
parameter is not referenced in some particular subprogram implementation
|
||
and that this is deliberate. It can also be useful in the case of
|
||
objects declared only for their initialization or finalization side
|
||
effects.
|
||
|
||
If `LOCAL_NAME' identifies more than one matching homonym in the
|
||
current scope, then the entity most recently declared is the one to
|
||
which the pragma applies. Note that in the case of accept formals, the
|
||
pragma Unreferenced may appear immediately after the keyword `do' which
|
||
allows the indication of whether or not accept formals are referenced
|
||
or not to be given individually for each accept statement.
|
||
|
||
The left hand side of an assignment does not count as a reference for
|
||
the purpose of this pragma. Thus it is fine to assign to an entity for
|
||
which pragma Unreferenced is given. However, use of an entity as an
|
||
actual for an out parameter does count as a reference unless warnings
|
||
for unread output parameters are enabled via `-gnatw.o'.
|
||
|
||
Note that if a warning is desired for all calls to a given subprogram,
|
||
regardless of whether they occur in the same unit as the subprogram
|
||
declaration, then this pragma should not be used (calls from another
|
||
unit would not be flagged); pragma Obsolescent can be used instead for
|
||
this purpose, see *note Pragma Obsolescent: b6.
|
||
|
||
The second form of pragma `Unreferenced' is used within a context
|
||
clause. In this case the arguments must be unit names of units
|
||
previously mentioned in `with' clauses (similar to the usage of pragma
|
||
`Elaborate_All'). The effect is to suppress warnings about unreferenced
|
||
units and unreferenced entities within these units.
|
||
|
||
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 Unreferenced' for such variables, though it is
|
||
harmless to do so.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Unreferenced_Objects" origin="GNAT RM">
|
||
<DOC>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.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Unreserve_All_Interrupts" origin="GNAT RM">
|
||
<DOC>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.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Unsuppress" origin="GNAT RM">
|
||
<DOC>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.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Unused" origin="GNAT RM">
|
||
<DOC>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.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Use_VADS_Size" origin="GNAT RM">
|
||
<DOC>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.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="User_Aspect_Definition" origin="GNAT RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma User_Aspect_Definition
|
||
(Identifier {, Identifier [(Identifier {, Identifier})]});
|
||
|
||
This configuration pragma defines a new aspect, making it available for
|
||
subsequent use in a `User_Aspect' aspect specification. The first
|
||
identifier is the name of the new aspect. Any subsequent arguments
|
||
specify the names of other aspects. A subsequent name for which no
|
||
parenthesized arguments are given shall denote either a Boolean-valued
|
||
non-representation aspect or an aspect that has been defined by another
|
||
`User_Aspect_Definition' pragma. A name for which one or more arguments
|
||
are given shall be either `Annotate' or `Local_Restrictions' (and the
|
||
arguments shall be appropriate for the named aspect).
|
||
|
||
This pragma, together with the `User_Aspect' aspect, provides a
|
||
mechanism for avoiding textual duplication if some set of aspect
|
||
specifications is needed in multiple places. This is somewhat analogous
|
||
to how profiles allow avoiding duplication of `Restrictions' pragmas.
|
||
|
||
The visibility rules for an aspect defined by a `User_Aspect_Definition'
|
||
pragma are the same as for a check name introduced by a `Check_Name'
|
||
pragma. If multiple definitions are visible for some aspect at some
|
||
point, then the definitions must agree. A predefined aspect cannot be
|
||
redefined.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Validity_Checks" origin="GNAT RM">
|
||
<DOC>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</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Volatile" origin="GNAT RM">
|
||
<DOC>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.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Volatile_Components" origin="Ada RM">
|
||
<DOC>Syntax:
|
||
|
||
pragma Volatile_Components;</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Volatile_Full_Access" origin="GNAT RM">
|
||
<DOC>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.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Volatile_Function" origin="GNAT RM">
|
||
<DOC>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.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Warning_As_Error" origin="GNAT RM">
|
||
<DOC>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: 12a. 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').
|
||
|
||
pragma Warning_As_Error ("*never assigned*");
|
||
function Warnerr return String is
|
||
X : Integer;
|
||
|
|
||
>>> error: variable "X" is never read and
|
||
never assigned [-gnatwv] [warning-as-error]
|
||
|
||
Y : Integer;
|
||
|
|
||
>>> warning: variable "Y" is assigned but
|
||
never read [-gnatwu]
|
||
|
||
begin
|
||
Y := 0;
|
||
return %ABC%;
|
||
|
|
||
>>> error: use of "%" is an obsolescent
|
||
feature (RM J.2(4)), use """ instead
|
||
[-gnatwj] [warning-as-error]
|
||
|
||
end;
|
||
|
||
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.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Warnings" origin="GNAT RM">
|
||
<DOC>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'.</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Weak_External" origin="GNAT RM">
|
||
<DOC>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;</DOC>
|
||
</PRAGMA>
|
||
<PRAGMA id="0" name="Wide_Character_Encoding" origin="GNAT RM">
|
||
<DOC>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.</DOC>
|
||
</PRAGMA>
|
||
<STANDARD name=""&"" category="function"/>
|
||
<STANDARD name="">"" category="function"/>
|
||
<STANDARD name="">="" category="function"/>
|
||
<STANDARD name=""<"" category="function"/>
|
||
<STANDARD name=""<="" category="function"/>
|
||
<STANDARD name=""*"" category="function"/>
|
||
<STANDARD name=""**"" category="function"/>
|
||
<STANDARD name=""+"" category="function"/>
|
||
<STANDARD name=""-"" category="function"/>
|
||
<STANDARD name=""/"" category="function"/>
|
||
<STANDARD name=""/="" category="function"/>
|
||
<STANDARD name=""="" category="function"/>
|
||
<STANDARD name=""abs"" category="function"/>
|
||
<STANDARD name=""and"" category="function"/>
|
||
<STANDARD name=""mod"" category="function"/>
|
||
<STANDARD name=""not"" category="function"/>
|
||
<STANDARD name=""or"" category="function"/>
|
||
<STANDARD name=""rem"" category="function"/>
|
||
<STANDARD name=""xor"" category="function"/>
|
||
<STANDARD name="ASCII" category="package"><FIELD name='NUL' doc='16#00#'/>
|
||
<FIELD name='SOH' doc='16#01#'/>
|
||
<FIELD name='STX' doc='16#02#'/>
|
||
<FIELD name='ETX' doc='16#03#'/>
|
||
<FIELD name='EOT' doc='16#04#'/>
|
||
<FIELD name='ENQ' doc='16#05#'/>
|
||
<FIELD name='ACK' doc='16#06#'/>
|
||
<FIELD name='BEL' doc='16#07#'/>
|
||
<FIELD name='BS' doc='16#08#'/>
|
||
<FIELD name='HT' doc='16#09#'/>
|
||
<FIELD name='LF' doc='16#0A#'/>
|
||
<FIELD name='VT' doc='16#0B#'/>
|
||
<FIELD name='FF' doc='16#0C#'/>
|
||
<FIELD name='CR' doc='16#0D#'/>
|
||
<FIELD name='SO' doc='16#0E#'/>
|
||
<FIELD name='SI' doc='16#0F#'/>
|
||
<FIELD name='DLE' doc='16#10#'/>
|
||
<FIELD name='DC1' doc='16#11#'/>
|
||
<FIELD name='DC2' doc='16#12#'/>
|
||
<FIELD name='DC3' doc='16#13#'/>
|
||
<FIELD name='DC4' doc='16#14#'/>
|
||
<FIELD name='NAK' doc='16#15#'/>
|
||
<FIELD name='SYN' doc='16#16#'/>
|
||
<FIELD name='ETB' doc='16#17#'/>
|
||
<FIELD name='CAN' doc='16#18#'/>
|
||
<FIELD name='EM' doc='16#19#'/>
|
||
<FIELD name='SUB' doc='16#1A#'/>
|
||
<FIELD name='ESC' doc='16#1B#'/>
|
||
<FIELD name='FS' doc='16#1C#'/>
|
||
<FIELD name='GS' doc='16#1D#'/>
|
||
<FIELD name='RS' doc='16#1E#'/>
|
||
<FIELD name='US' doc='16#1F#'/>
|
||
<FIELD name='Exclam' doc='16#21#'/>
|
||
<FIELD name='Quotation' doc='16#22#'/>
|
||
<FIELD name='Sharp' doc='16#23#'/>
|
||
<FIELD name='Dollar' doc='16#24#'/>
|
||
<FIELD name='Percent' doc='16#25#'/>
|
||
<FIELD name='Ampersand' doc='16#26#'/>
|
||
<FIELD name='Colon' doc='16#3A#'/>
|
||
<FIELD name='Semicolon' doc='16#3B#'/>
|
||
<FIELD name='Query' doc='16#3F#'/>
|
||
<FIELD name='At_Sign' doc='16#40#'/>
|
||
<FIELD name='L_Bracket' doc='16#5B#'/>
|
||
<FIELD name='Back_Slash' doc='16#5C#'/>
|
||
<FIELD name='R_Bracket' doc='16#5D#'/>
|
||
<FIELD name='Circumflex' doc='16#5E#'/>
|
||
<FIELD name='Underline' doc='16#5F#'/>
|
||
<FIELD name='Grave' doc='16#60#'/>
|
||
<FIELD name='LC_A' doc='16#61#'/>
|
||
<FIELD name='LC_B' doc='16#62#'/>
|
||
<FIELD name='LC_C' doc='16#63#'/>
|
||
<FIELD name='LC_D' doc='16#64#'/>
|
||
<FIELD name='LC_E' doc='16#65#'/>
|
||
<FIELD name='LC_F' doc='16#66#'/>
|
||
<FIELD name='LC_G' doc='16#67#'/>
|
||
<FIELD name='LC_H' doc='16#68#'/>
|
||
<FIELD name='LC_I' doc='16#69#'/>
|
||
<FIELD name='LC_J' doc='16#6A#'/>
|
||
<FIELD name='LC_K' doc='16#6B#'/>
|
||
<FIELD name='LC_L' doc='16#6C#'/>
|
||
<FIELD name='LC_M' doc='16#6D#'/>
|
||
<FIELD name='LC_N' doc='16#6E#'/>
|
||
<FIELD name='LC_O' doc='16#6F#'/>
|
||
<FIELD name='LC_P' doc='16#70#'/>
|
||
<FIELD name='LC_Q' doc='16#71#'/>
|
||
<FIELD name='LC_R' doc='16#72#'/>
|
||
<FIELD name='LC_S' doc='16#73#'/>
|
||
<FIELD name='LC_T' doc='16#74#'/>
|
||
<FIELD name='LC_U' doc='16#75#'/>
|
||
<FIELD name='LC_V' doc='16#76#'/>
|
||
<FIELD name='LC_W' doc='16#77#'/>
|
||
<FIELD name='LC_X' doc='16#78#'/>
|
||
<FIELD name='LC_Y' doc='16#79#'/>
|
||
<FIELD name='LC_Z' doc='16#7A#'/>
|
||
<FIELD name='L_BRACE' doc='16#7B#'/>
|
||
<FIELD name='BA' doc='16#7C#'/>
|
||
<FIELD name='R_BRACE' doc='16#7D#'/>
|
||
<FIELD name='TILDE' doc='16#7E#'/>
|
||
<FIELD name='DEL' doc='16#7F#'/></STANDARD>
|
||
<STANDARD name="Boolean" category="type"/>
|
||
<STANDARD name="Character" category="type"/>
|
||
<STANDARD name="Constraint_Error" category="variable"/>
|
||
<STANDARD name="Duration" category="type"/>
|
||
<STANDARD name="False" category="variable"/>
|
||
<STANDARD name="Float" category="type"/>
|
||
<STANDARD name="Integer" category="type"/>
|
||
<STANDARD name="Long_Float" category="type"/>
|
||
<STANDARD name="Long_Integer" category="type"/>
|
||
<STANDARD name="Long_Long_Float" category="type"/>
|
||
<STANDARD name="Long_Long_Integer" category="type"/>
|
||
<STANDARD name="Natural" category="type"/>
|
||
<STANDARD name="Numeric_Error" category="variable"/>
|
||
<STANDARD name="Positive" category="type"/>
|
||
<STANDARD name="Program_Error" category="variable"/>
|
||
<STANDARD name="Short_Float" category="type"/>
|
||
<STANDARD name="Short_Integer" category="type"/>
|
||
<STANDARD name="Short_Short_Integer" category="type"/>
|
||
<STANDARD name="Storage_Error" category="variable"/>
|
||
<STANDARD name="String" category="type"/>
|
||
<STANDARD name="Tasking_Error" category="variable"/>
|
||
<STANDARD name="True" category="variable"/>
|
||
<STANDARD name="Wide_Character" category="type"/>
|
||
<STANDARD name="Wide_String" category="type"/>
|
||
<STANDARD name="Wide_Wide_Character" category="type"/>
|
||
<STANDARD name="Wide_Wide_String" category="type"/>
|
||
</PREDEFINED_ADA>
|