3 .. _Implementation_Defined_Pragmas:
5 ******************************
6 Implementation Defined Pragmas
7 ******************************
9 Ada defines a set of pragmas that can be used to supply additional
10 information to the compiler. These language defined pragmas are
11 implemented in GNAT and work as described in the Ada Reference Manual.
13 In addition, Ada allows implementations to define additional pragmas
14 whose meaning is defined by the implementation. GNAT provides a number
15 of these implementation-defined pragmas, which can be used to extend
16 and enhance the functionality of the compiler. This section of the GNAT
17 Reference Manual describes these additional pragmas.
19 Note that any program using these pragmas might not be portable to other
20 compilers (although GNAT implements this set of pragmas on all
21 platforms). Therefore if portability to other compilers is an important
22 consideration, the use of these pragmas should be minimized.
27 .. index:: Deferring aborts
36 This pragma must appear at the start of the statement sequence of a
37 handled sequence of statements (right after the ``begin``). It has
38 the effect of deferring aborts for the sequence of statements (but not
39 for the declarations or handlers, if any, associated with this statement
42 .. _Pragma-Abstract_State:
51 pragma Abstract_State (ABSTRACT_STATE_LIST);
53 ABSTRACT_STATE_LIST ::=
55 | STATE_NAME_WITH_OPTIONS
56 | (STATE_NAME_WITH_OPTIONS {, STATE_NAME_WITH_OPTIONS} )
58 STATE_NAME_WITH_OPTIONS ::=
60 | (STATE_NAME with OPTION_LIST)
62 OPTION_LIST ::= OPTION {, OPTION}
68 SIMPLE_OPTION ::= Ghost | Synchronous
71 Part_Of => ABSTRACT_STATE
72 | External [=> EXTERNAL_PROPERTY_LIST]
74 EXTERNAL_PROPERTY_LIST ::=
76 | (EXTERNAL_PROPERTY {, EXTERNAL_PROPERTY} )
79 Async_Readers [=> boolean_EXPRESSION]
80 | Async_Writers [=> boolean_EXPRESSION]
81 | Effective_Reads [=> boolean_EXPRESSION]
82 | Effective_Writes [=> boolean_EXPRESSION]
83 others => boolean_EXPRESSION
85 STATE_NAME ::= defining_identifier
87 ABSTRACT_STATE ::= name
89 For the semantics of this pragma, see the entry for aspect ``Abstract_State`` in
90 the SPARK 2014 Reference Manual, section 7.1.4.
98 pragma Acc_Parallel [( ACC_PARALLEL_CLAUSE [, ACC_PARALLEL_CLAUSE... ])];
100 ACC_PARALLEL_CLAUSE ::=
101 Acc_If => boolean_EXPRESSION
102 | Acc_Private => IDENTIFIERS
103 | Async => integer_EXPRESSION
104 | Copy => IDENTIFIERS
105 | Copy_In => IDENTIFIERS
106 | Copy_Out => IDENTIFIERS
107 | Create => IDENTIFIERS
109 | Device_Ptr => IDENTIFIERS
110 | First_Private => IDENTIFIERS
111 | Num_Gangs => integer_EXPRESSION
112 | Num_Workers => integer_EXPRESSION
113 | Present => IDENTIFIERS
114 | Reduction => (REDUCTION_RECORD)
115 | Vector_Length => integer_EXPRESSION
121 | "min" => IDENTIFIERS
122 | "max" => IDENTIFIERS
123 | "or" => IDENTIFIERS
124 | "and" => IDENTIFIERS
128 | (IDENTIFIER, IDENTIFIERS)
132 | (integer_EXPRESSION, INTEGERS)
134 Requires the :switch:`-fopenacc` flag.
136 Equivalent to the ``parallel`` directive of the OpenAcc standard. This pragma
137 should be placed in loops. It offloads the content of the loop to an
140 For more information about the effect of the clauses, see the OpenAcc
149 pragma Acc_Loop [( ACC_LOOP_CLAUSE [, ACC_LOOP_CLAUSE... ])];
153 | Collapse => INTEGER_LITERAL
156 | Private => IDENTIFIERS
157 | Reduction => (REDUCTION_RECORD)
159 | Tile => SIZE_EXPRESSION
160 | Vector [=> integer_EXPRESSION]
161 | Worker [=> integer_EXPRESSION]
165 | Static => SIZE_EXPRESSION
171 Requires the :switch:`-fopenacc` flag.
173 Equivalent to the ``loop`` directive of the OpenAcc standard. This pragma
174 should be placed in for loops after the "Acc_Parallel" pragma. It tells the
175 compiler how to parallelize the loop.
177 For more information about the effect of the clauses, see the OpenAcc
186 pragma Acc_Kernels [( ACC_KERNELS_CLAUSE [, ACC_KERNELS_CLAUSE...])];
188 ACC_KERNELS_CLAUSE ::=
189 Acc_If => boolean_EXPRESSION
190 | Async => integer_EXPRESSION
191 | Copy => IDENTIFIERS
192 | Copy_In => IDENTIFIERS
193 | Copy_Out => IDENTIFIERS
194 | Create => IDENTIFIERS
196 | Device_Ptr => IDENTIFIERS
197 | Num_Gangs => integer_EXPRESSION
198 | Num_Workers => integer_EXPRESSION
199 | Present => IDENTIFIERS
200 | Vector_Length => integer_EXPRESSION
205 | (IDENTIFIER, IDENTIFIERS)
209 | (integer_EXPRESSION, INTEGERS)
211 Requires the :switch:`-fopenacc` flag.
213 Equivalent to the kernels directive of the OpenAcc standard. This pragma should
216 For more information about the effect of the clauses, see the OpenAcc
225 pragma Acc_Data ([ ACC_DATA_CLAUSE [, ACC_DATA_CLAUSE...]]);
229 | Copy_In => IDENTIFIERS
230 | Copy_Out => IDENTIFIERS
231 | Create => IDENTIFIERS
232 | Device_Ptr => IDENTIFIERS
233 | Present => IDENTIFIERS
235 Requires the :switch:`-fopenacc` flag.
237 Equivalent to the ``data`` directive of the OpenAcc standard. This pragma
238 should be placed in loops.
240 For more information about the effect of the clauses, see the OpenAcc
254 A configuration pragma that establishes Ada 83 mode for the unit to
255 which it applies, regardless of the mode set by the command line
256 switches. In Ada 83 mode, GNAT attempts to be as compatible with
257 the syntax and semantics of Ada 83, as defined in the original Ada
258 83 Reference Manual as possible. In particular, the keywords added by Ada 95
259 and Ada 2005 are not recognized, optional package bodies are allowed,
260 and generics may name types with unknown discriminants without using
261 the ``(<>)`` notation. In addition, some but not all of the additional
262 restrictions of Ada 83 are enforced.
264 Ada 83 mode is intended for two purposes. Firstly, it allows existing
265 Ada 83 code to be compiled and adapted to GNAT with less effort.
266 Secondly, it aids in keeping code backwards compatible with Ada 83.
267 However, there is no guarantee that code that is processed correctly
268 by GNAT in Ada 83 mode will in fact compile and execute with an Ada
269 83 compiler, since GNAT does not enforce all the additional checks
282 A configuration pragma that establishes Ada 95 mode for the unit to which
283 it applies, regardless of the mode set by the command line switches.
284 This mode is set automatically for the ``Ada`` and ``System``
285 packages and their children, so you need not specify it in these
286 contexts. This pragma is useful when writing a reusable component that
287 itself uses Ada 95 features, but which is intended to be usable from
288 either Ada 83 or Ada 95 programs.
298 pragma Ada_05 (local_NAME);
301 A configuration pragma that establishes Ada 2005 mode for the unit to which
302 it applies, regardless of the mode set by the command line switches.
303 This pragma is useful when writing a reusable component that
304 itself uses Ada 2005 features, but which is intended to be usable from
305 either Ada 83 or Ada 95 programs.
307 The one argument form (which is not a configuration pragma)
308 is used for managing the transition from
309 Ada 95 to Ada 2005 in the run-time library. If an entity is marked
310 as Ada_2005 only, then referencing the entity in Ada_83 or Ada_95
311 mode will generate a warning. In addition, in Ada_83 or Ada_95
312 mode, a preference rule is established which does not choose
313 such an entity unless it is unambiguously specified. This avoids
314 extra subprograms marked this way from generating ambiguities in
315 otherwise legal pre-Ada_2005 programs. The one argument form is
316 intended for exclusive use in the GNAT run-time library.
328 This configuration pragma is a synonym for pragma Ada_05 and has the
329 same syntax and effect.
339 pragma Ada_12 (local_NAME);
342 A configuration pragma that establishes Ada 2012 mode for the unit to which
343 it applies, regardless of the mode set by the command line switches.
344 This mode is set automatically for the ``Ada`` and ``System``
345 packages and their children, so you need not specify it in these
346 contexts. This pragma is useful when writing a reusable component that
347 itself uses Ada 2012 features, but which is intended to be usable from
348 Ada 83, Ada 95, or Ada 2005 programs.
350 The one argument form, which is not a configuration pragma,
351 is used for managing the transition from Ada
352 2005 to Ada 2012 in the run-time library. If an entity is marked
353 as Ada_2012 only, then referencing the entity in any pre-Ada_2012
354 mode will generate a warning. In addition, in any pre-Ada_2012
355 mode, a preference rule is established which does not choose
356 such an entity unless it is unambiguously specified. This avoids
357 extra subprograms marked this way from generating ambiguities in
358 otherwise legal pre-Ada_2012 programs. The one argument form is
359 intended for exclusive use in the GNAT run-time library.
371 This configuration pragma is a synonym for pragma Ada_12 and has the
372 same syntax and effect.
374 Pragma Allow_Integer_Address
375 ============================
381 pragma Allow_Integer_Address;
384 In almost all versions of GNAT, ``System.Address`` is a private
385 type in accordance with the implementation advice in the RM. This
386 means that integer values,
387 in particular integer literals, are not allowed as address values.
388 If the configuration pragma
389 ``Allow_Integer_Address`` is given, then integer expressions may
390 be used anywhere a value of type ``System.Address`` is required.
391 The effect is to introduce an implicit unchecked conversion from the
392 integer value to type ``System.Address``. The reverse case of using
393 an address where an integer type is required is handled analogously.
394 The following example compiles without errors:
399 pragma Allow_Integer_Address;
400 with System; use System;
404 for X'Address use 16#1240#;
405 for Y use at 16#3230#;
406 m : Address := 16#4000#;
407 n : constant Address := 4000;
408 p : constant Address := Address (X + Y);
409 v : Integer := y'Address;
410 w : constant Integer := Integer (Y'Address);
411 type R is new integer;
414 for Z'Address use RR;
418 Note that pragma ``Allow_Integer_Address`` is ignored if ``System.Address``
419 is not a private type. In implementations of ``GNAT`` where
420 System.Address is a visible integer type,
421 this pragma serves no purpose but is ignored
422 rather than rejected to allow common sets of sources to be used
423 in the two situations.
432 pragma Annotate (IDENTIFIER [, IDENTIFIER {, ARG}] [, entity => local_NAME]);
434 ARG ::= NAME | EXPRESSION
437 This pragma is used to annotate programs. IDENTIFIER identifies
438 the type of annotation. GNAT verifies that it is an identifier, but does
439 not otherwise analyze it. The second optional identifier is also left
440 unanalyzed, and by convention is used to control the action of the tool to
441 which the annotation is addressed. The remaining ARG arguments
442 can be either string literals or more generally expressions.
443 String literals are assumed to be either of type
444 ``Standard.String`` or else ``Wide_String`` or ``Wide_Wide_String``
445 depending on the character literals they contain.
446 All other kinds of arguments are analyzed as expressions, and must be
447 unambiguous. The last argument if present must have the identifier
448 ``Entity`` and GNAT verifies that a local name is given.
450 The analyzed pragma is retained in the tree, but not otherwise processed
451 by any part of the GNAT compiler, except to generate corresponding note
452 lines in the generated ALI file. For the format of these note lines, see
453 the compiler source file lib-writ.ads. This pragma is intended for use by
454 external tools, including ASIS. The use of pragma Annotate does not
455 affect the compilation process in any way. This pragma may be used as
456 a configuration pragma.
465 [, string_EXPRESSION]);
468 The effect of this pragma depends on whether the corresponding command
469 line switch is set to activate assertions. The pragma expands into code
470 equivalent to the following:
474 if assertions-enabled then
475 if not boolean_EXPRESSION then
476 System.Assertions.Raise_Assert_Failure
482 The string argument, if given, is the message that will be associated
483 with the exception occurrence if the exception is raised. If no second
484 argument is given, the default message is ``file``:``nnn``,
485 where ``file`` is the name of the source file containing the assert,
486 and ``nnn`` is the line number of the assert.
488 Note that, as with the ``if`` statement to which it is equivalent, the
489 type of the expression is either ``Standard.Boolean``, or any type derived
490 from this standard type.
492 Assert checks can be either checked or ignored. By default they are ignored.
493 They will be checked if either the command line switch *-gnata* is
494 used, or if an ``Assertion_Policy`` or ``Check_Policy`` pragma is used
495 to enable ``Assert_Checks``.
497 If assertions are ignored, then there
498 is no run-time effect (and in particular, any side effects from the
499 expression will not occur at run time). (The expression is still
500 analyzed at compile time, and may cause types to be frozen if they are
501 mentioned here for the first time).
503 If assertions are checked, then the given expression is tested, and if
504 it is ``False`` then ``System.Assertions.Raise_Assert_Failure`` is called
505 which results in the raising of ``Assert_Failure`` with the given message.
507 You should generally avoid side effects in the expression arguments of
508 this pragma, because these side effects will turn on and off with the
509 setting of the assertions mode, resulting in assertions that have an
510 effect on the program. However, the expressions are analyzed for
511 semantic correctness whether or not assertions are enabled, so turning
512 assertions on and off cannot affect the legality of a program.
514 Note that the implementation defined policy ``DISABLE``, given in a
515 pragma ``Assertion_Policy``, can be used to suppress this semantic analysis.
517 Note: this is a standard language-defined pragma in versions
518 of Ada from 2005 on. In GNAT, it is implemented in all versions
519 of Ada, and the DISABLE policy is an implementation-defined
522 Pragma Assert_And_Cut
523 =====================
527 pragma Assert_And_Cut (
529 [, string_EXPRESSION]);
532 The effect of this pragma is identical to that of pragma ``Assert``,
533 except that in an ``Assertion_Policy`` pragma, the identifier
534 ``Assert_And_Cut`` is used to control whether it is ignored or checked
537 The intention is that this be used within a subprogram when the
538 given test expresion sums up all the work done so far in the
539 subprogram, so that the rest of the subprogram can be verified
540 (informally or formally) using only the entry preconditions,
541 and the expression in this pragma. This allows dividing up
542 a subprogram into sections for the purposes of testing or
543 formal verification. The pragma also serves as useful
546 Pragma Assertion_Policy
547 =======================
551 pragma Assertion_Policy (CHECK | DISABLE | IGNORE | SUPPRESSIBLE);
553 pragma Assertion_Policy (
554 ASSERTION_KIND => POLICY_IDENTIFIER
555 {, ASSERTION_KIND => POLICY_IDENTIFIER});
557 ASSERTION_KIND ::= RM_ASSERTION_KIND | ID_ASSERTION_KIND
559 RM_ASSERTION_KIND ::= Assert |
569 ID_ASSERTION_KIND ::= Assertions |
585 POLICY_IDENTIFIER ::= Check | Disable | Ignore | Suppressible
588 This is a standard Ada 2012 pragma that is available as an
589 implementation-defined pragma in earlier versions of Ada.
590 The assertion kinds ``RM_ASSERTION_KIND`` are those defined in
591 the Ada standard. The assertion kinds ``ID_ASSERTION_KIND``
592 are implementation defined additions recognized by the GNAT compiler.
594 The pragma applies in both cases to pragmas and aspects with matching
595 names, e.g. ``Pre`` applies to the Pre aspect, and ``Precondition``
596 applies to both the ``Precondition`` pragma
597 and the aspect ``Precondition``. Note that the identifiers for
598 pragmas Pre_Class and Post_Class are Pre'Class and Post'Class (not
599 Pre_Class and Post_Class), since these pragmas are intended to be
600 identical to the corresponding aspects).
602 If the policy is ``CHECK``, then assertions are enabled, i.e.
603 the corresponding pragma or aspect is activated.
604 If the policy is ``IGNORE``, then assertions are ignored, i.e.
605 the corresponding pragma or aspect is deactivated.
606 This pragma overrides the effect of the *-gnata* switch on the
608 If the policy is ``SUPPRESSIBLE``, then assertions are enabled by default,
609 however, if the *-gnatp* switch is specified all assertions are ignored.
611 The implementation defined policy ``DISABLE`` is like
612 ``IGNORE`` except that it completely disables semantic
613 checking of the corresponding pragma or aspect. This is
614 useful when the pragma or aspect argument references subprograms
615 in a with'ed package which is replaced by a dummy package
618 The implementation defined assertion kind ``Assertions`` applies to all
619 assertion kinds. The form with no assertion kind given implies this
620 choice, so it applies to all assertion kinds (RM defined, and
621 implementation defined).
623 The implementation defined assertion kind ``Statement_Assertions``
624 applies to ``Assert``, ``Assert_And_Cut``,
625 ``Assume``, ``Loop_Invariant``, and ``Loop_Variant``.
636 [, string_EXPRESSION]);
639 The effect of this pragma is identical to that of pragma ``Assert``,
640 except that in an ``Assertion_Policy`` pragma, the identifier
641 ``Assume`` is used to control whether it is ignored or checked
644 The intention is that this be used for assumptions about the
645 external environment. So you cannot expect to verify formally
646 or informally that the condition is met, this must be
647 established by examining things outside the program itself.
648 For example, we may have code that depends on the size of
649 ``Long_Long_Integer`` being at least 64. So we could write:
653 pragma Assume (Long_Long_Integer'Size >= 64);
656 This assumption cannot be proved from the program itself,
657 but it acts as a useful run-time check that the assumption
658 is met, and documents the need to ensure that it is met by
659 reference to information outside the program.
661 Pragma Assume_No_Invalid_Values
662 ===============================
663 .. index:: Invalid representations
665 .. index:: Invalid values
671 pragma Assume_No_Invalid_Values (On | Off);
674 This is a configuration pragma that controls the assumptions made by the
675 compiler about the occurrence of invalid representations (invalid values)
678 The default behavior (corresponding to an Off argument for this pragma), is
679 to assume that values may in general be invalid unless the compiler can
680 prove they are valid. Consider the following example:
684 V1 : Integer range 1 .. 10;
685 V2 : Integer range 11 .. 20;
687 for J in V2 .. V1 loop
692 if V1 and V2 have valid values, then the loop is known at compile
693 time not to execute since the lower bound must be greater than the
694 upper bound. However in default mode, no such assumption is made,
695 and the loop may execute. If ``Assume_No_Invalid_Values (On)``
696 is given, the compiler will assume that any occurrence of a variable
697 other than in an explicit ``'Valid`` test always has a valid
698 value, and the loop above will be optimized away.
700 The use of ``Assume_No_Invalid_Values (On)`` is appropriate if
701 you know your code is free of uninitialized variables and other
702 possible sources of invalid representations, and may result in
703 more efficient code. A program that accesses an invalid representation
704 with this pragma in effect is erroneous, so no guarantees can be made
707 It is peculiar though permissible to use this pragma in conjunction
708 with validity checking (-gnatVa). In such cases, accessing invalid
709 values will generally give an exception, though formally the program
710 is erroneous so there are no guarantees that this will always be the
711 case, and it is recommended that these two options not be used together.
713 .. _Pragma-Async_Readers:
722 pragma Async_Readers [ (boolean_EXPRESSION) ];
724 For the semantics of this pragma, see the entry for aspect ``Async_Readers`` in
725 the SPARK 2014 Reference Manual, section 7.1.2.
727 .. _Pragma-Async_Writers:
736 pragma Async_Writers [ (boolean_EXPRESSION) ];
738 For the semantics of this pragma, see the entry for aspect ``Async_Writers`` in
739 the SPARK 2014 Reference Manual, section 7.1.2.
741 Pragma Attribute_Definition
742 ===========================
748 pragma Attribute_Definition
749 ([Attribute =>] ATTRIBUTE_DESIGNATOR,
750 [Entity =>] LOCAL_NAME,
751 [Expression =>] EXPRESSION | NAME);
754 If ``Attribute`` is a known attribute name, this pragma is equivalent to
755 the attribute definition clause:
760 for Entity'Attribute use Expression;
763 If ``Attribute`` is not a recognized attribute name, the pragma is
764 ignored, and a warning is emitted. This allows source
765 code to be written that takes advantage of some new attribute, while remaining
766 compilable with earlier compilers.
768 Pragma C_Pass_By_Copy
769 =====================
770 .. index:: Passing by copy
777 pragma C_Pass_By_Copy
778 ([Max_Size =>] static_integer_EXPRESSION);
781 Normally the default mechanism for passing C convention records to C
782 convention subprograms is to pass them by reference, as suggested by RM
783 B.3(69). Use the configuration pragma ``C_Pass_By_Copy`` to change
784 this default, by requiring that record formal parameters be passed by
785 copy if all of the following conditions are met:
788 The size of the record type does not exceed the value specified for
791 The record type has ``Convention C``.
793 The formal parameter has this record type, and the subprogram has a
794 foreign (non-Ada) convention.
796 If these conditions are met the argument is passed by copy; i.e., in a
797 manner consistent with what C expects if the corresponding formal in the
798 C prototype is a struct (rather than a pointer to a struct).
800 You can also pass records by copy by specifying the convention
801 ``C_Pass_By_Copy`` for the record type, or by using the extended
802 ``Import`` and ``Export`` pragmas, which allow specification of
803 passing mechanisms on a parameter by parameter basis.
807 .. index:: Assertions
809 .. index:: Named assertions
817 [Name =>] CHECK_KIND,
818 [Check =>] Boolean_EXPRESSION
819 [, [Message =>] string_EXPRESSION] );
821 CHECK_KIND ::= IDENTIFIER |
824 Type_Invariant'Class |
828 This pragma is similar to the predefined pragma ``Assert`` except that an
829 extra identifier argument is present. In conjunction with pragma
830 ``Check_Policy``, this can be used to define groups of assertions that can
831 be independently controlled. The identifier ``Assertion`` is special, it
832 refers to the normal set of pragma ``Assert`` statements.
834 Checks introduced by this pragma are normally deactivated by default. They can
835 be activated either by the command line option *-gnata*, which turns on
836 all checks, or individually controlled using pragma ``Check_Policy``.
838 The identifiers ``Assertions`` and ``Statement_Assertions`` are not
839 permitted as check kinds, since this would cause confusion with the use
840 of these identifiers in ``Assertion_Policy`` and ``Check_Policy``
841 pragmas, where they are used to refer to sets of assertions.
843 Pragma Check_Float_Overflow
844 ===========================
845 .. index:: Floating-point overflow
852 pragma Check_Float_Overflow;
855 In Ada, the predefined floating-point types (``Short_Float``,
856 ``Float``, ``Long_Float``, ``Long_Long_Float``) are
857 defined to be *unconstrained*. This means that even though each
858 has a well-defined base range, an operation that delivers a result
859 outside this base range is not required to raise an exception.
860 This implementation permission accommodates the notion
861 of infinities in IEEE floating-point, and corresponds to the
862 efficient execution mode on most machines. GNAT will not raise
863 overflow exceptions on these machines; instead it will generate
864 infinities and NaN's as defined in the IEEE standard.
866 Generating infinities, although efficient, is not always desirable.
867 Often the preferable approach is to check for overflow, even at the
868 (perhaps considerable) expense of run-time performance.
869 This can be accomplished by defining your own constrained floating-point subtypes -- i.e., by supplying explicit
870 range constraints -- and indeed such a subtype
871 can have the same base range as its base type. For example:
876 subtype My_Float is Float range Float'Range;
879 Here ``My_Float`` has the same range as
880 ``Float`` but is constrained, so operations on
881 ``My_Float`` values will be checked for overflow
884 This style will achieve the desired goal, but
885 it is often more convenient to be able to simply use
886 the standard predefined floating-point types as long
887 as overflow checking could be guaranteed.
888 The ``Check_Float_Overflow``
889 configuration pragma achieves this effect. If a unit is compiled
890 subject to this configuration pragma, then all operations
891 on predefined floating-point types including operations on
892 base types of these floating-point types will be treated as
893 though those types were constrained, and overflow checks
894 will be generated. The ``Constraint_Error``
895 exception is raised if the result is out of range.
897 This mode can also be set by use of the compiler
902 .. index:: Defining check names
904 .. index:: Check names, defining
911 pragma Check_Name (check_name_IDENTIFIER);
914 This is a configuration pragma that defines a new implementation
915 defined check name (unless IDENTIFIER matches one of the predefined
916 check names, in which case the pragma has no effect). Check names
917 are global to a partition, so if two or more configuration pragmas
918 are present in a partition mentioning the same name, only one new
919 check name is introduced.
921 An implementation defined check name introduced with this pragma may
922 be used in only three contexts: ``pragma Suppress``,
923 ``pragma Unsuppress``,
924 and as the prefix of a ``Check_Name'Enabled`` attribute reference. For
925 any of these three cases, the check name must be visible. A check
926 name is visible if it is in the configuration pragmas applying to
927 the current unit, or if it appears at the start of any unit that
928 is part of the dependency set of the current unit (e.g., units that
929 are mentioned in ``with`` clauses).
931 Check names introduced by this pragma are subject to control by compiler
932 switches (in particular -gnatp) in the usual manner.
936 .. index:: Controlling assertions
938 .. index:: Assertions, control
940 .. index:: Check pragma control
942 .. index:: Named assertions
950 ([Name =>] CHECK_KIND,
951 [Policy =>] POLICY_IDENTIFIER);
953 pragma Check_Policy (
954 CHECK_KIND => POLICY_IDENTIFIER
955 {, CHECK_KIND => POLICY_IDENTIFIER});
957 ASSERTION_KIND ::= RM_ASSERTION_KIND | ID_ASSERTION_KIND
959 CHECK_KIND ::= IDENTIFIER |
962 Type_Invariant'Class |
965 The identifiers Name and Policy are not allowed as CHECK_KIND values. This
966 avoids confusion between the two possible syntax forms for this pragma.
968 POLICY_IDENTIFIER ::= ON | OFF | CHECK | DISABLE | IGNORE
971 This pragma is used to set the checking policy for assertions (specified
972 by aspects or pragmas), the ``Debug`` pragma, or additional checks
973 to be checked using the ``Check`` pragma. It may appear either as
974 a configuration pragma, or within a declarative part of package. In the
975 latter case, it applies from the point where it appears to the end of
976 the declarative region (like pragma ``Suppress``).
978 The ``Check_Policy`` pragma is similar to the
979 predefined ``Assertion_Policy`` pragma,
980 and if the check kind corresponds to one of the assertion kinds that
981 are allowed by ``Assertion_Policy``, then the effect is identical.
983 If the first argument is Debug, then the policy applies to Debug pragmas,
984 disabling their effect if the policy is ``OFF``, ``DISABLE``, or
985 ``IGNORE``, and allowing them to execute with normal semantics if
986 the policy is ``ON`` or ``CHECK``. In addition if the policy is
987 ``DISABLE``, then the procedure call in ``Debug`` pragmas will
988 be totally ignored and not analyzed semantically.
990 Finally the first argument may be some other identifier than the above
991 possibilities, in which case it controls a set of named assertions
992 that can be checked using pragma ``Check``. For example, if the pragma:
997 pragma Check_Policy (Critical_Error, OFF);
1000 is given, then subsequent ``Check`` pragmas whose first argument is also
1001 ``Critical_Error`` will be disabled.
1003 The check policy is ``OFF`` to turn off corresponding checks, and ``ON``
1004 to turn on corresponding checks. The default for a set of checks for which no
1005 ``Check_Policy`` is given is ``OFF`` unless the compiler switch
1006 *-gnata* is given, which turns on all checks by default.
1008 The check policy settings ``CHECK`` and ``IGNORE`` are recognized
1009 as synonyms for ``ON`` and ``OFF``. These synonyms are provided for
1010 compatibility with the standard ``Assertion_Policy`` pragma. The check
1011 policy setting ``DISABLE`` causes the second argument of a corresponding
1012 ``Check`` pragma to be completely ignored and not analyzed.
1022 pragma Comment (static_string_EXPRESSION);
1025 This is almost identical in effect to pragma ``Ident``. It allows the
1026 placement of a comment into the object file and hence into the
1027 executable file if the operating system permits such usage. The
1028 difference is that ``Comment``, unlike ``Ident``, has
1029 no limitations on placement of the pragma (it can be placed
1030 anywhere in the main source unit), and if more than one pragma
1031 is used, all comments are retained.
1033 Pragma Common_Object
1034 ====================
1041 pragma Common_Object (
1042 [Internal =>] LOCAL_NAME
1043 [, [External =>] EXTERNAL_SYMBOL]
1044 [, [Size =>] EXTERNAL_SYMBOL] );
1048 | static_string_EXPRESSION
1051 This pragma enables the shared use of variables stored in overlaid
1052 linker areas corresponding to the use of ``COMMON``
1053 in Fortran. The single
1054 object ``LOCAL_NAME`` is assigned to the area designated by
1055 the ``External`` argument.
1056 You may define a record to correspond to a series
1057 of fields. The ``Size`` argument
1058 is syntax checked in GNAT, but otherwise ignored.
1060 ``Common_Object`` is not supported on all platforms. If no
1061 support is available, then the code generator will issue a message
1062 indicating that the necessary attribute for implementation of this
1063 pragma is not available.
1065 Pragma Compile_Time_Error
1066 =========================
1073 pragma Compile_Time_Error
1074 (boolean_EXPRESSION, static_string_EXPRESSION);
1077 This pragma can be used to generate additional compile time
1079 is particularly useful in generics, where errors can be issued for
1080 specific problematic instantiations. The first parameter is a boolean
1081 expression. The pragma is effective only if the value of this expression
1082 is known at compile time, and has the value True. The set of expressions
1083 whose values are known at compile time includes all static boolean
1084 expressions, and also other values which the compiler can determine
1085 at compile time (e.g., the size of a record type set by an explicit
1086 size representation clause, or the value of a variable which was
1087 initialized to a constant and is known not to have been modified).
1088 If these conditions are met, an error message is generated using
1089 the value given as the second argument. This string value may contain
1090 embedded ASCII.LF characters to break the message into multiple lines.
1092 Pragma Compile_Time_Warning
1093 ===========================
1100 pragma Compile_Time_Warning
1101 (boolean_EXPRESSION, static_string_EXPRESSION);
1104 Same as pragma Compile_Time_Error, except a warning is issued instead
1105 of an error message. Note that if this pragma is used in a package that
1106 is with'ed by a client, the client will get the warning even though it
1107 is issued by a with'ed package (normally warnings in with'ed units are
1108 suppressed, but this is a special exception to that rule).
1110 One typical use is within a generic where compile time known characteristics
1111 of formal parameters are tested, and warnings given appropriately. Another use
1112 with a first parameter of True is to warn a client about use of a package,
1113 for example that it is not fully implemented.
1115 Pragma Compiler_Unit
1116 ====================
1123 pragma Compiler_Unit;
1126 This pragma is obsolete. It is equivalent to Compiler_Unit_Warning. It is
1127 retained so that old versions of the GNAT run-time that use this pragma can
1128 be compiled with newer versions of the compiler.
1130 Pragma Compiler_Unit_Warning
1131 ============================
1138 pragma Compiler_Unit_Warning;
1141 This pragma is intended only for internal use in the GNAT run-time library.
1142 It indicates that the unit is used as part of the compiler build. The effect
1143 is to generate warnings for the use of constructs (for example, conditional
1144 expressions) that would cause trouble when bootstrapping using an older
1145 version of GNAT. For the exact list of restrictions, see the compiler sources
1146 and references to Check_Compiler_Unit.
1148 Pragma Complete_Representation
1149 ==============================
1156 pragma Complete_Representation;
1159 This pragma must appear immediately within a record representation
1160 clause. Typical placements are before the first component clause
1161 or after the last component clause. The effect is to give an error
1162 message if any component is missing a component clause. This pragma
1163 may be used to ensure that a record representation clause is
1164 complete, and that this invariant is maintained if fields are
1165 added to the record in the future.
1167 Pragma Complex_Representation
1168 =============================
1175 pragma Complex_Representation
1176 ([Entity =>] LOCAL_NAME);
1179 The ``Entity`` argument must be the name of a record type which has
1180 two fields of the same floating-point type. The effect of this pragma is
1181 to force gcc to use the special internal complex representation form for
1182 this record, which may be more efficient. Note that this may result in
1183 the code for this type not conforming to standard ABI (application
1184 binary interface) requirements for the handling of record types. For
1185 example, in some environments, there is a requirement for passing
1186 records by pointer, and the use of this pragma may result in passing
1187 this type in floating-point registers.
1189 Pragma Component_Alignment
1190 ==========================
1191 .. index:: Alignments of components
1192 .. index:: Pragma Component_Alignment
1199 pragma Component_Alignment (
1200 [Form =>] ALIGNMENT_CHOICE
1201 [, [Name =>] type_LOCAL_NAME]);
1203 ALIGNMENT_CHOICE ::=
1210 Specifies the alignment of components in array or record types.
1211 The meaning of the ``Form`` argument is as follows:
1214 .. index:: Component_Size (in pragma Component_Alignment)
1217 Aligns scalar components and subcomponents of the array or record type
1218 on boundaries appropriate to their inherent size (naturally
1219 aligned). For example, 1-byte components are aligned on byte boundaries,
1220 2-byte integer components are aligned on 2-byte boundaries, 4-byte
1221 integer components are aligned on 4-byte boundaries and so on. These
1222 alignment rules correspond to the normal rules for C compilers on all
1223 machines except the VAX.
1225 .. index:: Component_Size_4 (in pragma Component_Alignment)
1228 Naturally aligns components with a size of four or fewer
1229 bytes. Components that are larger than 4 bytes are placed on the next
1232 .. index:: Storage_Unit (in pragma Component_Alignment)
1235 Specifies that array or record components are byte aligned, i.e.,
1236 aligned on boundaries determined by the value of the constant
1237 ``System.Storage_Unit``.
1239 .. index:: Default (in pragma Component_Alignment)
1242 Specifies that array or record components are aligned on default
1243 boundaries, appropriate to the underlying hardware or operating system or
1244 both. The ``Default`` choice is the same as ``Component_Size`` (natural
1247 If the ``Name`` parameter is present, ``type_LOCAL_NAME`` must
1248 refer to a local record or array type, and the specified alignment
1249 choice applies to the specified type. The use of
1250 ``Component_Alignment`` together with a pragma ``Pack`` causes the
1251 ``Component_Alignment`` pragma to be ignored. The use of
1252 ``Component_Alignment`` together with a record representation clause
1253 is only effective for fields not specified by the representation clause.
1255 If the ``Name`` parameter is absent, the pragma can be used as either
1256 a configuration pragma, in which case it applies to one or more units in
1257 accordance with the normal rules for configuration pragmas, or it can be
1258 used within a declarative part, in which case it applies to types that
1259 are declared within this declarative part, or within any nested scope
1260 within this declarative part. In either case it specifies the alignment
1261 to be applied to any record or array type which has otherwise standard
1264 If the alignment for a record or array type is not specified (using
1265 pragma ``Pack``, pragma ``Component_Alignment``, or a record rep
1266 clause), the GNAT uses the default alignment as described previously.
1268 .. _Pragma-Constant_After_Elaboration:
1270 Pragma Constant_After_Elaboration
1271 =================================
1277 pragma Constant_After_Elaboration [ (boolean_EXPRESSION) ];
1279 For the semantics of this pragma, see the entry for aspect
1280 ``Constant_After_Elaboration`` in the SPARK 2014 Reference Manual, section 3.3.1.
1282 .. _Pragma-Contract_Cases:
1284 Pragma Contract_Cases
1285 =====================
1286 .. index:: Contract cases
1292 pragma Contract_Cases ((CONTRACT_CASE {, CONTRACT_CASE));
1294 CONTRACT_CASE ::= CASE_GUARD => CONSEQUENCE
1296 CASE_GUARD ::= boolean_EXPRESSION | others
1298 CONSEQUENCE ::= boolean_EXPRESSION
1300 The ``Contract_Cases`` pragma allows defining fine-grain specifications
1301 that can complement or replace the contract given by a precondition and a
1302 postcondition. Additionally, the ``Contract_Cases`` pragma can be used
1303 by testing and formal verification tools. The compiler checks its validity and,
1304 depending on the assertion policy at the point of declaration of the pragma,
1305 it may insert a check in the executable. For code generation, the contract
1311 pragma Contract_Cases (
1321 C1 : constant Boolean := Cond1; -- evaluated at subprogram entry
1322 C2 : constant Boolean := Cond2; -- evaluated at subprogram entry
1323 pragma Precondition ((C1 and not C2) or (C2 and not C1));
1324 pragma Postcondition (if C1 then Pred1);
1325 pragma Postcondition (if C2 then Pred2);
1328 The precondition ensures that one and only one of the case guards is
1329 satisfied on entry to the subprogram.
1330 The postcondition ensures that for the case guard that was True on entry,
1331 the corrresponding consequence is True on exit. Other consequence expressions
1334 A precondition ``P`` and postcondition ``Q`` can also be
1335 expressed as contract cases:
1339 pragma Contract_Cases (P => Q);
1342 The placement and visibility rules for ``Contract_Cases`` pragmas are
1343 identical to those described for preconditions and postconditions.
1345 The compiler checks that boolean expressions given in case guards and
1346 consequences are valid, where the rules for case guards are the same as
1347 the rule for an expression in ``Precondition`` and the rules for
1348 consequences are the same as the rule for an expression in
1349 ``Postcondition``. In particular, attributes ``'Old`` and
1350 ``'Result`` can only be used within consequence expressions.
1351 The case guard for the last contract case may be ``others``, to denote
1352 any case not captured by the previous cases. The
1353 following is an example of use within a package spec:
1358 package Math_Functions is
1360 function Sqrt (Arg : Float) return Float;
1361 pragma Contract_Cases (((Arg in 0.0 .. 99.0) => Sqrt'Result < 10.0,
1362 Arg >= 100.0 => Sqrt'Result >= 10.0,
1363 others => Sqrt'Result = 0.0));
1368 The meaning of contract cases is that only one case should apply at each
1369 call, as determined by the corresponding case guard evaluating to True,
1370 and that the consequence for this case should hold when the subprogram
1373 Pragma Convention_Identifier
1374 ============================
1375 .. index:: Conventions, synonyms
1382 pragma Convention_Identifier (
1383 [Name =>] IDENTIFIER,
1384 [Convention =>] convention_IDENTIFIER);
1387 This pragma provides a mechanism for supplying synonyms for existing
1388 convention identifiers. The ``Name`` identifier can subsequently
1389 be used as a synonym for the given convention in other pragmas (including
1390 for example pragma ``Import`` or another ``Convention_Identifier``
1391 pragma). As an example of the use of this, suppose you had legacy code
1392 which used Fortran77 as the identifier for Fortran. Then the pragma:
1397 pragma Convention_Identifier (Fortran77, Fortran);
1400 would allow the use of the convention identifier ``Fortran77`` in
1401 subsequent code, avoiding the need to modify the sources. As another
1402 example, you could use this to parameterize convention requirements
1403 according to systems. Suppose you needed to use ``Stdcall`` on
1404 windows systems, and ``C`` on some other system, then you could
1405 define a convention identifier ``Library`` and use a single
1406 ``Convention_Identifier`` pragma to specify which convention
1407 would be used system-wide.
1411 .. index:: Interfacing with C++
1418 pragma CPP_Class ([Entity =>] LOCAL_NAME);
1421 The argument denotes an entity in the current declarative region that is
1422 declared as a record type. It indicates that the type corresponds to an
1423 externally declared C++ class type, and is to be laid out the same way
1424 that C++ would lay out the type. If the C++ class has virtual primitives
1425 then the record must be declared as a tagged record type.
1427 Types for which ``CPP_Class`` is specified do not have assignment or
1428 equality operators defined (such operations can be imported or declared
1429 as subprograms as required). Initialization is allowed only by constructor
1430 functions (see pragma ``CPP_Constructor``). Such types are implicitly
1431 limited if not explicitly declared as limited or derived from a limited
1432 type, and an error is issued in that case.
1434 See :ref:`Interfacing_to_C++` for related information.
1436 Note: Pragma ``CPP_Class`` is currently obsolete. It is supported
1437 for backward compatibility but its functionality is available
1438 using pragma ``Import`` with ``Convention`` = ``CPP``.
1440 Pragma CPP_Constructor
1441 ======================
1442 .. index:: Interfacing with C++
1450 pragma CPP_Constructor ([Entity =>] LOCAL_NAME
1451 [, [External_Name =>] static_string_EXPRESSION ]
1452 [, [Link_Name =>] static_string_EXPRESSION ]);
1455 This pragma identifies an imported function (imported in the usual way
1456 with pragma ``Import``) as corresponding to a C++ constructor. If
1457 ``External_Name`` and ``Link_Name`` are not specified then the
1458 ``Entity`` argument is a name that must have been previously mentioned
1459 in a pragma ``Import`` with ``Convention`` = ``CPP``. Such name
1460 must be of one of the following forms:
1463 **function** ``Fname`` **return** T`
1466 **function** ``Fname`` **return** T'Class
1469 **function** ``Fname`` (...) **return** T`
1472 **function** ``Fname`` (...) **return** T'Class
1474 where ``T`` is a limited record type imported from C++ with pragma
1475 ``Import`` and ``Convention`` = ``CPP``.
1477 The first two forms import the default constructor, used when an object
1478 of type ``T`` is created on the Ada side with no explicit constructor.
1479 The latter two forms cover all the non-default constructors of the type.
1480 See the GNAT User's Guide for details.
1482 If no constructors are imported, it is impossible to create any objects
1483 on the Ada side and the type is implicitly declared abstract.
1485 Pragma ``CPP_Constructor`` is intended primarily for automatic generation
1486 using an automatic binding generator tool (such as the :switch:`-fdump-ada-spec`
1488 See :ref:`Interfacing_to_C++` for more related information.
1490 Note: The use of functions returning class-wide types for constructors is
1491 currently obsolete. They are supported for backward compatibility. The
1492 use of functions returning the type T leave the Ada sources more clear
1493 because the imported C++ constructors always return an object of type T;
1494 that is, they never return an object whose type is a descendant of type T.
1498 .. index:: Interfacing to C++
1501 This pragma is now obsolete and, other than generating a warning if warnings
1502 on obsolescent features are enabled, is completely ignored.
1503 It is retained for compatibility
1504 purposes. It used to be required to ensure compoatibility with C++, but
1505 is no longer required for that purpose because GNAT generates
1506 the same object layout as the G++ compiler by default.
1508 See :ref:`Interfacing_to_C++` for related information.
1512 .. index:: Interfacing with C++
1515 This pragma is now obsolete and, other than generating a warning if warnings
1516 on obsolescent features are enabled, is completely ignored.
1517 It used to be required to ensure compatibility with C++, but
1518 is no longer required for that purpose because GNAT generates
1519 the same object layout as the G++ compiler by default.
1521 See :ref:`Interfacing_to_C++` for related information.
1531 pragma CPU (EXPRESSION);
1534 This pragma is standard in Ada 2012, but is available in all earlier
1535 versions of Ada as an implementation-defined pragma.
1536 See Ada 2012 Reference Manual for details.
1538 Pragma Deadline_Floor
1539 =====================
1546 pragma Deadline_Floor (time_span_EXPRESSION);
1549 This pragma applies only to protected types and specifies the floor
1550 deadline inherited by a task when the task enters a protected object.
1551 It is effective only when the EDF scheduling policy is used.
1553 .. _Pragma-Default_Initial_Condition:
1555 Pragma Default_Initial_Condition
1556 ================================
1562 pragma Default_Initial_Condition [ (null | boolean_EXPRESSION) ];
1564 For the semantics of this pragma, see the entry for aspect
1565 ``Default_Initial_Condition`` in the SPARK 2014 Reference Manual, section 7.3.3.
1575 pragma Debug ([CONDITION, ]PROCEDURE_CALL_WITHOUT_SEMICOLON);
1577 PROCEDURE_CALL_WITHOUT_SEMICOLON ::=
1579 | PROCEDURE_PREFIX ACTUAL_PARAMETER_PART
1582 The procedure call argument has the syntactic form of an expression, meeting
1583 the syntactic requirements for pragmas.
1585 If debug pragmas are not enabled or if the condition is present and evaluates
1586 to False, this pragma has no effect. If debug pragmas are enabled, the
1587 semantics of the pragma is exactly equivalent to the procedure call statement
1588 corresponding to the argument with a terminating semicolon. Pragmas are
1589 permitted in sequences of declarations, so you can use pragma ``Debug`` to
1590 intersperse calls to debug procedures in the middle of declarations. Debug
1591 pragmas can be enabled either by use of the command line switch *-gnata*
1592 or by use of the pragma ``Check_Policy`` with a first argument of
1603 pragma Debug_Policy (CHECK | DISABLE | IGNORE | ON | OFF);
1606 This pragma is equivalent to a corresponding ``Check_Policy`` pragma
1607 with a first argument of ``Debug``. It is retained for historical
1608 compatibility reasons.
1610 Pragma Default_Scalar_Storage_Order
1611 ===================================
1612 .. index:: Default_Scalar_Storage_Order
1614 .. index:: Scalar_Storage_Order
1622 pragma Default_Scalar_Storage_Order (High_Order_First | Low_Order_First);
1625 Normally if no explicit ``Scalar_Storage_Order`` is given for a record
1626 type or array type, then the scalar storage order defaults to the ordinary
1627 default for the target. But this default may be overridden using this pragma.
1628 The pragma may appear as a configuration pragma, or locally within a package
1629 spec or declarative part. In the latter case, it applies to all subsequent
1630 types declared within that package spec or declarative part.
1632 The following example shows the use of this pragma:
1637 pragma Default_Scalar_Storage_Order (High_Order_First);
1638 with System; use System;
1647 for L2'Scalar_Storage_Order use Low_Order_First;
1656 pragma Default_Scalar_Storage_Order (Low_Order_First);
1663 type H4a is new Inner.L4;
1671 In this example record types with names starting with *L* have `Low_Order_First` scalar
1672 storage order, and record types with names starting with *H* have ``High_Order_First``.
1673 Note that in the case of ``H4a``, the order is not inherited
1674 from the parent type. Only an explicitly set ``Scalar_Storage_Order``
1675 gets inherited on type derivation.
1677 If this pragma is used as a configuration pragma which appears within a
1678 configuration pragma file (as opposed to appearing explicitly at the start
1679 of a single unit), then the binder will require that all units in a partition
1680 be compiled in a similar manner, other than run-time units, which are not
1681 affected by this pragma. Note that the use of this form is discouraged because
1682 it may significantly degrade the run-time performance of the software, instead
1683 the default scalar storage order ought to be changed only on a local basis.
1685 Pragma Default_Storage_Pool
1686 ===========================
1687 .. index:: Default_Storage_Pool
1695 pragma Default_Storage_Pool (storage_pool_NAME | null);
1698 This pragma is standard in Ada 2012, but is available in all earlier
1699 versions of Ada as an implementation-defined pragma.
1700 See Ada 2012 Reference Manual for details.
1711 pragma Depends (DEPENDENCY_RELATION);
1713 DEPENDENCY_RELATION ::=
1715 | (DEPENDENCY_CLAUSE {, DEPENDENCY_CLAUSE})
1717 DEPENDENCY_CLAUSE ::=
1718 OUTPUT_LIST =>[+] INPUT_LIST
1719 | NULL_DEPENDENCY_CLAUSE
1721 NULL_DEPENDENCY_CLAUSE ::= null => INPUT_LIST
1723 OUTPUT_LIST ::= OUTPUT | (OUTPUT {, OUTPUT})
1725 INPUT_LIST ::= null | INPUT | (INPUT {, INPUT})
1727 OUTPUT ::= NAME | FUNCTION_RESULT
1730 where FUNCTION_RESULT is a function Result attribute_reference
1732 For the semantics of this pragma, see the entry for aspect ``Depends`` in the
1733 SPARK 2014 Reference Manual, section 6.1.5.
1735 Pragma Detect_Blocking
1736 ======================
1742 pragma Detect_Blocking;
1745 This is a standard pragma in Ada 2005, that is available in all earlier
1746 versions of Ada as an implementation-defined pragma.
1748 This is a configuration pragma that forces the detection of potentially
1749 blocking operations within a protected operation, and to raise Program_Error
1752 Pragma Disable_Atomic_Synchronization
1753 =====================================
1755 .. index:: Atomic Synchronization
1761 pragma Disable_Atomic_Synchronization [(Entity)];
1764 Ada requires that accesses (reads or writes) of an atomic variable be
1765 regarded as synchronization points in the case of multiple tasks.
1766 Particularly in the case of multi-processors this may require special
1767 handling, e.g. the generation of memory barriers. This capability may
1768 be turned off using this pragma in cases where it is known not to be
1771 The placement and scope rules for this pragma are the same as those
1772 for ``pragma Suppress``. In particular it can be used as a
1773 configuration pragma, or in a declaration sequence where it applies
1774 till the end of the scope. If an ``Entity`` argument is present,
1775 the action applies only to that entity.
1777 Pragma Dispatching_Domain
1778 =========================
1785 pragma Dispatching_Domain (EXPRESSION);
1788 This pragma is standard in Ada 2012, but is available in all earlier
1789 versions of Ada as an implementation-defined pragma.
1790 See Ada 2012 Reference Manual for details.
1792 .. _Pragma-Effective_Reads:
1794 Pragma Effective_Reads
1795 ======================
1801 pragma Effective_Reads [ (boolean_EXPRESSION) ];
1803 For the semantics of this pragma, see the entry for aspect ``Effective_Reads`` in
1804 the SPARK 2014 Reference Manual, section 7.1.2.
1806 .. _Pragma-Effective_Writes:
1808 Pragma Effective_Writes
1809 =======================
1815 pragma Effective_Writes [ (boolean_EXPRESSION) ];
1817 For the semantics of this pragma, see the entry for aspect ``Effective_Writes``
1818 in the SPARK 2014 Reference Manual, section 7.1.2.
1820 Pragma Elaboration_Checks
1821 =========================
1822 .. index:: Elaboration control
1830 pragma Elaboration_Checks (Dynamic | Static);
1833 This is a configuration pragma which specifies the elaboration model to be
1834 used during compilation. For more information on the elaboration models of
1835 GNAT, consult the chapter on elaboration order handling in the *GNAT User's
1838 The pragma may appear in the following contexts:
1840 * Configuration pragmas file
1842 * Prior to the context clauses of a compilation unit's initial declaration
1844 Any other placement of the pragma will result in a warning and the effects of
1845 the offending pragma will be ignored.
1847 If the pragma argument is ``Dynamic``, then the dynamic elaboration model is in
1848 effect. If the pragma argument is ``Static``, then the static elaboration model
1853 .. index:: Elimination of unused subprograms
1862 [ Unit_Name => ] IDENTIFIER | SELECTED_COMPONENT ,
1863 [ Entity => ] IDENTIFIER |
1864 SELECTED_COMPONENT |
1866 [, Source_Location => SOURCE_TRACE ] );
1868 SOURCE_TRACE ::= STRING_LITERAL
1871 This pragma indicates that the given entity is not used in the program to be
1872 compiled and built, thus allowing the compiler to
1873 eliminate the code or data associated with the named entity. Any reference to
1874 an eliminated entity causes a compile-time or link-time error.
1876 The pragma has the following semantics, where ``U`` is the unit specified by
1877 the ``Unit_Name`` argument and ``E`` is the entity specified by the ``Entity``
1880 * ``E`` must be a subprogram that is explicitly declared either:
1884 o Within a generic package that is instantiated in ``U``, or
1886 o As an instance of generic subprogram instantiated in ``U``.
1888 Otherwise the pragma is ignored.
1890 * If ``E`` is overloaded within ``U`` then, in the absence of a
1891 ``Source_Location`` argument, all overloadings are eliminated.
1893 * If ``E`` is overloaded within ``U`` and only some overloadings
1894 are to be eliminated, then each overloading to be eliminated
1895 must be specified in a corresponding pragma ``Eliminate``
1896 with a ``Source_Location`` argument identifying the line where the
1897 declaration appears, as described below.
1899 * If ``E`` is declared as the result of a generic instantiation, then
1900 a ``Source_Location`` argument is needed, as described below
1902 Pragma ``Eliminate`` allows a program to be compiled in a system-independent
1903 manner, so that unused entities are eliminated but without
1904 needing to modify the source text. Normally the required set of
1905 ``Eliminate`` pragmas is constructed automatically using the ``gnatelim`` tool.
1907 Any source file change that removes, splits, or
1908 adds lines may make the set of ``Eliminate`` pragmas invalid because their
1909 ``Source_Location`` argument values may get out of date.
1911 Pragma ``Eliminate`` may be used where the referenced entity is a dispatching
1912 operation. In this case all the subprograms to which the given operation can
1913 dispatch are considered to be unused (are never called as a result of a direct
1914 or a dispatching call).
1916 The string literal given for the source location specifies the line number
1917 of the declaration of the entity, using the following syntax for ``SOURCE_TRACE``:
1921 SOURCE_TRACE ::= SOURCE_REFERENCE [ LBRACKET SOURCE_TRACE RBRACKET ]
1926 SOURCE_REFERENCE ::= FILE_NAME : LINE_NUMBER
1928 LINE_NUMBER ::= DIGIT {DIGIT}
1931 Spaces around the colon in a ``SOURCE_REFERENCE`` are optional.
1933 The source trace that is given as the ``Source_Location`` must obey the
1934 following rules (or else the pragma is ignored), where ``U`` is
1935 the unit ``U`` specified by the ``Unit_Name`` argument and ``E`` is the
1936 subprogram specified by the ``Entity`` argument:
1938 * ``FILE_NAME`` is the short name (with no directory
1939 information) of the Ada source file for ``U``, using the required syntax
1940 for the underlying file system (e.g. case is significant if the underlying
1941 operating system is case sensitive).
1942 If ``U`` is a package and ``E`` is a subprogram declared in the package
1943 specification and its full declaration appears in the package body,
1944 then the relevant source file is the one for the package specification;
1945 analogously if ``U`` is a generic package.
1947 * If ``E`` is not declared in a generic instantiation (this includes
1948 generic subprogram instances), the source trace includes only one source
1949 line reference. ``LINE_NUMBER`` gives the line number of the occurrence
1950 of the declaration of ``E`` within the source file (as a decimal literal
1951 without an exponent or point).
1953 * If ``E`` is declared by a generic instantiation, its source trace
1954 (from left to right) starts with the source location of the
1955 declaration of ``E`` in the generic unit and ends with the source
1956 location of the instantiation, given in square brackets. This approach is
1957 applied recursively with nested instantiations: the rightmost (nested
1958 most deeply in square brackets) element of the source trace is the location
1959 of the outermost instantiation, and the leftmost element (that is, outside
1960 of any square brackets) is the location of the declaration of ``E`` in
1967 pragma Eliminate (Pkg0, Proc);
1968 -- Eliminate (all overloadings of) Proc in Pkg0
1970 pragma Eliminate (Pkg1, Proc,
1971 Source_Location => "pkg1.ads:8");
1972 -- Eliminate overloading of Proc at line 8 in pkg1.ads
1974 -- Assume the following file contents:
1977 -- 2: type T is private;
1978 -- 3: package Gen_Pkg is
1979 -- 4: procedure Proc(N : T);
1985 -- 2: procedure Q is
1986 -- 3: package Inst_Pkg is new Gen_Pkg(Integer);
1987 -- ... -- No calls on Inst_Pkg.Proc
1990 -- The following pragma eliminates Inst_Pkg.Proc from Q
1991 pragma Eliminate (Q, Proc,
1992 Source_Location => "gen_pkg.ads:4[q.adb:3]");
1996 Pragma Enable_Atomic_Synchronization
1997 ====================================
1998 .. index:: Atomic Synchronization
2006 pragma Enable_Atomic_Synchronization [(Entity)];
2009 Ada requires that accesses (reads or writes) of an atomic variable be
2010 regarded as synchronization points in the case of multiple tasks.
2011 Particularly in the case of multi-processors this may require special
2012 handling, e.g. the generation of memory barriers. This synchronization
2013 is performed by default, but can be turned off using
2014 ``pragma Disable_Atomic_Synchronization``. The
2015 ``Enable_Atomic_Synchronization`` pragma can be used to turn
2018 The placement and scope rules for this pragma are the same as those
2019 for ``pragma Unsuppress``. In particular it can be used as a
2020 configuration pragma, or in a declaration sequence where it applies
2021 till the end of the scope. If an ``Entity`` argument is present,
2022 the action applies only to that entity.
2024 Pragma Export_Function
2025 ======================
2026 .. index:: Argument passing mechanisms
2034 pragma Export_Function (
2035 [Internal =>] LOCAL_NAME
2036 [, [External =>] EXTERNAL_SYMBOL]
2037 [, [Parameter_Types =>] PARAMETER_TYPES]
2038 [, [Result_Type =>] result_SUBTYPE_MARK]
2039 [, [Mechanism =>] MECHANISM]
2040 [, [Result_Mechanism =>] MECHANISM_NAME]);
2044 | static_string_EXPRESSION
2049 | TYPE_DESIGNATOR {, TYPE_DESIGNATOR}
2053 | subtype_Name ' Access
2057 | (MECHANISM_ASSOCIATION {, MECHANISM_ASSOCIATION})
2059 MECHANISM_ASSOCIATION ::=
2060 [formal_parameter_NAME =>] MECHANISM_NAME
2062 MECHANISM_NAME ::= Value | Reference
2065 Use this pragma to make a function externally callable and optionally
2066 provide information on mechanisms to be used for passing parameter and
2067 result values. We recommend, for the purposes of improving portability,
2068 this pragma always be used in conjunction with a separate pragma
2069 ``Export``, which must precede the pragma ``Export_Function``.
2070 GNAT does not require a separate pragma ``Export``, but if none is
2071 present, ``Convention Ada`` is assumed, which is usually
2072 not what is wanted, so it is usually appropriate to use this
2073 pragma in conjunction with a ``Export`` or ``Convention``
2074 pragma that specifies the desired foreign convention.
2075 Pragma ``Export_Function``
2076 (and ``Export``, if present) must appear in the same declarative
2077 region as the function to which they apply.
2079 The ``internal_name`` must uniquely designate the function to which the
2080 pragma applies. If more than one function name exists of this name in
2081 the declarative part you must use the ``Parameter_Types`` and
2082 ``Result_Type`` parameters to achieve the required
2083 unique designation. The `subtype_mark`\ s in these parameters must
2084 exactly match the subtypes in the corresponding function specification,
2085 using positional notation to match parameters with subtype marks.
2086 The form with an ``'Access`` attribute can be used to match an
2087 anonymous access parameter.
2089 .. index:: Suppressing external name
2091 Special treatment is given if the EXTERNAL is an explicit null
2092 string or a static string expressions that evaluates to the null
2093 string. In this case, no external name is generated. This form
2094 still allows the specification of parameter mechanisms.
2096 Pragma Export_Object
2097 ====================
2104 pragma Export_Object
2105 [Internal =>] LOCAL_NAME
2106 [, [External =>] EXTERNAL_SYMBOL]
2107 [, [Size =>] EXTERNAL_SYMBOL]
2111 | static_string_EXPRESSION
2114 This pragma designates an object as exported, and apart from the
2115 extended rules for external symbols, is identical in effect to the use of
2116 the normal ``Export`` pragma applied to an object. You may use a
2117 separate Export pragma (and you probably should from the point of view
2118 of portability), but it is not required. ``Size`` is syntax checked,
2119 but otherwise ignored by GNAT.
2121 Pragma Export_Procedure
2122 =======================
2129 pragma Export_Procedure (
2130 [Internal =>] LOCAL_NAME
2131 [, [External =>] EXTERNAL_SYMBOL]
2132 [, [Parameter_Types =>] PARAMETER_TYPES]
2133 [, [Mechanism =>] MECHANISM]);
2137 | static_string_EXPRESSION
2142 | TYPE_DESIGNATOR {, TYPE_DESIGNATOR}
2146 | subtype_Name ' Access
2150 | (MECHANISM_ASSOCIATION {, MECHANISM_ASSOCIATION})
2152 MECHANISM_ASSOCIATION ::=
2153 [formal_parameter_NAME =>] MECHANISM_NAME
2155 MECHANISM_NAME ::= Value | Reference
2158 This pragma is identical to ``Export_Function`` except that it
2159 applies to a procedure rather than a function and the parameters
2160 ``Result_Type`` and ``Result_Mechanism`` are not permitted.
2161 GNAT does not require a separate pragma ``Export``, but if none is
2162 present, ``Convention Ada`` is assumed, which is usually
2163 not what is wanted, so it is usually appropriate to use this
2164 pragma in conjunction with a ``Export`` or ``Convention``
2165 pragma that specifies the desired foreign convention.
2167 .. index:: Suppressing external name
2169 Special treatment is given if the EXTERNAL is an explicit null
2170 string or a static string expressions that evaluates to the null
2171 string. In this case, no external name is generated. This form
2172 still allows the specification of parameter mechanisms.
2182 pragma Export_Value (
2183 [Value =>] static_integer_EXPRESSION,
2184 [Link_Name =>] static_string_EXPRESSION);
2187 This pragma serves to export a static integer value for external use.
2188 The first argument specifies the value to be exported. The Link_Name
2189 argument specifies the symbolic name to be associated with the integer
2190 value. This pragma is useful for defining a named static value in Ada
2191 that can be referenced in assembly language units to be linked with
2192 the application. This pragma is currently supported only for the
2193 AAMP target and is ignored for other targets.
2195 Pragma Export_Valued_Procedure
2196 ==============================
2203 pragma Export_Valued_Procedure (
2204 [Internal =>] LOCAL_NAME
2205 [, [External =>] EXTERNAL_SYMBOL]
2206 [, [Parameter_Types =>] PARAMETER_TYPES]
2207 [, [Mechanism =>] MECHANISM]);
2211 | static_string_EXPRESSION
2216 | TYPE_DESIGNATOR {, TYPE_DESIGNATOR}
2220 | subtype_Name ' Access
2224 | (MECHANISM_ASSOCIATION {, MECHANISM_ASSOCIATION})
2226 MECHANISM_ASSOCIATION ::=
2227 [formal_parameter_NAME =>] MECHANISM_NAME
2229 MECHANISM_NAME ::= Value | Reference
2232 This pragma is identical to ``Export_Procedure`` except that the
2233 first parameter of ``LOCAL_NAME``, which must be present, must be of
2234 mode ``out``, and externally the subprogram is treated as a function
2235 with this parameter as the result of the function. GNAT provides for
2236 this capability to allow the use of ``out`` and ``in out``
2237 parameters in interfacing to external functions (which are not permitted
2239 GNAT does not require a separate pragma ``Export``, but if none is
2240 present, ``Convention Ada`` is assumed, which is almost certainly
2241 not what is wanted since the whole point of this pragma is to interface
2242 with foreign language functions, so it is usually appropriate to use this
2243 pragma in conjunction with a ``Export`` or ``Convention``
2244 pragma that specifies the desired foreign convention.
2246 .. index:: Suppressing external name
2248 Special treatment is given if the EXTERNAL is an explicit null
2249 string or a static string expressions that evaluates to the null
2250 string. In this case, no external name is generated. This form
2251 still allows the specification of parameter mechanisms.
2253 Pragma Extend_System
2254 ====================
2255 .. index:: System, extending
2257 .. index:: DEC Ada 83
2265 pragma Extend_System ([Name =>] IDENTIFIER);
2268 This pragma is used to provide backwards compatibility with other
2269 implementations that extend the facilities of package ``System``. In
2270 GNAT, ``System`` contains only the definitions that are present in
2271 the Ada RM. However, other implementations, notably the DEC Ada 83
2272 implementation, provide many extensions to package ``System``.
2274 For each such implementation accommodated by this pragma, GNAT provides a
2275 package :samp:`Aux_{xxx}`, e.g., ``Aux_DEC`` for the DEC Ada 83
2276 implementation, which provides the required additional definitions. You
2277 can use this package in two ways. You can ``with`` it in the normal
2278 way and access entities either by selection or using a ``use``
2279 clause. In this case no special processing is required.
2281 However, if existing code contains references such as
2282 :samp:`System.{xxx}` where *xxx* is an entity in the extended
2283 definitions provided in package ``System``, you may use this pragma
2284 to extend visibility in ``System`` in a non-standard way that
2285 provides greater compatibility with the existing code. Pragma
2286 ``Extend_System`` is a configuration pragma whose single argument is
2287 the name of the package containing the extended definition
2288 (e.g., ``Aux_DEC`` for the DEC Ada case). A unit compiled under
2289 control of this pragma will be processed using special visibility
2290 processing that looks in package :samp:`System.Aux_{xxx}` where
2291 :samp:`Aux_{xxx}` is the pragma argument for any entity referenced in
2292 package ``System``, but not found in package ``System``.
2294 You can use this pragma either to access a predefined ``System``
2295 extension supplied with the compiler, for example ``Aux_DEC`` or
2296 you can construct your own extension unit following the above
2297 definition. Note that such a package is a child of ``System``
2298 and thus is considered part of the implementation.
2299 To compile it you will have to use the *-gnatg* switch
2300 for compiling System units, as explained in the
2303 Pragma Extensions_Allowed
2304 =========================
2305 .. index:: Ada Extensions
2307 .. index:: GNAT Extensions
2314 pragma Extensions_Allowed (On | Off);
2317 This configuration pragma enables or disables the implementation
2318 extension mode (the use of Off as a parameter cancels the effect
2319 of the *-gnatX* command switch).
2321 In extension mode, the latest version of the Ada language is
2322 implemented (currently Ada 2012), and in addition a small number
2323 of GNAT specific extensions are recognized as follows:
2327 *Constrained attribute for generic objects*
2328 The ``Constrained`` attribute is permitted for objects of
2329 generic types. The result indicates if the corresponding actual
2332 .. _Pragma-Extensions_Visible:
2334 Pragma Extensions_Visible
2335 =========================
2341 pragma Extensions_Visible [ (boolean_EXPRESSION) ];
2343 For the semantics of this pragma, see the entry for aspect ``Extensions_Visible``
2344 in the SPARK 2014 Reference Manual, section 6.1.7.
2355 [ Convention =>] convention_IDENTIFIER,
2356 [ Entity =>] LOCAL_NAME
2357 [, [External_Name =>] static_string_EXPRESSION ]
2358 [, [Link_Name =>] static_string_EXPRESSION ]);
2361 This pragma is identical in syntax and semantics to pragma
2362 ``Export`` as defined in the Ada Reference Manual. It is
2363 provided for compatibility with some Ada 83 compilers that
2364 used this pragma for exactly the same purposes as pragma
2365 ``Export`` before the latter was standardized.
2367 Pragma External_Name_Casing
2368 ===========================
2369 .. index:: Dec Ada 83 casing compatibility
2371 .. index:: External Names, casing
2373 .. index:: Casing of External names
2381 pragma External_Name_Casing (
2382 Uppercase | Lowercase
2383 [, Uppercase | Lowercase | As_Is]);
2386 This pragma provides control over the casing of external names associated
2387 with Import and Export pragmas. There are two cases to consider:
2391 * Implicit external names
2393 Implicit external names are derived from identifiers. The most common case
2394 arises when a standard Ada Import or Export pragma is used with only two
2399 pragma Import (C, C_Routine);
2401 Since Ada is a case-insensitive language, the spelling of the identifier in
2402 the Ada source program does not provide any information on the desired
2403 casing of the external name, and so a convention is needed. In GNAT the
2404 default treatment is that such names are converted to all lower case
2405 letters. This corresponds to the normal C style in many environments.
2406 The first argument of pragma ``External_Name_Casing`` can be used to
2407 control this treatment. If ``Uppercase`` is specified, then the name
2408 will be forced to all uppercase letters. If ``Lowercase`` is specified,
2409 then the normal default of all lower case letters will be used.
2411 This same implicit treatment is also used in the case of extended DEC Ada 83
2412 compatible Import and Export pragmas where an external name is explicitly
2413 specified using an identifier rather than a string.
2416 * Explicit external names
2418 Explicit external names are given as string literals. The most common case
2419 arises when a standard Ada Import or Export pragma is used with three
2424 pragma Import (C, C_Routine, "C_routine");
2426 In this case, the string literal normally provides the exact casing required
2427 for the external name. The second argument of pragma
2428 ``External_Name_Casing`` may be used to modify this behavior.
2429 If ``Uppercase`` is specified, then the name
2430 will be forced to all uppercase letters. If ``Lowercase`` is specified,
2431 then the name will be forced to all lowercase letters. A specification of
2432 ``As_Is`` provides the normal default behavior in which the casing is
2433 taken from the string provided.
2435 This pragma may appear anywhere that a pragma is valid. In particular, it
2436 can be used as a configuration pragma in the :file:`gnat.adc` file, in which
2437 case it applies to all subsequent compilations, or it can be used as a program
2438 unit pragma, in which case it only applies to the current unit, or it can
2439 be used more locally to control individual Import/Export pragmas.
2441 It was primarily intended for use with OpenVMS systems, where many
2442 compilers convert all symbols to upper case by default. For interfacing to
2443 such compilers (e.g., the DEC C compiler), it may be convenient to use
2448 pragma External_Name_Casing (Uppercase, Uppercase);
2451 to enforce the upper casing of all external symbols.
2464 This is a configuration pragma which activates a mode in which speed is
2465 considered more important for floating-point operations than absolutely
2466 accurate adherence to the requirements of the standard. Currently the
2467 following operations are affected:
2471 *Complex Multiplication*
2472 The normal simple formula for complex multiplication can result in intermediate
2473 overflows for numbers near the end of the range. The Ada standard requires that
2474 this situation be detected and corrected by scaling, but in Fast_Math mode such
2475 cases will simply result in overflow. Note that to take advantage of this you
2476 must instantiate your own version of ``Ada.Numerics.Generic_Complex_Types``
2477 under control of the pragma, rather than use the preinstantiated versions.
2479 .. _Pragma-Favor_Top_Level:
2481 Pragma Favor_Top_Level
2482 ======================
2489 pragma Favor_Top_Level (type_NAME);
2492 The argument of pragma ``Favor_Top_Level`` must be a named access-to-subprogram
2493 type. This pragma is an efficiency hint to the compiler, regarding the use of
2494 ``'Access`` or ``'Unrestricted_Access`` on nested (non-library-level) subprograms.
2495 The pragma means that nested subprograms are not used with this type, or are
2496 rare, so that the generated code should be efficient in the top-level case.
2497 When this pragma is used, dynamically generated trampolines may be used on some
2498 targets for nested subprograms. See restriction ``No_Implicit_Dynamic_Code``.
2500 Pragma Finalize_Storage_Only
2501 ============================
2508 pragma Finalize_Storage_Only (first_subtype_LOCAL_NAME);
2511 The argument of pragma ``Finalize_Storage_Only`` must denote a local type which
2512 is derived from ``Ada.Finalization.Controlled`` or ``Limited_Controlled``. The
2513 pragma suppresses the call to ``Finalize`` for declared library-level objects
2514 of the argument type. This is mostly useful for types where finalization is
2515 only used to deal with storage reclamation since in most environments it is
2516 not necessary to reclaim memory just before terminating execution, hence the
2517 name. Note that this pragma does not suppress Finalize calls for library-level
2518 heap-allocated objects (see pragma ``No_Heap_Finalization``).
2520 Pragma Float_Representation
2521 ===========================
2525 pragma Float_Representation (FLOAT_REP[, float_type_LOCAL_NAME]);
2527 FLOAT_REP ::= VAX_Float | IEEE_Float
2530 In the one argument form, this pragma is a configuration pragma which
2531 allows control over the internal representation chosen for the predefined
2532 floating point types declared in the packages ``Standard`` and
2533 ``System``. This pragma is only provided for compatibility and has no effect.
2535 The two argument form specifies the representation to be used for
2536 the specified floating-point type. The argument must
2537 be ``IEEE_Float`` to specify the use of IEEE format, as follows:
2540 For a digits value of 6, 32-bit IEEE short format will be used.
2542 For a digits value of 15, 64-bit IEEE long format will be used.
2544 No other value of digits is permitted.
2555 pragma Ghost [ (boolean_EXPRESSION) ];
2557 For the semantics of this pragma, see the entry for aspect ``Ghost`` in the SPARK
2558 2014 Reference Manual, section 6.9.
2569 pragma Global (GLOBAL_SPECIFICATION);
2571 GLOBAL_SPECIFICATION ::=
2574 | (MODED_GLOBAL_LIST {, MODED_GLOBAL_LIST})
2576 MODED_GLOBAL_LIST ::= MODE_SELECTOR => GLOBAL_LIST
2578 MODE_SELECTOR ::= In_Out | Input | Output | Proof_In
2579 GLOBAL_LIST ::= GLOBAL_ITEM | (GLOBAL_ITEM {, GLOBAL_ITEM})
2580 GLOBAL_ITEM ::= NAME
2582 For the semantics of this pragma, see the entry for aspect ``Global`` in the
2583 SPARK 2014 Reference Manual, section 6.1.4.
2593 pragma Ident (static_string_EXPRESSION);
2596 This pragma is identical in effect to pragma ``Comment``. It is provided
2597 for compatibility with other Ada compilers providing this pragma.
2599 Pragma Ignore_Pragma
2600 ====================
2607 pragma Ignore_Pragma (pragma_IDENTIFIER);
2609 This is a configuration pragma
2610 that takes a single argument that is a simple identifier. Any subsequent
2611 use of a pragma whose pragma identifier matches this argument will be
2612 silently ignored. This may be useful when legacy code or code intended
2613 for compilation with some other compiler contains pragmas that match the
2614 name, but not the exact implementation, of a GNAT pragma. The use of this
2615 pragma allows such pragmas to be ignored, which may be useful in CodePeer
2616 mode, or during porting of legacy code.
2618 Pragma Implementation_Defined
2619 =============================
2626 pragma Implementation_Defined (local_NAME);
2629 This pragma marks a previously declared entity as implementation-defined.
2630 For an overloaded entity, applies to the most recent homonym.
2635 pragma Implementation_Defined;
2638 The form with no arguments appears anywhere within a scope, most
2639 typically a package spec, and indicates that all entities that are
2640 defined within the package spec are Implementation_Defined.
2642 This pragma is used within the GNAT runtime library to identify
2643 implementation-defined entities introduced in language-defined units,
2644 for the purpose of implementing the No_Implementation_Identifiers
2655 pragma Implemented (procedure_LOCAL_NAME, implementation_kind);
2657 implementation_kind ::= By_Entry | By_Protected_Procedure | By_Any
2660 This is an Ada 2012 representation pragma which applies to protected, task
2661 and synchronized interface primitives. The use of pragma Implemented provides
2662 a way to impose a static requirement on the overriding operation by adhering
2663 to one of the three implementation kinds: entry, protected procedure or any of
2664 the above. This pragma is available in all earlier versions of Ada as an
2665 implementation-defined pragma.
2670 type Synch_Iface is synchronized interface;
2671 procedure Prim_Op (Obj : in out Iface) is abstract;
2672 pragma Implemented (Prim_Op, By_Protected_Procedure);
2674 protected type Prot_1 is new Synch_Iface with
2675 procedure Prim_Op; -- Legal
2678 protected type Prot_2 is new Synch_Iface with
2679 entry Prim_Op; -- Illegal
2682 task type Task_Typ is new Synch_Iface with
2683 entry Prim_Op; -- Illegal
2687 When applied to the procedure_or_entry_NAME of a requeue statement, pragma
2688 Implemented determines the runtime behavior of the requeue. Implementation kind
2689 By_Entry guarantees that the action of requeueing will proceed from an entry to
2690 another entry. Implementation kind By_Protected_Procedure transforms the
2691 requeue into a dispatching call, thus eliminating the chance of blocking. Kind
2692 By_Any shares the behavior of By_Entry and By_Protected_Procedure depending on
2693 the target's overriding subprogram kind.
2695 Pragma Implicit_Packing
2696 =======================
2697 .. index:: Rational Profile
2704 pragma Implicit_Packing;
2707 This is a configuration pragma that requests implicit packing for packed
2708 arrays for which a size clause is given but no explicit pragma Pack or
2709 specification of Component_Size is present. It also applies to records
2710 where no record representation clause is present. Consider this example:
2715 type R is array (0 .. 7) of Boolean;
2719 In accordance with the recommendation in the RM (RM 13.3(53)), a Size clause
2720 does not change the layout of a composite object. So the Size clause in the
2721 above example is normally rejected, since the default layout of the array uses
2722 8-bit components, and thus the array requires a minimum of 64 bits.
2724 If this declaration is compiled in a region of code covered by an occurrence
2725 of the configuration pragma Implicit_Packing, then the Size clause in this
2726 and similar examples will cause implicit packing and thus be accepted. For
2727 this implicit packing to occur, the type in question must be an array of small
2728 components whose size is known at compile time, and the Size clause must
2729 specify the exact size that corresponds to the number of elements in the array
2730 multiplied by the size in bits of the component type (both single and
2731 multi-dimensioned arrays can be controlled with this pragma).
2733 .. index:: Array packing
2735 Similarly, the following example shows the use in the record case
2741 a, b, c, d, e, f, g, h : boolean;
2747 Without a pragma Pack, each Boolean field requires 8 bits, so the
2748 minimum size is 72 bits, but with a pragma Pack, 16 bits would be
2749 sufficient. The use of pragma Implicit_Packing allows this record
2750 declaration to compile without an explicit pragma Pack.
2752 Pragma Import_Function
2753 ======================
2760 pragma Import_Function (
2761 [Internal =>] LOCAL_NAME,
2762 [, [External =>] EXTERNAL_SYMBOL]
2763 [, [Parameter_Types =>] PARAMETER_TYPES]
2764 [, [Result_Type =>] SUBTYPE_MARK]
2765 [, [Mechanism =>] MECHANISM]
2766 [, [Result_Mechanism =>] MECHANISM_NAME]);
2770 | static_string_EXPRESSION
2774 | TYPE_DESIGNATOR {, TYPE_DESIGNATOR}
2778 | subtype_Name ' Access
2782 | (MECHANISM_ASSOCIATION {, MECHANISM_ASSOCIATION})
2784 MECHANISM_ASSOCIATION ::=
2785 [formal_parameter_NAME =>] MECHANISM_NAME
2792 This pragma is used in conjunction with a pragma ``Import`` to
2793 specify additional information for an imported function. The pragma
2794 ``Import`` (or equivalent pragma ``Interface``) must precede the
2795 ``Import_Function`` pragma and both must appear in the same
2796 declarative part as the function specification.
2798 The ``Internal`` argument must uniquely designate
2799 the function to which the
2800 pragma applies. If more than one function name exists of this name in
2801 the declarative part you must use the ``Parameter_Types`` and
2802 ``Result_Type`` parameters to achieve the required unique
2803 designation. Subtype marks in these parameters must exactly match the
2804 subtypes in the corresponding function specification, using positional
2805 notation to match parameters with subtype marks.
2806 The form with an ``'Access`` attribute can be used to match an
2807 anonymous access parameter.
2809 You may optionally use the ``Mechanism`` and ``Result_Mechanism``
2810 parameters to specify passing mechanisms for the
2811 parameters and result. If you specify a single mechanism name, it
2812 applies to all parameters. Otherwise you may specify a mechanism on a
2813 parameter by parameter basis using either positional or named
2814 notation. If the mechanism is not specified, the default mechanism
2817 Pragma Import_Object
2818 ====================
2825 pragma Import_Object
2826 [Internal =>] LOCAL_NAME
2827 [, [External =>] EXTERNAL_SYMBOL]
2828 [, [Size =>] EXTERNAL_SYMBOL]);
2832 | static_string_EXPRESSION
2835 This pragma designates an object as imported, and apart from the
2836 extended rules for external symbols, is identical in effect to the use of
2837 the normal ``Import`` pragma applied to an object. Unlike the
2838 subprogram case, you need not use a separate ``Import`` pragma,
2839 although you may do so (and probably should do so from a portability
2840 point of view). ``size`` is syntax checked, but otherwise ignored by
2843 Pragma Import_Procedure
2844 =======================
2851 pragma Import_Procedure (
2852 [Internal =>] LOCAL_NAME
2853 [, [External =>] EXTERNAL_SYMBOL]
2854 [, [Parameter_Types =>] PARAMETER_TYPES]
2855 [, [Mechanism =>] MECHANISM]);
2859 | static_string_EXPRESSION
2863 | TYPE_DESIGNATOR {, TYPE_DESIGNATOR}
2867 | subtype_Name ' Access
2871 | (MECHANISM_ASSOCIATION {, MECHANISM_ASSOCIATION})
2873 MECHANISM_ASSOCIATION ::=
2874 [formal_parameter_NAME =>] MECHANISM_NAME
2876 MECHANISM_NAME ::= Value | Reference
2879 This pragma is identical to ``Import_Function`` except that it
2880 applies to a procedure rather than a function and the parameters
2881 ``Result_Type`` and ``Result_Mechanism`` are not permitted.
2883 Pragma Import_Valued_Procedure
2884 ==============================
2891 pragma Import_Valued_Procedure (
2892 [Internal =>] LOCAL_NAME
2893 [, [External =>] EXTERNAL_SYMBOL]
2894 [, [Parameter_Types =>] PARAMETER_TYPES]
2895 [, [Mechanism =>] MECHANISM]);
2899 | static_string_EXPRESSION
2903 | TYPE_DESIGNATOR {, TYPE_DESIGNATOR}
2907 | subtype_Name ' Access
2911 | (MECHANISM_ASSOCIATION {, MECHANISM_ASSOCIATION})
2913 MECHANISM_ASSOCIATION ::=
2914 [formal_parameter_NAME =>] MECHANISM_NAME
2916 MECHANISM_NAME ::= Value | Reference
2919 This pragma is identical to ``Import_Procedure`` except that the
2920 first parameter of ``LOCAL_NAME``, which must be present, must be of
2921 mode ``out``, and externally the subprogram is treated as a function
2922 with this parameter as the result of the function. The purpose of this
2923 capability is to allow the use of ``out`` and ``in out``
2924 parameters in interfacing to external functions (which are not permitted
2925 in Ada functions). You may optionally use the ``Mechanism``
2926 parameters to specify passing mechanisms for the parameters.
2927 If you specify a single mechanism name, it applies to all parameters.
2928 Otherwise you may specify a mechanism on a parameter by parameter
2929 basis using either positional or named notation. If the mechanism is not
2930 specified, the default mechanism is used.
2932 Note that it is important to use this pragma in conjunction with a separate
2933 pragma Import that specifies the desired convention, since otherwise the
2934 default convention is Ada, which is almost certainly not what is required.
2944 pragma Independent (Local_NAME);
2947 This pragma is standard in Ada 2012 mode (which also provides an aspect
2948 of the same name). It is also available as an implementation-defined
2949 pragma in all earlier versions. It specifies that the
2950 designated object or all objects of the designated type must be
2951 independently addressable. This means that separate tasks can safely
2952 manipulate such objects. For example, if two components of a record are
2953 independent, then two separate tasks may access these two components.
2955 constraints on the representation of the object (for instance prohibiting
2958 Pragma Independent_Components
2959 =============================
2966 pragma Independent_Components (Local_NAME);
2969 This pragma is standard in Ada 2012 mode (which also provides an aspect
2970 of the same name). It is also available as an implementation-defined
2971 pragma in all earlier versions. It specifies that the components of the
2972 designated object, or the components of each object of the designated
2974 independently addressable. This means that separate tasks can safely
2975 manipulate separate components in the composite object. This may place
2976 constraints on the representation of the object (for instance prohibiting
2979 .. _Pragma-Initial_Condition:
2981 Pragma Initial_Condition
2982 ========================
2988 pragma Initial_Condition (boolean_EXPRESSION);
2990 For the semantics of this pragma, see the entry for aspect ``Initial_Condition``
2991 in the SPARK 2014 Reference Manual, section 7.1.6.
2993 Pragma Initialize_Scalars
2994 =========================
2995 .. index:: debugging with Initialize_Scalars
3002 pragma Initialize_Scalars
3003 [ ( TYPE_VALUE_PAIR {, TYPE_VALUE_PAIR} ) ];
3006 SCALAR_TYPE => static_EXPRESSION
3023 This pragma is similar to ``Normalize_Scalars`` conceptually but has two
3024 important differences.
3026 First, there is no requirement for the pragma to be used uniformly in all units
3027 of a partition. In particular, it is fine to use this just for some or all of
3028 the application units of a partition, without needing to recompile the run-time
3029 library. In the case where some units are compiled with the pragma, and some
3030 without, then a declaration of a variable where the type is defined in package
3031 Standard or is locally declared will always be subject to initialization, as
3032 will any declaration of a scalar variable. For composite variables, whether the
3033 variable is initialized may also depend on whether the package in which the
3034 type of the variable is declared is compiled with the pragma.
3036 The other important difference is that the programmer can control the value
3037 used for initializing scalar objects. This effect can be achieved in several
3040 * At compile time, the programmer can specify the invalid value for a
3041 particular family of scalar types using the optional arguments of the pragma.
3043 The compile-time approach is intended to optimize the generated code for the
3044 pragma, by possibly using fast operations such as ``memset``.
3046 * At bind time, the programmer has several options:
3048 * Initialization with invalid values (similar to Normalize_Scalars, though
3049 for Initialize_Scalars it is not always possible to determine the invalid
3050 values in complex cases like signed component fields with nonstandard
3053 * Initialization with high values.
3055 * Initialization with low values.
3057 * Initialization with a specific bit pattern.
3059 See the GNAT User's Guide for binder options for specifying these cases.
3061 The bind-time approach is intended to provide fast turnaround for testing
3062 with different values, without having to recompile the program.
3064 * At execution time, the programmer can speify the invalid values using an
3065 environment variable. See the GNAT User's Guide for details.
3067 The execution-time approach is intended to provide fast turnaround for
3068 testing with different values, without having to recompile and rebind the
3071 Note that pragma ``Initialize_Scalars`` is particularly useful in conjunction
3072 with the enhanced validity checking that is now provided in GNAT, which checks
3073 for invalid values under more conditions. Using this feature (see description
3074 of the *-gnatV* flag in the GNAT User's Guide) in conjunction with pragma
3075 ``Initialize_Scalars`` provides a powerful new tool to assist in the detection
3076 of problems caused by uninitialized variables.
3078 Note: the use of ``Initialize_Scalars`` has a fairly extensive effect on the
3079 generated code. This may cause your code to be substantially larger. It may
3080 also cause an increase in the amount of stack required, so it is probably a
3081 good idea to turn on stack checking (see description of stack checking in the
3082 GNAT User's Guide) when using this pragma.
3084 .. _Pragma-Initializes:
3093 pragma Initializes (INITIALIZATION_LIST);
3095 INITIALIZATION_LIST ::=
3097 | (INITIALIZATION_ITEM {, INITIALIZATION_ITEM})
3099 INITIALIZATION_ITEM ::= name [=> INPUT_LIST]
3108 For the semantics of this pragma, see the entry for aspect ``Initializes`` in the
3109 SPARK 2014 Reference Manual, section 7.1.5.
3111 .. _Pragma-Inline_Always:
3113 Pragma Inline_Always
3114 ====================
3121 pragma Inline_Always (NAME [, NAME]);
3124 Similar to pragma ``Inline`` except that inlining is unconditional.
3125 Inline_Always instructs the compiler to inline every direct call to the
3126 subprogram or else to emit a compilation error, independently of any
3127 option, in particular *-gnatn* or *-gnatN* or the optimization level.
3128 It is an error to take the address or access of ``NAME``. It is also an error to
3129 apply this pragma to a primitive operation of a tagged type. Thanks to such
3130 restrictions, the compiler is allowed to remove the out-of-line body of ``NAME``.
3132 Pragma Inline_Generic
3133 =====================
3140 pragma Inline_Generic (GNAME {, GNAME});
3142 GNAME ::= generic_unit_NAME | generic_instance_NAME
3145 This pragma is provided for compatibility with Dec Ada 83. It has
3146 no effect in GNAT (which always inlines generics), other
3147 than to check that the given names are all names of generic units or
3159 [Convention =>] convention_identifier,
3160 [Entity =>] local_NAME
3161 [, [External_Name =>] static_string_expression]
3162 [, [Link_Name =>] static_string_expression]);
3165 This pragma is identical in syntax and semantics to
3166 the standard Ada pragma ``Import``. It is provided for compatibility
3167 with Ada 83. The definition is upwards compatible both with pragma
3168 ``Interface`` as defined in the Ada 83 Reference Manual, and also
3169 with some extended implementations of this pragma in certain Ada 83
3170 implementations. The only difference between pragma ``Interface``
3171 and pragma ``Import`` is that there is special circuitry to allow
3172 both pragmas to appear for the same subprogram entity (normally it
3173 is illegal to have multiple ``Import`` pragmas. This is useful in
3174 maintaining Ada 83/Ada 95 compatibility and is compatible with other
3177 Pragma Interface_Name
3178 =====================
3185 pragma Interface_Name (
3186 [Entity =>] LOCAL_NAME
3187 [, [External_Name =>] static_string_EXPRESSION]
3188 [, [Link_Name =>] static_string_EXPRESSION]);
3191 This pragma provides an alternative way of specifying the interface name
3192 for an interfaced subprogram, and is provided for compatibility with Ada
3193 83 compilers that use the pragma for this purpose. You must provide at
3194 least one of ``External_Name`` or ``Link_Name``.
3196 Pragma Interrupt_Handler
3197 ========================
3204 pragma Interrupt_Handler (procedure_LOCAL_NAME);
3207 This program unit pragma is supported for parameterless protected procedures
3208 as described in Annex C of the Ada Reference Manual. On the AAMP target
3209 the pragma can also be specified for nonprotected parameterless procedures
3210 that are declared at the library level (which includes procedures
3211 declared at the top level of a library package). In the case of AAMP,
3212 when this pragma is applied to a nonprotected procedure, the instruction
3213 ``IERET`` is generated for returns from the procedure, enabling
3214 maskable interrupts, in place of the normal return instruction.
3216 Pragma Interrupt_State
3217 ======================
3224 pragma Interrupt_State
3226 [State =>] SYSTEM | RUNTIME | USER);
3229 Normally certain interrupts are reserved to the implementation. Any attempt
3230 to attach an interrupt causes Program_Error to be raised, as described in
3231 RM C.3.2(22). A typical example is the ``SIGINT`` interrupt used in
3232 many systems for an :kbd:`Ctrl-C` interrupt. Normally this interrupt is
3233 reserved to the implementation, so that :kbd:`Ctrl-C` can be used to
3234 interrupt execution. Additionally, signals such as ``SIGSEGV``,
3235 ``SIGABRT``, ``SIGFPE`` and ``SIGILL`` are often mapped to specific
3236 Ada exceptions, or used to implement run-time functions such as the
3237 ``abort`` statement and stack overflow checking.
3239 Pragma ``Interrupt_State`` provides a general mechanism for overriding
3240 such uses of interrupts. It subsumes the functionality of pragma
3241 ``Unreserve_All_Interrupts``. Pragma ``Interrupt_State`` is not
3242 available on Windows or VMS. On all other platforms than VxWorks,
3243 it applies to signals; on VxWorks, it applies to vectored hardware interrupts
3244 and may be used to mark interrupts required by the board support package
3247 Interrupts can be in one of three states:
3251 The interrupt is reserved (no Ada handler can be installed), and the
3252 Ada run-time may not install a handler. As a result you are guaranteed
3253 standard system default action if this interrupt is raised. This also allows
3254 installing a low level handler via C APIs such as sigaction(), outside
3259 The interrupt is reserved (no Ada handler can be installed). The run time
3260 is allowed to install a handler for internal control purposes, but is
3261 not required to do so.
3265 The interrupt is unreserved. The user may install an Ada handler via
3266 Ada.Interrupts and pragma Interrupt_Handler or Attach_Handler to provide
3269 These states are the allowed values of the ``State`` parameter of the
3270 pragma. The ``Name`` parameter is a value of the type
3271 ``Ada.Interrupts.Interrupt_ID``. Typically, it is a name declared in
3272 ``Ada.Interrupts.Names``.
3274 This is a configuration pragma, and the binder will check that there
3275 are no inconsistencies between different units in a partition in how a
3276 given interrupt is specified. It may appear anywhere a pragma is legal.
3278 The effect is to move the interrupt to the specified state.
3280 By declaring interrupts to be SYSTEM, you guarantee the standard system
3281 action, such as a core dump.
3283 By declaring interrupts to be USER, you guarantee that you can install
3286 Note that certain signals on many operating systems cannot be caught and
3287 handled by applications. In such cases, the pragma is ignored. See the
3288 operating system documentation, or the value of the array ``Reserved``
3289 declared in the spec of package ``System.OS_Interface``.
3291 Overriding the default state of signals used by the Ada runtime may interfere
3292 with an application's runtime behavior in the cases of the synchronous signals,
3293 and in the case of the signal used to implement the ``abort`` statement.
3295 .. _Pragma-Invariant:
3306 ([Entity =>] private_type_LOCAL_NAME,
3307 [Check =>] EXPRESSION
3308 [,[Message =>] String_Expression]);
3311 This pragma provides exactly the same capabilities as the Type_Invariant aspect
3312 defined in AI05-0146-1, and in the Ada 2012 Reference Manual. The
3313 Type_Invariant aspect is fully implemented in Ada 2012 mode, but since it
3314 requires the use of the aspect syntax, which is not available except in 2012
3315 mode, it is not possible to use the Type_Invariant aspect in earlier versions
3316 of Ada. However the Invariant pragma may be used in any version of Ada. Also
3317 note that the aspect Invariant is a synonym in GNAT for the aspect
3318 Type_Invariant, but there is no pragma Type_Invariant.
3320 The pragma must appear within the visible part of the package specification,
3321 after the type to which its Entity argument appears. As with the Invariant
3322 aspect, the Check expression is not analyzed until the end of the visible
3323 part of the package, so it may contain forward references. The Message
3324 argument, if present, provides the exception message used if the invariant
3325 is violated. If no Message parameter is provided, a default message that
3326 identifies the line on which the pragma appears is used.
3328 It is permissible to have multiple Invariants for the same type entity, in
3329 which case they are and'ed together. It is permissible to use this pragma
3330 in Ada 2012 mode, but you cannot have both an invariant aspect and an
3331 invariant pragma for the same entity.
3333 For further details on the use of this pragma, see the Ada 2012 documentation
3334 of the Type_Invariant aspect.
3344 pragma Keep_Names ([On =>] enumeration_first_subtype_LOCAL_NAME);
3347 The ``LOCAL_NAME`` argument
3348 must refer to an enumeration first subtype
3349 in the current declarative part. The effect is to retain the enumeration
3350 literal names for use by ``Image`` and ``Value`` even if a global
3351 ``Discard_Names`` pragma applies. This is useful when you want to
3352 generally suppress enumeration literal names and for example you therefore
3353 use a ``Discard_Names`` pragma in the :file:`gnat.adc` file, but you
3354 want to retain the names for specific enumeration types.
3358 .. index:: License checking
3365 pragma License (Unrestricted | GPL | Modified_GPL | Restricted);
3368 This pragma is provided to allow automated checking for appropriate license
3369 conditions with respect to the standard and modified GPL. A pragma
3370 ``License``, which is a configuration pragma that typically appears at
3371 the start of a source file or in a separate :file:`gnat.adc` file, specifies
3372 the licensing conditions of a unit as follows:
3375 This is used for a unit that can be freely used with no license restrictions.
3376 Examples of such units are public domain units, and units from the Ada
3380 This is used for a unit that is licensed under the unmodified GPL, and which
3381 therefore cannot be ``with``\ ed by a restricted unit.
3384 This is used for a unit licensed under the GNAT modified GPL that includes
3385 a special exception paragraph that specifically permits the inclusion of
3386 the unit in programs without requiring the entire program to be released
3390 This is used for a unit that is restricted in that it is not permitted to
3391 depend on units that are licensed under the GPL. Typical examples are
3392 proprietary code that is to be released under more restrictive license
3393 conditions. Note that restricted units are permitted to ``with`` units
3394 which are licensed under the modified GPL (this is the whole point of the
3398 Normally a unit with no ``License`` pragma is considered to have an
3399 unknown license, and no checking is done. However, standard GNAT headers
3400 are recognized, and license information is derived from them as follows.
3402 A GNAT license header starts with a line containing 78 hyphens. The following
3403 comment text is searched for the appearance of any of the following strings.
3405 If the string 'GNU General Public License' is found, then the unit is assumed
3406 to have GPL license, unless the string 'As a special exception' follows, in
3407 which case the license is assumed to be modified GPL.
3409 If one of the strings
3410 'This specification is adapted from the Ada Semantic Interface' or
3411 'This specification is derived from the Ada Reference Manual' is found
3412 then the unit is assumed to be unrestricted.
3414 These default actions means that a program with a restricted license pragma
3415 will automatically get warnings if a GPL unit is inappropriately
3416 ``with``\ ed. For example, the program:
3422 procedure Secret_Stuff is
3427 if compiled with pragma ``License`` (``Restricted``) in a
3428 :file:`gnat.adc` file will generate the warning::
3432 >>> license of withed unit "Sem_Ch3" is incompatible
3434 2. with GNAT.Sockets;
3435 3. procedure Secret_Stuff is
3438 Here we get a warning on ``Sem_Ch3`` since it is part of the GNAT
3439 compiler and is licensed under the
3440 GPL, but no warning for ``GNAT.Sockets`` which is part of the GNAT
3441 run time, and is therefore licensed under the modified GPL.
3451 pragma Link_With (static_string_EXPRESSION {,static_string_EXPRESSION});
3454 This pragma is provided for compatibility with certain Ada 83 compilers.
3455 It has exactly the same effect as pragma ``Linker_Options`` except
3456 that spaces occurring within one of the string expressions are treated
3457 as separators. For example, in the following case:
3461 pragma Link_With ("-labc -ldef");
3464 results in passing the strings ``-labc`` and ``-ldef`` as two
3465 separate arguments to the linker. In addition pragma Link_With allows
3466 multiple arguments, with the same effect as successive pragmas.
3476 pragma Linker_Alias (
3477 [Entity =>] LOCAL_NAME,
3478 [Target =>] static_string_EXPRESSION);
3481 ``LOCAL_NAME`` must refer to an object that is declared at the library
3482 level. This pragma establishes the given entity as a linker alias for the
3483 given target. It is equivalent to ``__attribute__((alias))`` in GNU C
3484 and causes ``LOCAL_NAME`` to be emitted as an alias for the symbol
3485 ``static_string_EXPRESSION`` in the object file, that is to say no space
3486 is reserved for ``LOCAL_NAME`` by the assembler and it will be resolved
3487 to the same address as ``static_string_EXPRESSION`` by the linker.
3489 The actual linker name for the target must be used (e.g., the fully
3490 encoded name with qualification in Ada, or the mangled name in C++),
3491 or it must be declared using the C convention with ``pragma Import``
3492 or ``pragma Export``.
3494 Not all target machines support this pragma. On some of them it is accepted
3495 only if ``pragma Weak_External`` has been applied to ``LOCAL_NAME``.
3500 -- Example of the use of pragma Linker_Alias
3504 pragma Export (C, i);
3506 new_name_for_i : Integer;
3507 pragma Linker_Alias (new_name_for_i, "i");
3511 Pragma Linker_Constructor
3512 =========================
3519 pragma Linker_Constructor (procedure_LOCAL_NAME);
3522 ``procedure_LOCAL_NAME`` must refer to a parameterless procedure that
3523 is declared at the library level. A procedure to which this pragma is
3524 applied will be treated as an initialization routine by the linker.
3525 It is equivalent to ``__attribute__((constructor))`` in GNU C and
3526 causes ``procedure_LOCAL_NAME`` to be invoked before the entry point
3527 of the executable is called (or immediately after the shared library is
3528 loaded if the procedure is linked in a shared library), in particular
3529 before the Ada run-time environment is set up.
3531 Because of these specific contexts, the set of operations such a procedure
3532 can perform is very limited and the type of objects it can manipulate is
3533 essentially restricted to the elementary types. In particular, it must only
3534 contain code to which pragma Restrictions (No_Elaboration_Code) applies.
3536 This pragma is used by GNAT to implement auto-initialization of shared Stand
3537 Alone Libraries, which provides a related capability without the restrictions
3538 listed above. Where possible, the use of Stand Alone Libraries is preferable
3539 to the use of this pragma.
3541 Pragma Linker_Destructor
3542 ========================
3549 pragma Linker_Destructor (procedure_LOCAL_NAME);
3552 ``procedure_LOCAL_NAME`` must refer to a parameterless procedure that
3553 is declared at the library level. A procedure to which this pragma is
3554 applied will be treated as a finalization routine by the linker.
3555 It is equivalent to ``__attribute__((destructor))`` in GNU C and
3556 causes ``procedure_LOCAL_NAME`` to be invoked after the entry point
3557 of the executable has exited (or immediately before the shared library
3558 is unloaded if the procedure is linked in a shared library), in particular
3559 after the Ada run-time environment is shut down.
3561 See ``pragma Linker_Constructor`` for the set of restrictions that apply
3562 because of these specific contexts.
3564 .. _Pragma-Linker_Section:
3566 Pragma Linker_Section
3567 =====================
3574 pragma Linker_Section (
3575 [Entity =>] LOCAL_NAME,
3576 [Section =>] static_string_EXPRESSION);
3579 ``LOCAL_NAME`` must refer to an object, type, or subprogram that is
3580 declared at the library level. This pragma specifies the name of the
3581 linker section for the given entity. It is equivalent to
3582 ``__attribute__((section))`` in GNU C and causes ``LOCAL_NAME`` to
3583 be placed in the ``static_string_EXPRESSION`` section of the
3584 executable (assuming the linker doesn't rename the section).
3585 GNAT also provides an implementation defined aspect of the same name.
3587 In the case of specifying this aspect for a type, the effect is to
3588 specify the corresponding section for all library-level objects of
3589 the type that do not have an explicit linker section set. Note that
3590 this only applies to whole objects, not to components of composite objects.
3592 In the case of a subprogram, the linker section applies to all previously
3593 declared matching overloaded subprograms in the current declarative part
3594 which do not already have a linker section assigned. The linker section
3595 aspect is useful in this case for specifying different linker sections
3596 for different elements of such an overloaded set.
3598 Note that an empty string specifies that no linker section is specified.
3599 This is not quite the same as omitting the pragma or aspect, since it
3600 can be used to specify that one element of an overloaded set of subprograms
3601 has the default linker section, or that one object of a type for which a
3602 linker section is specified should has the default linker section.
3604 The compiler normally places library-level entities in standard sections
3605 depending on the class: procedures and functions generally go in the
3606 ``.text`` section, initialized variables in the ``.data`` section
3607 and uninitialized variables in the ``.bss`` section.
3609 Other, special sections may exist on given target machines to map special
3610 hardware, for example I/O ports or flash memory. This pragma is a means to
3611 defer the final layout of the executable to the linker, thus fully working
3612 at the symbolic level with the compiler.
3614 Some file formats do not support arbitrary sections so not all target
3615 machines support this pragma. The use of this pragma may cause a program
3616 execution to be erroneous if it is used to place an entity into an
3617 inappropriate section (e.g., a modified variable into the ``.text``
3618 section). See also ``pragma Persistent_BSS``.
3623 -- Example of the use of pragma Linker_Section
3627 pragma Volatile (Port_A);
3628 pragma Linker_Section (Port_A, ".bss.port_a");
3631 pragma Volatile (Port_B);
3632 pragma Linker_Section (Port_B, ".bss.port_b");
3634 type Port_Type is new Integer with Linker_Section => ".bss";
3635 PA : Port_Type with Linker_Section => ".bss.PA";
3636 PB : Port_Type; -- ends up in linker section ".bss"
3638 procedure Q with Linker_Section => "Qsection";
3641 .. _Pragma-Lock_Free:
3647 This pragma may be specified for protected types or objects. It specifies that
3648 the implementation of protected operations must be implemented without locks.
3649 Compilation fails if the compiler cannot generate lock-free code for the
3652 Pragma Loop_Invariant
3653 =====================
3660 pragma Loop_Invariant ( boolean_EXPRESSION );
3663 The effect of this pragma is similar to that of pragma ``Assert``,
3664 except that in an ``Assertion_Policy`` pragma, the identifier
3665 ``Loop_Invariant`` is used to control whether it is ignored or checked
3668 ``Loop_Invariant`` can only appear as one of the items in the sequence
3669 of statements of a loop body, or nested inside block statements that
3670 appear in the sequence of statements of a loop body.
3671 The intention is that it be used to
3672 represent a "loop invariant" assertion, i.e. something that is true each
3673 time through the loop, and which can be used to show that the loop is
3674 achieving its purpose.
3676 Multiple ``Loop_Invariant`` and ``Loop_Variant`` pragmas that
3677 apply to the same loop should be grouped in the same sequence of
3680 To aid in writing such invariants, the special attribute ``Loop_Entry``
3681 may be used to refer to the value of an expression on entry to the loop. This
3682 attribute can only be used within the expression of a ``Loop_Invariant``
3683 pragma. For full details, see documentation of attribute ``Loop_Entry``.
3685 Pragma Loop_Optimize
3686 ====================
3693 pragma Loop_Optimize (OPTIMIZATION_HINT {, OPTIMIZATION_HINT});
3695 OPTIMIZATION_HINT ::= Ivdep | No_Unroll | Unroll | No_Vector | Vector
3698 This pragma must appear immediately within a loop statement. It allows the
3699 programmer to specify optimization hints for the enclosing loop. The hints
3700 are not mutually exclusive and can be freely mixed, but not all combinations
3701 will yield a sensible outcome.
3703 There are five supported optimization hints for a loop:
3707 The programmer asserts that there are no loop-carried dependencies
3708 which would prevent consecutive iterations of the loop from being
3709 executed simultaneously.
3713 The loop must not be unrolled. This is a strong hint: the compiler will not
3714 unroll a loop marked with this hint.
3718 The loop should be unrolled. This is a weak hint: the compiler will try to
3719 apply unrolling to this loop preferably to other optimizations, notably
3720 vectorization, but there is no guarantee that the loop will be unrolled.
3724 The loop must not be vectorized. This is a strong hint: the compiler will not
3725 vectorize a loop marked with this hint.
3729 The loop should be vectorized. This is a weak hint: the compiler will try to
3730 apply vectorization to this loop preferably to other optimizations, notably
3731 unrolling, but there is no guarantee that the loop will be vectorized.
3734 These hints do not remove the need to pass the appropriate switches to the
3735 compiler in order to enable the relevant optimizations, that is to say
3736 *-funroll-loops* for unrolling and *-ftree-vectorize* for
3747 pragma Loop_Variant ( LOOP_VARIANT_ITEM {, LOOP_VARIANT_ITEM } );
3748 LOOP_VARIANT_ITEM ::= CHANGE_DIRECTION => discrete_EXPRESSION
3749 CHANGE_DIRECTION ::= Increases | Decreases
3752 ``Loop_Variant`` can only appear as one of the items in the sequence
3753 of statements of a loop body, or nested inside block statements that
3754 appear in the sequence of statements of a loop body.
3755 It allows the specification of quantities which must always
3756 decrease or increase in successive iterations of the loop. In its simplest
3757 form, just one expression is specified, whose value must increase or decrease
3758 on each iteration of the loop.
3760 In a more complex form, multiple arguments can be given which are intepreted
3761 in a nesting lexicographic manner. For example:
3765 pragma Loop_Variant (Increases => X, Decreases => Y);
3768 specifies that each time through the loop either X increases, or X stays
3769 the same and Y decreases. A ``Loop_Variant`` pragma ensures that the
3770 loop is making progress. It can be useful in helping to show informally
3771 or prove formally that the loop always terminates.
3773 ``Loop_Variant`` is an assertion whose effect can be controlled using
3774 an ``Assertion_Policy`` with a check name of ``Loop_Variant``. The
3775 policy can be ``Check`` to enable the loop variant check, ``Ignore``
3776 to ignore the check (in which case the pragma has no effect on the program),
3777 or ``Disable`` in which case the pragma is not even checked for correct
3780 Multiple ``Loop_Invariant`` and ``Loop_Variant`` pragmas that
3781 apply to the same loop should be grouped in the same sequence of
3784 The ``Loop_Entry`` attribute may be used within the expressions of the
3785 ``Loop_Variant`` pragma to refer to values on entry to the loop.
3787 Pragma Machine_Attribute
3788 ========================
3795 pragma Machine_Attribute (
3796 [Entity =>] LOCAL_NAME,
3797 [Attribute_Name =>] static_string_EXPRESSION
3798 [, [Info =>] static_EXPRESSION {, static_EXPRESSION}] );
3801 Machine-dependent attributes can be specified for types and/or
3802 declarations. This pragma is semantically equivalent to
3803 :samp:`__attribute__(({attribute_name}))` (if ``info`` is not
3804 specified) or :samp:`__attribute__(({attribute_name(info})))`
3805 or :samp:`__attribute__(({attribute_name(info,...})))` in GNU C,
3806 where *attribute_name* is recognized by the compiler middle-end
3807 or the ``TARGET_ATTRIBUTE_TABLE`` machine specific macro. Note
3808 that a string literal for the optional parameter ``info`` or the
3809 following ones is transformed by default into an identifier,
3810 which may make this pragma unusable for some attributes.
3811 For further information see :title:`GNU Compiler Collection (GCC) Internals`.
3819 (MAIN_OPTION [, MAIN_OPTION]);
3822 [Stack_Size =>] static_integer_EXPRESSION
3823 | [Task_Stack_Size_Default =>] static_integer_EXPRESSION
3824 | [Time_Slicing_Enabled =>] static_boolean_EXPRESSION
3827 This pragma is provided for compatibility with OpenVMS VAX Systems. It has
3828 no effect in GNAT, other than being syntax checked.
3836 (MAIN_STORAGE_OPTION [, MAIN_STORAGE_OPTION]);
3838 MAIN_STORAGE_OPTION ::=
3839 [WORKING_STORAGE =>] static_SIMPLE_EXPRESSION
3840 | [TOP_GUARD =>] static_SIMPLE_EXPRESSION
3843 This pragma is provided for compatibility with OpenVMS VAX Systems. It has
3844 no effect in GNAT, other than being syntax checked.
3846 .. _Pragma-Max_Queue_Length:
3848 Pragma Max_Queue_Length
3849 =======================
3853 pragma Max_Entry_Queue (static_integer_EXPRESSION);
3856 This pragma is used to specify the maximum callers per entry queue for
3857 individual protected entries and entry families. It accepts a single
3858 positive integer as a parameter and must appear after the declaration
3872 There are a number of cases in which a package spec does not require a body,
3873 and in fact a body is not permitted. GNAT will not permit the spec to be
3874 compiled if there is a body around. The pragma No_Body allows you to provide
3875 a body file, even in a case where no body is allowed. The body file must
3876 contain only comments and a single No_Body pragma. This is recognized by
3877 the compiler as indicating that no body is logically present.
3879 This is particularly useful during maintenance when a package is modified in
3880 such a way that a body needed before is no longer needed. The provision of a
3881 dummy body with a No_Body pragma ensures that there is no interference from
3882 earlier versions of the package body.
3884 Pragma No_Component_Reordering
3885 ==============================
3892 pragma No_Component_Reordering [([Entity =>] type_LOCAL_NAME)];
3895 ``type_LOCAL_NAME`` must refer to a record type declaration in the current
3896 declarative part. The effect is to preclude any reordering of components
3897 for the layout of the record, i.e. the record is laid out by the compiler
3898 in the order in which the components are declared textually. The form with
3899 no argument is a configuration pragma which applies to all record types
3900 declared in units to which the pragma applies and there is a requirement
3901 that this pragma be used consistently within a partition.
3903 .. _Pragma-No_Elaboration_Code_All:
3905 Pragma No_Elaboration_Code_All
3906 ==============================
3913 pragma No_Elaboration_Code_All [(program_unit_NAME)];
3916 This is a program unit pragma (there is also an equivalent aspect of the
3917 same name) that establishes the restriction ``No_Elaboration_Code`` for
3918 the current unit and any extended main source units (body and subunits).
3919 It also has the effect of enforcing a transitive application of this
3920 aspect, so that if any unit is implicitly or explicitly with'ed by the
3921 current unit, it must also have the No_Elaboration_Code_All aspect set.
3922 It may be applied to package or subprogram specs or their generic versions.
3924 Pragma No_Heap_Finalization
3925 ===========================
3932 pragma No_Heap_Finalization [ (first_subtype_LOCAL_NAME) ];
3935 Pragma ``No_Heap_Finalization`` may be used as a configuration pragma or as a
3936 type-specific pragma.
3938 In its configuration form, the pragma must appear within a configuration file
3939 such as gnat.adc, without an argument. The pragma suppresses the call to
3940 ``Finalize`` for heap-allocated objects created through library-level named
3941 access-to-object types in cases where the designated type requires finalization
3944 In its type-specific form, the argument of the pragma must denote a
3945 library-level named access-to-object type. The pragma suppresses the call to
3946 ``Finalize`` for heap-allocated objects created through the specific access type
3947 in cases where the designated type requires finalization actions.
3949 It is still possible to finalize such heap-allocated objects by explicitly
3952 A library-level named access-to-object type declared within a generic unit will
3953 lose its ``No_Heap_Finalization`` pragma when the corresponding instance does not
3954 appear at the library level.
3956 .. _Pragma-No_Inline:
3966 pragma No_Inline (NAME {, NAME});
3969 This pragma suppresses inlining for the callable entity or the instances of
3970 the generic subprogram designated by ``NAME``, including inlining that
3971 results from the use of pragma ``Inline``. This pragma is always active,
3972 in particular it is not subject to the use of option *-gnatn* or
3973 *-gnatN*. It is illegal to specify both pragma ``No_Inline`` and
3974 pragma ``Inline_Always`` for the same ``NAME``.
3984 pragma No_Return (procedure_LOCAL_NAME {, procedure_LOCAL_NAME});
3987 Each ``procedure_LOCAL_NAME`` argument must refer to one or more procedure
3988 declarations in the current declarative part. A procedure to which this
3989 pragma is applied may not contain any explicit ``return`` statements.
3990 In addition, if the procedure contains any implicit returns from falling
3991 off the end of a statement sequence, then execution of that implicit
3992 return will cause Program_Error to be raised.
3994 One use of this pragma is to identify procedures whose only purpose is to raise
3995 an exception. Another use of this pragma is to suppress incorrect warnings
3996 about missing returns in functions, where the last statement of a function
3997 statement sequence is a call to such a procedure.
3999 Note that in Ada 2005 mode, this pragma is part of the language. It is
4000 available in all earlier versions of Ada as an implementation-defined
4014 This is an obsolete configuration pragma that historically was used to
4015 set up a runtime library with no object code. It is now used only for
4016 internal testing. The pragma has been superseded by the reconfigurable
4017 runtime capability of GNAT.
4019 Pragma No_Strict_Aliasing
4020 =========================
4027 pragma No_Strict_Aliasing [([Entity =>] type_LOCAL_NAME)];
4030 ``type_LOCAL_NAME`` must refer to an access type
4031 declaration in the current declarative part. The effect is to inhibit
4032 strict aliasing optimization for the given type. The form with no
4033 arguments is a configuration pragma which applies to all access types
4034 declared in units to which the pragma applies. For a detailed
4035 description of the strict aliasing optimization, and the situations
4036 in which it must be suppressed, see the section on Optimization and Strict Aliasing
4037 in the :title:`GNAT User's Guide`.
4039 This pragma currently has no effects on access to unconstrained array types.
4041 .. _Pragma-No_Tagged_Streams:
4043 Pragma No_Tagged_Streams
4044 ========================
4051 pragma No_Tagged_Streams [([Entity =>] tagged_type_LOCAL_NAME)];
4054 Normally when a tagged type is introduced using a full type declaration,
4055 part of the processing includes generating stream access routines to be
4056 used by stream attributes referencing the type (or one of its subtypes
4057 or derived types). This can involve the generation of significant amounts
4058 of code which is wasted space if stream routines are not needed for the
4061 The ``No_Tagged_Streams`` pragma causes the generation of these stream
4062 routines to be skipped, and any attempt to use stream operations on
4063 types subject to this pragma will be statically rejected as illegal.
4065 There are two forms of the pragma. The form with no arguments must appear
4066 in a declarative sequence or in the declarations of a package spec. This
4067 pragma affects all subsequent root tagged types declared in the declaration
4068 sequence, and specifies that no stream routines be generated. The form with
4069 an argument (for which there is also a corresponding aspect) specifies a
4070 single root tagged type for which stream routines are not to be generated.
4072 Once the pragma has been given for a particular root tagged type, all subtypes
4073 and derived types of this type inherit the pragma automatically, so the effect
4074 applies to a complete hierarchy (this is necessary to deal with the class-wide
4075 dispatching versions of the stream routines).
4077 When pragmas ``Discard_Names`` and ``No_Tagged_Streams`` are simultaneously
4078 applied to a tagged type its Expanded_Name and External_Tag are initialized
4079 with empty strings. This is useful to avoid exposing entity names at binary
4080 level but has a negative impact on the debuggability of tagged types.
4082 Pragma Normalize_Scalars
4083 ========================
4090 pragma Normalize_Scalars;
4093 This is a language defined pragma which is fully implemented in GNAT. The
4094 effect is to cause all scalar objects that are not otherwise initialized
4095 to be initialized. The initial values are implementation dependent and
4100 *Standard.Character*
4101 Objects whose root type is Standard.Character are initialized to
4102 Character'Last unless the subtype range excludes NUL (in which case
4103 NUL is used). This choice will always generate an invalid value if
4107 *Standard.Wide_Character*
4108 Objects whose root type is Standard.Wide_Character are initialized to
4109 Wide_Character'Last unless the subtype range excludes NUL (in which case
4110 NUL is used). This choice will always generate an invalid value if
4114 *Standard.Wide_Wide_Character*
4115 Objects whose root type is Standard.Wide_Wide_Character are initialized to
4116 the invalid value 16#FFFF_FFFF# unless the subtype range excludes NUL (in
4117 which case NUL is used). This choice will always generate an invalid value if
4122 Objects of an integer type are treated differently depending on whether
4123 negative values are present in the subtype. If no negative values are
4124 present, then all one bits is used as the initial value except in the
4125 special case where zero is excluded from the subtype, in which case
4126 all zero bits are used. This choice will always generate an invalid
4127 value if one exists.
4129 For subtypes with negative values present, the largest negative number
4130 is used, except in the unusual case where this largest negative number
4131 is in the subtype, and the largest positive number is not, in which case
4132 the largest positive value is used. This choice will always generate
4133 an invalid value if one exists.
4136 *Floating-Point Types*
4137 Objects of all floating-point types are initialized to all 1-bits. For
4138 standard IEEE format, this corresponds to a NaN (not a number) which is
4139 indeed an invalid value.
4143 Objects of all fixed-point types are treated as described above for integers,
4144 with the rules applying to the underlying integer value used to represent
4145 the fixed-point value.
4149 Objects of a modular type are initialized to all one bits, except in
4150 the special case where zero is excluded from the subtype, in which
4151 case all zero bits are used. This choice will always generate an
4152 invalid value if one exists.
4156 Objects of an enumeration type are initialized to all one-bits, i.e., to
4157 the value ``2 ** typ'Size - 1`` unless the subtype excludes the literal
4158 whose Pos value is zero, in which case a code of zero is used. This choice
4159 will always generate an invalid value if one exists.
4161 .. _Pragma_Obsolescent:
4173 pragma Obsolescent (
4174 [Message =>] static_string_EXPRESSION
4175 [,[Version =>] Ada_05]]);
4177 pragma Obsolescent (
4179 [,[Message =>] static_string_EXPRESSION
4180 [,[Version =>] Ada_05]] );
4183 This pragma can occur immediately following a declaration of an entity,
4184 including the case of a record component. If no Entity argument is present,
4185 then this declaration is the one to which the pragma applies. If an Entity
4186 parameter is present, it must either match the name of the entity in this
4187 declaration, or alternatively, the pragma can immediately follow an enumeration
4188 type declaration, where the Entity argument names one of the enumeration
4191 This pragma is used to indicate that the named entity
4192 is considered obsolescent and should not be used. Typically this is
4193 used when an API must be modified by eventually removing or modifying
4194 existing subprograms or other entities. The pragma can be used at an
4195 intermediate stage when the entity is still present, but will be
4198 The effect of this pragma is to output a warning message on a reference to
4199 an entity thus marked that the subprogram is obsolescent if the appropriate
4200 warning option in the compiler is activated. If the ``Message`` parameter is
4201 present, then a second warning message is given containing this text. In
4202 addition, a reference to the entity is considered to be a violation of pragma
4203 ``Restrictions (No_Obsolescent_Features)``.
4205 This pragma can also be used as a program unit pragma for a package,
4206 in which case the entity name is the name of the package, and the
4207 pragma indicates that the entire package is considered
4208 obsolescent. In this case a client ``with``\ ing such a package
4209 violates the restriction, and the ``with`` clause is
4210 flagged with warnings if the warning option is set.
4212 If the ``Version`` parameter is present (which must be exactly
4213 the identifier ``Ada_05``, no other argument is allowed), then the
4214 indication of obsolescence applies only when compiling in Ada 2005
4215 mode. This is primarily intended for dealing with the situations
4216 in the predefined library where subprograms or packages
4217 have become defined as obsolescent in Ada 2005
4218 (e.g., in ``Ada.Characters.Handling``), but may be used anywhere.
4220 The following examples show typical uses of this pragma:
4226 pragma Obsolescent (p, Message => "use pp instead of p");
4231 pragma Obsolescent ("use q2new instead");
4233 type R is new integer;
4236 Message => "use RR in Ada 2005",
4246 type E is (a, bc, 'd', quack);
4247 pragma Obsolescent (Entity => bc)
4248 pragma Obsolescent (Entity => 'd')
4251 (a, b : character) return character;
4252 pragma Obsolescent (Entity => "+");
4256 Note that, as for all pragmas, if you use a pragma argument identifier,
4257 then all subsequent parameters must also use a pragma argument identifier.
4258 So if you specify ``Entity =>`` for the ``Entity`` argument, and a ``Message``
4259 argument is present, it must be preceded by ``Message =>``.
4261 Pragma Optimize_Alignment
4262 =========================
4263 .. index:: Alignment, default settings
4270 pragma Optimize_Alignment (TIME | SPACE | OFF);
4273 This is a configuration pragma which affects the choice of default alignments
4274 for types and objects where no alignment is explicitly specified. There is a
4275 time/space trade-off in the selection of these values. Large alignments result
4276 in more efficient code, at the expense of larger data space, since sizes have
4277 to be increased to match these alignments. Smaller alignments save space, but
4278 the access code is slower. The normal choice of default alignments for types
4279 and individual alignment promotions for objects (which is what you get if you
4280 do not use this pragma, or if you use an argument of OFF), tries to balance
4281 these two requirements.
4283 Specifying SPACE causes smaller default alignments to be chosen in two cases.
4284 First any packed record is given an alignment of 1. Second, if a size is given
4285 for the type, then the alignment is chosen to avoid increasing this size. For
4299 In the default mode, this type gets an alignment of 4, so that access to the
4300 Integer field X are efficient. But this means that objects of the type end up
4301 with a size of 8 bytes. This is a valid choice, since sizes of objects are
4302 allowed to be bigger than the size of the type, but it can waste space if for
4303 example fields of type R appear in an enclosing record. If the above type is
4304 compiled in ``Optimize_Alignment (Space)`` mode, the alignment is set to 1.
4306 However, there is one case in which SPACE is ignored. If a variable length
4307 record (that is a discriminated record with a component which is an array
4308 whose length depends on a discriminant), has a pragma Pack, then it is not
4309 in general possible to set the alignment of such a record to one, so the
4310 pragma is ignored in this case (with a warning).
4312 Specifying SPACE also disables alignment promotions for standalone objects,
4313 which occur when the compiler increases the alignment of a specific object
4314 without changing the alignment of its type.
4316 Specifying SPACE also disables component reordering in unpacked record types,
4317 which can result in larger sizes in order to meet alignment requirements.
4319 Specifying TIME causes larger default alignments to be chosen in the case of
4320 small types with sizes that are not a power of 2. For example, consider:
4335 The default alignment for this record is normally 1, but if this type is
4336 compiled in ``Optimize_Alignment (Time)`` mode, then the alignment is set
4337 to 4, which wastes space for objects of the type, since they are now 4 bytes
4338 long, but results in more efficient access when the whole record is referenced.
4340 As noted above, this is a configuration pragma, and there is a requirement
4341 that all units in a partition be compiled with a consistent setting of the
4342 optimization setting. This would normally be achieved by use of a configuration
4343 pragma file containing the appropriate setting. The exception to this rule is
4344 that units with an explicit configuration pragma in the same file as the source
4345 unit are excluded from the consistency check, as are all predefined units. The
4346 latter are compiled by default in pragma Optimize_Alignment (Off) mode if no
4347 pragma appears at the start of the file.
4357 pragma Ordered (enumeration_first_subtype_LOCAL_NAME);
4360 Most enumeration types are from a conceptual point of view unordered.
4361 For example, consider:
4366 type Color is (Red, Blue, Green, Yellow);
4369 By Ada semantics ``Blue > Red`` and ``Green > Blue``,
4370 but really these relations make no sense; the enumeration type merely
4371 specifies a set of possible colors, and the order is unimportant.
4373 For unordered enumeration types, it is generally a good idea if
4374 clients avoid comparisons (other than equality or inequality) and
4375 explicit ranges. (A *client* is a unit where the type is referenced,
4376 other than the unit where the type is declared, its body, and its subunits.)
4377 For example, if code buried in some client says:
4382 if Current_Color < Yellow then ...
4383 if Current_Color in Blue .. Green then ...
4386 then the client code is relying on the order, which is undesirable.
4387 It makes the code hard to read and creates maintenance difficulties if
4388 entries have to be added to the enumeration type. Instead,
4389 the code in the client should list the possibilities, or an
4390 appropriate subtype should be declared in the unit that declares
4391 the original enumeration type. E.g., the following subtype could
4392 be declared along with the type ``Color``:
4397 subtype RBG is Color range Red .. Green;
4400 and then the client could write:
4405 if Current_Color in RBG then ...
4406 if Current_Color = Blue or Current_Color = Green then ...
4409 However, some enumeration types are legitimately ordered from a conceptual
4410 point of view. For example, if you declare:
4415 type Day is (Mon, Tue, Wed, Thu, Fri, Sat, Sun);
4418 then the ordering imposed by the language is reasonable, and
4419 clients can depend on it, writing for example:
4424 if D in Mon .. Fri then ...
4428 The pragma *Ordered* is provided to mark enumeration types that
4429 are conceptually ordered, alerting the reader that clients may depend
4430 on the ordering. GNAT provides a pragma to mark enumerations as ordered
4431 rather than one to mark them as unordered, since in our experience,
4432 the great majority of enumeration types are conceptually unordered.
4434 The types ``Boolean``, ``Character``, ``Wide_Character``,
4435 and ``Wide_Wide_Character``
4436 are considered to be ordered types, so each is declared with a
4437 pragma ``Ordered`` in package ``Standard``.
4439 Normally pragma ``Ordered`` serves only as documentation and a guide for
4440 coding standards, but GNAT provides a warning switch *-gnatw.u* that
4441 requests warnings for inappropriate uses (comparisons and explicit
4442 subranges) for unordered types. If this switch is used, then any
4443 enumeration type not marked with pragma ``Ordered`` will be considered
4444 as unordered, and will generate warnings for inappropriate uses.
4446 Note that generic types are not considered ordered or unordered (since the
4447 template can be instantiated for both cases), so we never generate warnings
4448 for the case of generic enumerated types.
4450 For additional information please refer to the description of the
4451 *-gnatw.u* switch in the GNAT User's Guide.
4453 Pragma Overflow_Mode
4454 ====================
4461 pragma Overflow_Mode
4463 [,[Assertions =>] MODE]);
4465 MODE ::= STRICT | MINIMIZED | ELIMINATED
4468 This pragma sets the current overflow mode to the given setting. For details
4469 of the meaning of these modes, please refer to the
4470 'Overflow Check Handling in GNAT' appendix in the
4471 GNAT User's Guide. If only the ``General`` parameter is present,
4472 the given mode applies to all expressions. If both parameters are present,
4473 the ``General`` mode applies to expressions outside assertions, and
4474 the ``Eliminated`` mode applies to expressions within assertions.
4476 The case of the ``MODE`` parameter is ignored,
4477 so ``MINIMIZED``, ``Minimized`` and
4478 ``minimized`` all have the same effect.
4480 The ``Overflow_Mode`` pragma has the same scoping and placement
4481 rules as pragma ``Suppress``, so it can occur either as a
4482 configuration pragma, specifying a default for the whole
4483 program, or in a declarative scope, where it applies to the
4484 remaining declarations and statements in that scope.
4486 The pragma ``Suppress (Overflow_Check)`` suppresses
4487 overflow checking, but does not affect the overflow mode.
4489 The pragma ``Unsuppress (Overflow_Check)`` unsuppresses (enables)
4490 overflow checking, but does not affect the overflow mode.
4492 Pragma Overriding_Renamings
4493 ===========================
4494 .. index:: Rational profile
4496 .. index:: Rational compatibility
4503 pragma Overriding_Renamings;
4506 This is a GNAT configuration pragma to simplify porting
4507 legacy code accepted by the Rational
4508 Ada compiler. In the presence of this pragma, a renaming declaration that
4509 renames an inherited operation declared in the same scope is legal if selected
4510 notation is used as in:
4515 pragma Overriding_Renamings;
4520 function F (..) renames R.F;
4525 RM 8.3 (15) stipulates that an overridden operation is not visible within the
4526 declaration of the overriding operation.
4528 Pragma Partition_Elaboration_Policy
4529 ===================================
4536 pragma Partition_Elaboration_Policy (POLICY_IDENTIFIER);
4538 POLICY_IDENTIFIER ::= Concurrent | Sequential
4541 This pragma is standard in Ada 2005, but is available in all earlier
4542 versions of Ada as an implementation-defined pragma.
4543 See Ada 2012 Reference Manual for details.
4554 pragma Part_Of (ABSTRACT_STATE);
4556 ABSTRACT_STATE ::= NAME
4558 For the semantics of this pragma, see the entry for aspect ``Part_Of`` in the
4559 SPARK 2014 Reference Manual, section 7.2.6.
4569 pragma Passive [(Semaphore | No)];
4572 Syntax checked, but otherwise ignored by GNAT. This is recognized for
4573 compatibility with DEC Ada 83 implementations, where it is used within a
4574 task definition to request that a task be made passive. If the argument
4575 ``Semaphore`` is present, or the argument is omitted, then DEC Ada 83
4576 treats the pragma as an assertion that the containing task is passive
4577 and that optimization of context switch with this task is permitted and
4578 desired. If the argument ``No`` is present, the task must not be
4579 optimized. GNAT does not attempt to optimize any tasks in this manner
4580 (since protected objects are available in place of passive tasks).
4582 For more information on the subject of passive tasks, see the section
4583 'Passive Task Optimization' in the GNAT Users Guide.
4585 .. _Pragma-Persistent_BSS:
4587 Pragma Persistent_BSS
4588 =====================
4595 pragma Persistent_BSS [(LOCAL_NAME)]
4598 This pragma allows selected objects to be placed in the ``.persistent_bss``
4599 section. On some targets the linker and loader provide for special
4600 treatment of this section, allowing a program to be reloaded without
4601 affecting the contents of this data (hence the name persistent).
4603 There are two forms of usage. If an argument is given, it must be the
4604 local name of a library-level object, with no explicit initialization
4605 and whose type is potentially persistent. If no argument is given, then
4606 the pragma is a configuration pragma, and applies to all library-level
4607 objects with no explicit initialization of potentially persistent types.
4609 A potentially persistent type is a scalar type, or an untagged,
4610 non-discriminated record, all of whose components have no explicit
4611 initialization and are themselves of a potentially persistent type,
4612 or an array, all of whose constraints are static, and whose component
4613 type is potentially persistent.
4615 If this pragma is used on a target where this feature is not supported,
4616 then the pragma will be ignored. See also ``pragma Linker_Section``.
4626 pragma Polling (ON | OFF);
4629 This pragma controls the generation of polling code. This is normally off.
4630 If ``pragma Polling (ON)`` is used then periodic calls are generated to
4631 the routine ``Ada.Exceptions.Poll``. This routine is a separate unit in the
4632 runtime library, and can be found in file :file:`a-excpol.adb`.
4634 Pragma ``Polling`` can appear as a configuration pragma (for example it
4635 can be placed in the :file:`gnat.adc` file) to enable polling globally, or it
4636 can be used in the statement or declaration sequence to control polling
4639 A call to the polling routine is generated at the start of every loop and
4640 at the start of every subprogram call. This guarantees that the ``Poll``
4641 routine is called frequently, and places an upper bound (determined by
4642 the complexity of the code) on the period between two ``Poll`` calls.
4644 The primary purpose of the polling interface is to enable asynchronous
4645 aborts on targets that cannot otherwise support it (for example Windows
4646 NT), but it may be used for any other purpose requiring periodic polling.
4647 The standard version is null, and can be replaced by a user program. This
4648 will require re-compilation of the ``Ada.Exceptions`` package that can
4649 be found in files :file:`a-except.ads` and :file:`a-except.adb`.
4651 A standard alternative unit (in file :file:`4wexcpol.adb` in the standard GNAT
4652 distribution) is used to enable the asynchronous abort capability on
4653 targets that do not normally support the capability. The version of
4654 ``Poll`` in this file makes a call to the appropriate runtime routine
4655 to test for an abort condition.
4657 Note that polling can also be enabled by use of the *-gnatP* switch.
4658 See the section on switches for gcc in the :title:`GNAT User's Guide`.
4664 .. index:: Checks, postconditions
4672 pragma Post (Boolean_Expression);
4675 The ``Post`` pragma is intended to be an exact replacement for
4676 the language-defined
4677 ``Post`` aspect, and shares its restrictions and semantics.
4678 It must appear either immediately following the corresponding
4679 subprogram declaration (only other pragmas may intervene), or
4680 if there is no separate subprogram declaration, then it can
4681 appear at the start of the declarations in a subprogram body
4682 (preceded only by other pragmas).
4684 Pragma Postcondition
4685 ====================
4686 .. index:: Postcondition
4688 .. index:: Checks, postconditions
4696 pragma Postcondition (
4697 [Check =>] Boolean_Expression
4698 [,[Message =>] String_Expression]);
4701 The ``Postcondition`` pragma allows specification of automatic
4702 postcondition checks for subprograms. These checks are similar to
4703 assertions, but are automatically inserted just prior to the return
4704 statements of the subprogram with which they are associated (including
4705 implicit returns at the end of procedure bodies and associated
4706 exception handlers).
4708 In addition, the boolean expression which is the condition which
4709 must be true may contain references to function'Result in the case
4710 of a function to refer to the returned value.
4712 ``Postcondition`` pragmas may appear either immediately following the
4713 (separate) declaration of a subprogram, or at the start of the
4714 declarations of a subprogram body. Only other pragmas may intervene
4715 (that is appear between the subprogram declaration and its
4716 postconditions, or appear before the postcondition in the
4717 declaration sequence in a subprogram body). In the case of a
4718 postcondition appearing after a subprogram declaration, the
4719 formal arguments of the subprogram are visible, and can be
4720 referenced in the postcondition expressions.
4722 The postconditions are collected and automatically tested just
4723 before any return (implicit or explicit) in the subprogram body.
4724 A postcondition is only recognized if postconditions are active
4725 at the time the pragma is encountered. The compiler switch *gnata*
4726 turns on all postconditions by default, and pragma ``Check_Policy``
4727 with an identifier of ``Postcondition`` can also be used to
4728 control whether postconditions are active.
4730 The general approach is that postconditions are placed in the spec
4731 if they represent functional aspects which make sense to the client.
4732 For example we might have:
4737 function Direction return Integer;
4738 pragma Postcondition
4739 (Direction'Result = +1
4741 Direction'Result = -1);
4744 which serves to document that the result must be +1 or -1, and
4745 will test that this is the case at run time if postcondition
4748 Postconditions within the subprogram body can be used to
4749 check that some internal aspect of the implementation,
4750 not visible to the client, is operating as expected.
4751 For instance if a square root routine keeps an internal
4752 counter of the number of times it is called, then we
4753 might have the following postcondition:
4758 Sqrt_Calls : Natural := 0;
4760 function Sqrt (Arg : Float) return Float is
4761 pragma Postcondition
4762 (Sqrt_Calls = Sqrt_Calls'Old + 1);
4767 As this example, shows, the use of the ``Old`` attribute
4768 is often useful in postconditions to refer to the state on
4769 entry to the subprogram.
4771 Note that postconditions are only checked on normal returns
4772 from the subprogram. If an abnormal return results from
4773 raising an exception, then the postconditions are not checked.
4775 If a postcondition fails, then the exception
4776 ``System.Assertions.Assert_Failure`` is raised. If
4777 a message argument was supplied, then the given string
4778 will be used as the exception message. If no message
4779 argument was supplied, then the default message has
4780 the form "Postcondition failed at file_name:line". The
4781 exception is raised in the context of the subprogram
4782 body, so it is possible to catch postcondition failures
4783 within the subprogram body itself.
4785 Within a package spec, normal visibility rules
4786 in Ada would prevent forward references within a
4787 postcondition pragma to functions defined later in
4788 the same package. This would introduce undesirable
4789 ordering constraints. To avoid this problem, all
4790 postcondition pragmas are analyzed at the end of
4791 the package spec, allowing forward references.
4793 The following example shows that this even allows
4794 mutually recursive postconditions as in:
4799 package Parity_Functions is
4800 function Odd (X : Natural) return Boolean;
4801 pragma Postcondition
4805 (x /= 0 and then Even (X - 1))));
4807 function Even (X : Natural) return Boolean;
4808 pragma Postcondition
4812 (x /= 1 and then Odd (X - 1))));
4814 end Parity_Functions;
4817 There are no restrictions on the complexity or form of
4818 conditions used within ``Postcondition`` pragmas.
4819 The following example shows that it is even possible
4820 to verify performance behavior.
4827 Performance : constant Float;
4828 -- Performance constant set by implementation
4829 -- to match target architecture behavior.
4831 procedure Treesort (Arg : String);
4832 -- Sorts characters of argument using N*logN sort
4833 pragma Postcondition
4834 (Float (Clock - Clock'Old) <=
4835 Float (Arg'Length) *
4836 log (Float (Arg'Length)) *
4841 Note: postcondition pragmas associated with subprograms that are
4842 marked as Inline_Always, or those marked as Inline with front-end
4843 inlining (-gnatN option set) are accepted and legality-checked
4844 by the compiler, but are ignored at run-time even if postcondition
4845 checking is enabled.
4847 Note that pragma ``Postcondition`` differs from the language-defined
4848 ``Post`` aspect (and corresponding ``Post`` pragma) in allowing
4849 multiple occurrences, allowing occurences in the body even if there
4850 is a separate spec, and allowing a second string parameter, and the
4851 use of the pragma identifier ``Check``. Historically, pragma
4852 ``Postcondition`` was implemented prior to the development of
4853 Ada 2012, and has been retained in its original form for
4854 compatibility purposes.
4860 .. index:: Checks, postconditions
4868 pragma Post_Class (Boolean_Expression);
4871 The ``Post_Class`` pragma is intended to be an exact replacement for
4872 the language-defined
4873 ``Post'Class`` aspect, and shares its restrictions and semantics.
4874 It must appear either immediately following the corresponding
4875 subprogram declaration (only other pragmas may intervene), or
4876 if there is no separate subprogram declaration, then it can
4877 appear at the start of the declarations in a subprogram body
4878 (preceded only by other pragmas).
4880 Note: This pragma is called ``Post_Class`` rather than
4881 ``Post'Class`` because the latter would not be strictly
4882 conforming to the allowed syntax for pragmas. The motivation
4883 for provinding pragmas equivalent to the aspects is to allow a program
4884 to be written using the pragmas, and then compiled if necessary
4885 using an Ada compiler that does not recognize the pragmas or
4886 aspects, but is prepared to ignore the pragmas. The assertion
4887 policy that controls this pragma is ``Post'Class``, not
4890 Pragma Rename_Pragma
4891 ============================
4892 .. index:: Pragmas, synonyms
4899 pragma Rename_Pragma (
4900 [New_Name =>] IDENTIFIER,
4901 [Renamed =>] pragma_IDENTIFIER);
4903 This pragma provides a mechanism for supplying new names for existing
4904 pragmas. The ``New_Name`` identifier can subsequently be used as a synonym for
4905 the Renamed pragma. For example, suppose you have code that was originally
4906 developed on a compiler that supports Inline_Only as an implementation defined
4907 pragma. And suppose the semantics of pragma Inline_Only are identical to (or at
4908 least very similar to) the GNAT implementation defined pragma
4909 Inline_Always. You could globally replace Inline_Only with Inline_Always.
4911 However, to avoid that source modification, you could instead add a
4912 configuration pragma:
4916 pragma Rename_Pragma (
4917 New_Name => Inline_Only,
4918 Renamed => Inline_Always);
4921 Then GNAT will treat "pragma Inline_Only ..." as if you had written
4922 "pragma Inline_Always ...".
4924 Pragma Inline_Only will not necessarily mean the same thing as the other Ada
4925 compiler; it's up to you to make sure the semantics are close enough.
4931 .. index:: Checks, preconditions
4939 pragma Pre (Boolean_Expression);
4942 The ``Pre`` pragma is intended to be an exact replacement for
4943 the language-defined
4944 ``Pre`` aspect, and shares its restrictions and semantics.
4945 It must appear either immediately following the corresponding
4946 subprogram declaration (only other pragmas may intervene), or
4947 if there is no separate subprogram declaration, then it can
4948 appear at the start of the declarations in a subprogram body
4949 (preceded only by other pragmas).
4953 .. index:: Preconditions
4955 .. index:: Checks, preconditions
4963 pragma Precondition (
4964 [Check =>] Boolean_Expression
4965 [,[Message =>] String_Expression]);
4968 The ``Precondition`` pragma is similar to ``Postcondition``
4969 except that the corresponding checks take place immediately upon
4970 entry to the subprogram, and if a precondition fails, the exception
4971 is raised in the context of the caller, and the attribute 'Result
4972 cannot be used within the precondition expression.
4974 Otherwise, the placement and visibility rules are identical to those
4975 described for postconditions. The following is an example of use
4976 within a package spec:
4981 package Math_Functions is
4983 function Sqrt (Arg : Float) return Float;
4984 pragma Precondition (Arg >= 0.0)
4989 ``Precondition`` pragmas may appear either immediately following the
4990 (separate) declaration of a subprogram, or at the start of the
4991 declarations of a subprogram body. Only other pragmas may intervene
4992 (that is appear between the subprogram declaration and its
4993 postconditions, or appear before the postcondition in the
4994 declaration sequence in a subprogram body).
4996 Note: precondition pragmas associated with subprograms that are
4997 marked as Inline_Always, or those marked as Inline with front-end
4998 inlining (-gnatN option set) are accepted and legality-checked
4999 by the compiler, but are ignored at run-time even if precondition
5000 checking is enabled.
5002 Note that pragma ``Precondition`` differs from the language-defined
5003 ``Pre`` aspect (and corresponding ``Pre`` pragma) in allowing
5004 multiple occurrences, allowing occurences in the body even if there
5005 is a separate spec, and allowing a second string parameter, and the
5006 use of the pragma identifier ``Check``. Historically, pragma
5007 ``Precondition`` was implemented prior to the development of
5008 Ada 2012, and has been retained in its original form for
5009 compatibility purposes.
5011 .. _Pragma-Predicate:
5022 ([Entity =>] type_LOCAL_NAME,
5023 [Check =>] EXPRESSION);
5026 This pragma (available in all versions of Ada in GNAT) encompasses both
5027 the ``Static_Predicate`` and ``Dynamic_Predicate`` aspects in
5028 Ada 2012. A predicate is regarded as static if it has an allowed form
5029 for ``Static_Predicate`` and is otherwise treated as a
5030 ``Dynamic_Predicate``. Otherwise, predicates specified by this
5031 pragma behave exactly as described in the Ada 2012 reference manual.
5032 For example, if we have
5037 type R is range 1 .. 10;
5039 pragma Predicate (Entity => S, Check => S not in 4 .. 6);
5041 pragma Predicate (Entity => Q, Check => F(Q) or G(Q));
5044 the effect is identical to the following Ada 2012 code:
5049 type R is range 1 .. 10;
5051 Static_Predicate => S not in 4 .. 6;
5053 Dynamic_Predicate => F(Q) or G(Q);
5056 Note that there are no pragmas ``Dynamic_Predicate``
5057 or ``Static_Predicate``. That is
5058 because these pragmas would affect legality and semantics of
5059 the program and thus do not have a neutral effect if ignored.
5060 The motivation behind providing pragmas equivalent to
5061 corresponding aspects is to allow a program to be written
5062 using the pragmas, and then compiled with a compiler that
5063 will ignore the pragmas. That doesn't work in the case of
5064 static and dynamic predicates, since if the corresponding
5065 pragmas are ignored, then the behavior of the program is
5066 fundamentally changed (for example a membership test
5067 ``A in B`` would not take into account a predicate
5068 defined for subtype B). When following this approach, the
5069 use of predicates should be avoided.
5071 Pragma Predicate_Failure
5072 ========================
5079 pragma Predicate_Failure
5080 ([Entity =>] type_LOCAL_NAME,
5081 [Message =>] String_Expression);
5084 The ``Predicate_Failure`` pragma is intended to be an exact replacement for
5085 the language-defined
5086 ``Predicate_Failure`` aspect, and shares its restrictions and semantics.
5088 Pragma Preelaborable_Initialization
5089 ===================================
5096 pragma Preelaborable_Initialization (DIRECT_NAME);
5099 This pragma is standard in Ada 2005, but is available in all earlier
5100 versions of Ada as an implementation-defined pragma.
5101 See Ada 2012 Reference Manual for details.
5103 Pragma Prefix_Exception_Messages
5104 ================================
5105 .. index:: Prefix_Exception_Messages
5107 .. index:: exception
5109 .. index:: Exception_Message
5117 pragma Prefix_Exception_Messages;
5120 This is an implementation-defined configuration pragma that affects the
5121 behavior of raise statements with a message given as a static string
5122 constant (typically a string literal). In such cases, the string will
5123 be automatically prefixed by the name of the enclosing entity (giving
5124 the package and subprogram containing the raise statement). This helps
5125 to identify where messages are coming from, and this mode is automatic
5126 for the run-time library.
5128 The pragma has no effect if the message is computed with an expression other
5129 than a static string constant, since the assumption in this case is that
5130 the program computes exactly the string it wants. If you still want the
5131 prefixing in this case, you can always call
5132 ``GNAT.Source_Info.Enclosing_Entity`` and prepend the string manually.
5136 .. index:: Pre_Class
5138 .. index:: Checks, preconditions
5146 pragma Pre_Class (Boolean_Expression);
5149 The ``Pre_Class`` pragma is intended to be an exact replacement for
5150 the language-defined
5151 ``Pre'Class`` aspect, and shares its restrictions and semantics.
5152 It must appear either immediately following the corresponding
5153 subprogram declaration (only other pragmas may intervene), or
5154 if there is no separate subprogram declaration, then it can
5155 appear at the start of the declarations in a subprogram body
5156 (preceded only by other pragmas).
5158 Note: This pragma is called ``Pre_Class`` rather than
5159 ``Pre'Class`` because the latter would not be strictly
5160 conforming to the allowed syntax for pragmas. The motivation
5161 for providing pragmas equivalent to the aspects is to allow a program
5162 to be written using the pragmas, and then compiled if necessary
5163 using an Ada compiler that does not recognize the pragmas or
5164 aspects, but is prepared to ignore the pragmas. The assertion
5165 policy that controls this pragma is ``Pre'Class``, not
5168 Pragma Priority_Specific_Dispatching
5169 ====================================
5176 pragma Priority_Specific_Dispatching (
5178 first_priority_EXPRESSION,
5179 last_priority_EXPRESSION)
5181 POLICY_IDENTIFIER ::=
5182 EDF_Across_Priorities |
5183 FIFO_Within_Priorities |
5184 Non_Preemptive_Within_Priorities |
5185 Round_Robin_Within_Priorities
5188 This pragma is standard in Ada 2005, but is available in all earlier
5189 versions of Ada as an implementation-defined pragma.
5190 See Ada 2012 Reference Manual for details.
5200 pragma Profile (Ravenscar | Restricted | Rational |
5201 GNAT_Extended_Ravenscar | GNAT_Ravenscar_EDF );
5204 This pragma is standard in Ada 2005, but is available in all earlier
5205 versions of Ada as an implementation-defined pragma. This is a
5206 configuration pragma that establishes a set of configuration pragmas
5207 that depend on the argument. ``Ravenscar`` is standard in Ada 2005.
5208 The other possibilities (``Restricted``, ``Rational``,
5209 ``GNAT_Extended_Ravenscar``, ``GNAT_Ravenscar_EDF``)
5210 are implementation-defined. The set of configuration pragmas
5211 is defined in the following sections.
5214 * Pragma Profile (Ravenscar)
5216 The ``Ravenscar`` profile is standard in Ada 2005,
5217 but is available in all earlier
5218 versions of Ada as an implementation-defined pragma. This profile
5219 establishes the following set of configuration pragmas:
5221 * ``Task_Dispatching_Policy (FIFO_Within_Priorities)``
5223 [RM D.2.2] Tasks are dispatched following a preemptive
5224 priority-ordered scheduling policy.
5227 * ``Locking_Policy (Ceiling_Locking)``
5229 [RM D.3] While tasks and interrupts execute a protected action, they inherit
5230 the ceiling priority of the corresponding protected object.
5233 * ``Detect_Blocking``
5235 This pragma forces the detection of potentially blocking operations within a
5236 protected operation, and to raise Program_Error if that happens.
5238 plus the following set of restrictions:
5240 * ``Max_Entry_Queue_Length => 1``
5242 No task can be queued on a protected entry.
5244 * ``Max_Protected_Entries => 1``
5246 * ``Max_Task_Entries => 0``
5248 No rendezvous statements are allowed.
5250 * ``No_Abort_Statements``
5252 * ``No_Dynamic_Attachment``
5254 * ``No_Dynamic_Priorities``
5256 * ``No_Implicit_Heap_Allocations``
5258 * ``No_Local_Protected_Objects``
5260 * ``No_Local_Timing_Events``
5262 * ``No_Protected_Type_Allocators``
5264 * ``No_Relative_Delay``
5266 * ``No_Requeue_Statements``
5268 * ``No_Select_Statements``
5270 * ``No_Specific_Termination_Handlers``
5272 * ``No_Task_Allocators``
5274 * ``No_Task_Hierarchy``
5276 * ``No_Task_Termination``
5278 * ``Simple_Barriers``
5280 The Ravenscar profile also includes the following restrictions that specify
5281 that there are no semantic dependences on the corresponding predefined
5284 * ``No_Dependence => Ada.Asynchronous_Task_Control``
5286 * ``No_Dependence => Ada.Calendar``
5288 * ``No_Dependence => Ada.Execution_Time.Group_Budget``
5290 * ``No_Dependence => Ada.Execution_Time.Timers``
5292 * ``No_Dependence => Ada.Task_Attributes``
5294 * ``No_Dependence => System.Multiprocessors.Dispatching_Domains``
5296 This set of configuration pragmas and restrictions correspond to the
5297 definition of the 'Ravenscar Profile' for limited tasking, devised and
5298 published by the :title:`International Real-Time Ada Workshop, 1997`.
5299 A description is also available at
5300 `http://www-users.cs.york.ac.uk/~burns/ravenscar.ps <http://www-users.cs.york.ac.uk/~burns/ravenscar.ps>`_.
5302 The original definition of the profile was revised at subsequent IRTAW
5303 meetings. It has been included in the ISO
5304 :title:`Guide for the Use of the Ada Programming Language in High Integrity Systems`,
5305 and was made part of the Ada 2005 standard.
5306 The formal definition given by
5307 the Ada Rapporteur Group (ARG) can be found in two Ada Issues (AI-249 and
5308 AI-305) available at
5309 `http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ais/ai-00249.txt <http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ais/ai-00249.txt>`_ and
5310 `http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ais/ai-00305.txt <http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ais/ai-00305.txt>`_.
5312 The above set is a superset of the restrictions provided by pragma
5313 ``Profile (Restricted)``, it includes six additional restrictions
5314 (``Simple_Barriers``, ``No_Select_Statements``,
5315 ``No_Calendar``, ``No_Implicit_Heap_Allocations``,
5316 ``No_Relative_Delay`` and ``No_Task_Termination``). This means
5317 that pragma ``Profile (Ravenscar)``, like the pragma
5318 ``Profile (Restricted)``,
5319 automatically causes the use of a simplified,
5320 more efficient version of the tasking run-time library.
5322 * Pragma Profile (GNAT_Extended_Ravenscar)
5324 This profile corresponds to a GNAT specific extension of the
5325 Ravenscar profile. The profile may change in the future although
5326 only in a compatible way: some restrictions may be removed or
5327 relaxed. It is defined as a variation of the Ravenscar profile.
5329 The ``No_Implicit_Heap_Allocations`` restriction has been replaced
5330 by ``No_Implicit_Task_Allocations`` and
5331 ``No_Implicit_Protected_Object_Allocations``.
5333 The ``Simple_Barriers`` restriction has been replaced by
5336 The ``Max_Protected_Entries``, ``Max_Entry_Queue_Length``, and
5337 ``No_Relative_Delay`` restrictions have been removed.
5339 * Pragma Profile (GNAT_Ravenscar_EDF)
5341 This profile corresponds to the Ravenscar profile but using
5342 EDF_Across_Priority as the Task_Scheduling_Policy.
5344 * Pragma Profile (Restricted)
5346 This profile corresponds to the GNAT restricted run time. It
5347 establishes the following set of restrictions:
5349 * ``No_Abort_Statements``
5350 * ``No_Entry_Queue``
5351 * ``No_Task_Hierarchy``
5352 * ``No_Task_Allocators``
5353 * ``No_Dynamic_Priorities``
5354 * ``No_Terminate_Alternatives``
5355 * ``No_Dynamic_Attachment``
5356 * ``No_Protected_Type_Allocators``
5357 * ``No_Local_Protected_Objects``
5358 * ``No_Requeue_Statements``
5359 * ``No_Task_Attributes_Package``
5360 * ``Max_Asynchronous_Select_Nesting = 0``
5361 * ``Max_Task_Entries = 0``
5362 * ``Max_Protected_Entries = 1``
5363 * ``Max_Select_Alternatives = 0``
5365 This set of restrictions causes the automatic selection of a simplified
5366 version of the run time that provides improved performance for the
5367 limited set of tasking functionality permitted by this set of restrictions.
5369 * Pragma Profile (Rational)
5371 The Rational profile is intended to facilitate porting legacy code that
5372 compiles with the Rational APEX compiler, even when the code includes non-
5373 conforming Ada constructs. The profile enables the following three pragmas:
5375 * ``pragma Implicit_Packing``
5376 * ``pragma Overriding_Renamings``
5377 * ``pragma Use_VADS_Size``
5380 Pragma Profile_Warnings
5381 =======================
5388 pragma Profile_Warnings (Ravenscar | Restricted | Rational);
5391 This is an implementation-defined pragma that is similar in
5392 effect to ``pragma Profile`` except that instead of
5393 generating ``Restrictions`` pragmas, it generates
5394 ``Restriction_Warnings`` pragmas. The result is that
5395 violations of the profile generate warning messages instead
5398 Pragma Propagate_Exceptions
5399 ===========================
5400 .. index:: Interfacing to C++
5408 pragma Propagate_Exceptions;
5411 This pragma is now obsolete and, other than generating a warning if warnings
5412 on obsolescent features are enabled, is ignored.
5413 It is retained for compatibility
5414 purposes. It used to be used in connection with optimization of
5415 a now-obsolete mechanism for implementation of exceptions.
5417 Pragma Provide_Shift_Operators
5418 ==============================
5419 .. index:: Shift operators
5427 pragma Provide_Shift_Operators (integer_first_subtype_LOCAL_NAME);
5430 This pragma can be applied to a first subtype local name that specifies
5431 either an unsigned or signed type. It has the effect of providing the
5432 five shift operators (Shift_Left, Shift_Right, Shift_Right_Arithmetic,
5433 Rotate_Left and Rotate_Right) for the given type. It is similar to
5434 including the function declarations for these five operators, together
5435 with the pragma Import (Intrinsic, ...) statements.
5445 pragma Psect_Object (
5446 [Internal =>] LOCAL_NAME,
5447 [, [External =>] EXTERNAL_SYMBOL]
5448 [, [Size =>] EXTERNAL_SYMBOL]);
5452 | static_string_EXPRESSION
5455 This pragma is identical in effect to pragma ``Common_Object``.
5457 .. _Pragma-Pure_Function:
5459 Pragma Pure_Function
5460 ====================
5467 pragma Pure_Function ([Entity =>] function_LOCAL_NAME);
5470 This pragma appears in the same declarative part as a function
5471 declaration (or a set of function declarations if more than one
5472 overloaded declaration exists, in which case the pragma applies
5473 to all entities). It specifies that the function ``Entity`` is
5474 to be considered pure for the purposes of code generation. This means
5475 that the compiler can assume that there are no side effects, and
5476 in particular that two calls with identical arguments produce the
5477 same result. It also means that the function can be used in an
5480 Note that, quite deliberately, there are no static checks to try
5481 to ensure that this promise is met, so ``Pure_Function`` can be used
5482 with functions that are conceptually pure, even if they do modify
5483 global variables. For example, a square root function that is
5484 instrumented to count the number of times it is called is still
5485 conceptually pure, and can still be optimized, even though it
5486 modifies a global variable (the count). Memo functions are another
5487 example (where a table of previous calls is kept and consulted to
5488 avoid re-computation).
5490 Note also that the normal rules excluding optimization of subprograms
5491 in pure units (when parameter types are descended from System.Address,
5492 or when the full view of a parameter type is limited), do not apply
5493 for the Pure_Function case. If you explicitly specify Pure_Function,
5494 the compiler may optimize away calls with identical arguments, and
5495 if that results in unexpected behavior, the proper action is not to
5496 use the pragma for subprograms that are not (conceptually) pure.
5498 Note: Most functions in a ``Pure`` package are automatically pure, and
5499 there is no need to use pragma ``Pure_Function`` for such functions. One
5500 exception is any function that has at least one formal of type
5501 ``System.Address`` or a type derived from it. Such functions are not
5502 considered pure by default, since the compiler assumes that the
5503 ``Address`` parameter may be functioning as a pointer and that the
5504 referenced data may change even if the address value does not.
5505 Similarly, imported functions are not considered to be pure by default,
5506 since there is no way of checking that they are in fact pure. The use
5507 of pragma ``Pure_Function`` for such a function will override these default
5508 assumption, and cause the compiler to treat a designated subprogram as pure
5511 Note: If pragma ``Pure_Function`` is applied to a renamed function, it
5512 applies to the underlying renamed function. This can be used to
5513 disambiguate cases of overloading where some but not all functions
5514 in a set of overloaded functions are to be designated as pure.
5516 If pragma ``Pure_Function`` is applied to a library-level function, the
5517 function is also considered pure from an optimization point of view, but the
5518 unit is not a Pure unit in the categorization sense. So for example, a function
5519 thus marked is free to ``with`` non-pure units.
5532 This pragma is considered obsolescent, but is retained for
5533 compatibility purposes. It is equivalent to:
5538 pragma Profile (Rational);
5552 This pragma is considered obsolescent, but is retained for
5553 compatibility purposes. It is equivalent to:
5558 pragma Profile (Ravenscar);
5561 which is the preferred method of setting the ``Ravenscar`` profile.
5563 .. _Pragma-Refined_Depends:
5565 Pragma Refined_Depends
5566 ======================
5572 pragma Refined_Depends (DEPENDENCY_RELATION);
5574 DEPENDENCY_RELATION ::=
5576 | (DEPENDENCY_CLAUSE {, DEPENDENCY_CLAUSE})
5578 DEPENDENCY_CLAUSE ::=
5579 OUTPUT_LIST =>[+] INPUT_LIST
5580 | NULL_DEPENDENCY_CLAUSE
5582 NULL_DEPENDENCY_CLAUSE ::= null => INPUT_LIST
5584 OUTPUT_LIST ::= OUTPUT | (OUTPUT {, OUTPUT})
5586 INPUT_LIST ::= null | INPUT | (INPUT {, INPUT})
5588 OUTPUT ::= NAME | FUNCTION_RESULT
5591 where FUNCTION_RESULT is a function Result attribute_reference
5593 For the semantics of this pragma, see the entry for aspect ``Refined_Depends`` in
5594 the SPARK 2014 Reference Manual, section 6.1.5.
5596 .. _Pragma-Refined_Global:
5598 Pragma Refined_Global
5599 =====================
5605 pragma Refined_Global (GLOBAL_SPECIFICATION);
5607 GLOBAL_SPECIFICATION ::=
5610 | (MODED_GLOBAL_LIST {, MODED_GLOBAL_LIST})
5612 MODED_GLOBAL_LIST ::= MODE_SELECTOR => GLOBAL_LIST
5614 MODE_SELECTOR ::= In_Out | Input | Output | Proof_In
5615 GLOBAL_LIST ::= GLOBAL_ITEM | (GLOBAL_ITEM {, GLOBAL_ITEM})
5616 GLOBAL_ITEM ::= NAME
5618 For the semantics of this pragma, see the entry for aspect ``Refined_Global`` in
5619 the SPARK 2014 Reference Manual, section 6.1.4.
5621 .. _Pragma-Refined_Post:
5630 pragma Refined_Post (boolean_EXPRESSION);
5632 For the semantics of this pragma, see the entry for aspect ``Refined_Post`` in
5633 the SPARK 2014 Reference Manual, section 7.2.7.
5635 .. _Pragma-Refined_State:
5637 Pragma Refined_State
5638 ====================
5644 pragma Refined_State (REFINEMENT_LIST);
5647 (REFINEMENT_CLAUSE {, REFINEMENT_CLAUSE})
5649 REFINEMENT_CLAUSE ::= state_NAME => CONSTITUENT_LIST
5651 CONSTITUENT_LIST ::=
5654 | (CONSTITUENT {, CONSTITUENT})
5656 CONSTITUENT ::= object_NAME | state_NAME
5658 For the semantics of this pragma, see the entry for aspect ``Refined_State`` in
5659 the SPARK 2014 Reference Manual, section 7.2.2.
5661 Pragma Relative_Deadline
5662 ========================
5669 pragma Relative_Deadline (time_span_EXPRESSION);
5672 This pragma is standard in Ada 2005, but is available in all earlier
5673 versions of Ada as an implementation-defined pragma.
5674 See Ada 2012 Reference Manual for details.
5676 .. _Pragma-Remote_Access_Type:
5678 Pragma Remote_Access_Type
5679 =========================
5686 pragma Remote_Access_Type ([Entity =>] formal_access_type_LOCAL_NAME);
5689 This pragma appears in the formal part of a generic declaration.
5690 It specifies an exception to the RM rule from E.2.2(17/2), which forbids
5691 the use of a remote access to class-wide type as actual for a formal
5694 When this pragma applies to a formal access type ``Entity``, that
5695 type is treated as a remote access to class-wide type in the generic.
5696 It must be a formal general access type, and its designated type must
5697 be the class-wide type of a formal tagged limited private type from the
5698 same generic declaration.
5700 In the generic unit, the formal type is subject to all restrictions
5701 pertaining to remote access to class-wide types. At instantiation, the
5702 actual type must be a remote access to class-wide type.
5704 Pragma Restricted_Run_Time
5705 ==========================
5712 pragma Restricted_Run_Time;
5715 This pragma is considered obsolescent, but is retained for
5716 compatibility purposes. It is equivalent to:
5721 pragma Profile (Restricted);
5724 which is the preferred method of setting the restricted run time
5727 Pragma Restriction_Warnings
5728 ===========================
5735 pragma Restriction_Warnings
5736 (restriction_IDENTIFIER {, restriction_IDENTIFIER});
5739 This pragma allows a series of restriction identifiers to be
5740 specified (the list of allowed identifiers is the same as for
5741 pragma ``Restrictions``). For each of these identifiers
5742 the compiler checks for violations of the restriction, but
5743 generates a warning message rather than an error message
5744 if the restriction is violated.
5746 One use of this is in situations where you want to know
5747 about violations of a restriction, but you want to ignore some of
5748 these violations. Consider this example, where you want to set
5749 Ada_95 mode and enable style checks, but you want to know about
5750 any other use of implementation pragmas:
5755 pragma Restriction_Warnings (No_Implementation_Pragmas);
5756 pragma Warnings (Off, "violation of No_Implementation_Pragmas");
5758 pragma Style_Checks ("2bfhkM160");
5759 pragma Warnings (On, "violation of No_Implementation_Pragmas");
5762 By including the above lines in a configuration pragmas file,
5763 the Ada_95 and Style_Checks pragmas are accepted without
5764 generating a warning, but any other use of implementation
5765 defined pragmas will cause a warning to be generated.
5778 This pragma is an RM-defined standard pragma, but has no effect on the
5779 program being compiled, or on the code generated for the program.
5781 To obtain the required output specified in RM H.3.1, the compiler must be
5782 run with various special switches as follows:
5784 * *Where compiler-generated run-time checks remain*
5786 The switch *-gnatGL*
5787 may be used to list the expanded code in pseudo-Ada form.
5788 Runtime checks show up in the listing either as explicit
5789 checks or operators marked with {} to indicate a check is present.
5792 * *An identification of known exceptions at compile time*
5794 If the program is compiled with *-gnatwa*,
5795 the compiler warning messages will indicate all cases where the compiler
5796 detects that an exception is certain to occur at run time.
5799 * *Possible reads of uninitialized variables*
5801 The compiler warns of many such cases, but its output is incomplete.
5803 .. only:: PRO or GPL
5805 The CodePeer analysis tool
5806 may be used to obtain a comprehensive list of all
5807 possible points at which uninitialized data may be read.
5811 A supplemental static analysis tool
5812 may be used to obtain a comprehensive list of all
5813 possible points at which uninitialized data may be read.
5816 * *Where run-time support routines are implicitly invoked*
5818 In the output from *-gnatGL*,
5819 run-time calls are explicitly listed as calls to the relevant
5823 * *Object code listing*
5825 This may be obtained either by using the *-S* switch,
5826 or the objdump utility.
5829 * *Constructs known to be erroneous at compile time*
5831 These are identified by warnings issued by the compiler (use *-gnatwa*).
5834 * *Stack usage information*
5836 Static stack usage data (maximum per-subprogram) can be obtained via the
5837 *-fstack-usage* switch to the compiler.
5838 Dynamic stack usage data (per task) can be obtained via the *-u* switch
5841 .. only:: PRO or GPL
5843 The gnatstack utility
5844 can be used to provide additional information on stack usage.
5847 * *Object code listing of entire partition*
5849 This can be obtained by compiling the partition with *-S*,
5850 or by applying objdump
5851 to all the object files that are part of the partition.
5854 * *A description of the run-time model*
5856 The full sources of the run-time are available, and the documentation of
5857 these routines describes how these run-time routines interface to the
5858 underlying operating system facilities.
5861 * *Control and data-flow information*
5863 .. only:: PRO or GPL
5866 may be used to obtain complete control and data-flow information, as well as
5867 comprehensive messages identifying possible problems based on this
5872 A supplemental static analysis tool
5873 may be used to obtain complete control and data-flow information, as well as
5874 comprehensive messages identifying possible problems based on this
5877 .. _Pragma-Secondary_Stack_Size:
5879 Pragma Secondary_Stack_Size
5880 ===========================
5886 pragma Secondary_Stack_Size (integer_EXPRESSION);
5888 This pragma appears within the task definition of a single task declaration
5889 or a task type declaration (like pragma ``Storage_Size``) and applies to all
5890 task objects of that type. The argument specifies the size of the secondary
5891 stack to be used by these task objects, and must be of an integer type. The
5892 secondary stack is used to handle functions that return a variable-sized
5893 result, for example a function returning an unconstrained String.
5895 Note this pragma only applies to targets using fixed secondary stacks, like
5896 VxWorks 653 and bare board targets, where a fixed block for the
5897 secondary stack is allocated from the primary stack of the task. By default,
5898 these targets assign a percentage of the primary stack for the secondary stack,
5899 as defined by ``System.Parameter.Sec_Stack_Percentage``. With this pragma,
5900 an ``integer_EXPRESSION`` of bytes is assigned from the primary stack instead.
5902 For most targets, the pragma does not apply as the secondary stack grows on
5903 demand: allocated as a chain of blocks in the heap. The default size of these
5904 blocks can be modified via the :switch:`-D` binder option as described in
5905 :title:`GNAT User's Guide`.
5907 Note that no check is made to see if the secondary stack can fit inside the
5910 Note the pragma cannot appear when the restriction ``No_Secondary_Stack``
5913 Pragma Share_Generic
5914 ====================
5921 pragma Share_Generic (GNAME {, GNAME});
5923 GNAME ::= generic_unit_NAME | generic_instance_NAME
5926 This pragma is provided for compatibility with Dec Ada 83. It has
5927 no effect in GNAT (which does not implement shared generics), other
5928 than to check that the given names are all names of generic units or
5936 This pragma is provided for compatibility with Ada 83. The syntax and
5937 semantics are identical to pragma Atomic.
5939 Pragma Short_Circuit_And_Or
5940 ===========================
5947 pragma Short_Circuit_And_Or;
5950 This configuration pragma causes any occurrence of the AND operator applied to
5951 operands of type Standard.Boolean to be short-circuited (i.e. the AND operator
5952 is treated as if it were AND THEN). Or is similarly treated as OR ELSE. This
5953 may be useful in the context of certification protocols requiring the use of
5954 short-circuited logical operators. If this configuration pragma occurs locally
5955 within the file being compiled, it applies only to the file being compiled.
5956 There is no requirement that all units in a partition use this option.
5958 Pragma Short_Descriptors
5959 ========================
5966 pragma Short_Descriptors
5969 This pragma is provided for compatibility with other Ada implementations. It
5970 is recognized but ignored by all current versions of GNAT.
5972 .. _Pragma-Simple_Storage_Pool_Type:
5974 Pragma Simple_Storage_Pool_Type
5975 ===============================
5976 .. index:: Storage pool, simple
5978 .. index:: Simple storage pool
5985 pragma Simple_Storage_Pool_Type (type_LOCAL_NAME);
5988 A type can be established as a 'simple storage pool type' by applying
5989 the representation pragma ``Simple_Storage_Pool_Type`` to the type.
5990 A type named in the pragma must be a library-level immutably limited record
5991 type or limited tagged type declared immediately within a package declaration.
5992 The type can also be a limited private type whose full type is allowed as
5993 a simple storage pool type.
5995 For a simple storage pool type ``SSP``, nonabstract primitive subprograms
5996 ``Allocate``, ``Deallocate``, and ``Storage_Size`` can be declared that
5997 are subtype conformant with the following subprogram declarations:
6004 Storage_Address : out System.Address;
6005 Size_In_Storage_Elements : System.Storage_Elements.Storage_Count;
6006 Alignment : System.Storage_Elements.Storage_Count);
6008 procedure Deallocate
6010 Storage_Address : System.Address;
6011 Size_In_Storage_Elements : System.Storage_Elements.Storage_Count;
6012 Alignment : System.Storage_Elements.Storage_Count);
6014 function Storage_Size (Pool : SSP)
6015 return System.Storage_Elements.Storage_Count;
6018 Procedure ``Allocate`` must be declared, whereas ``Deallocate`` and
6019 ``Storage_Size`` are optional. If ``Deallocate`` is not declared, then
6020 applying an unchecked deallocation has no effect other than to set its actual
6021 parameter to null. If ``Storage_Size`` is not declared, then the
6022 ``Storage_Size`` attribute applied to an access type associated with
6023 a pool object of type SSP returns zero. Additional operations can be declared
6024 for a simple storage pool type (such as for supporting a mark/release
6025 storage-management discipline).
6027 An object of a simple storage pool type can be associated with an access
6028 type by specifying the attribute
6029 :ref:`Simple_Storage_Pool <Attribute_Simple_Storage_Pool>`. For example:
6034 My_Pool : My_Simple_Storage_Pool_Type;
6036 type Acc is access My_Data_Type;
6038 for Acc'Simple_Storage_Pool use My_Pool;
6042 See attribute :ref:`Simple_Storage_Pool <Attribute_Simple_Storage_Pool>`
6043 for further details.
6045 .. _Pragma_Source_File_Name:
6047 Pragma Source_File_Name
6048 =======================
6055 pragma Source_File_Name (
6056 [Unit_Name =>] unit_NAME,
6057 Spec_File_Name => STRING_LITERAL,
6058 [Index => INTEGER_LITERAL]);
6060 pragma Source_File_Name (
6061 [Unit_Name =>] unit_NAME,
6062 Body_File_Name => STRING_LITERAL,
6063 [Index => INTEGER_LITERAL]);
6066 Use this to override the normal naming convention. It is a configuration
6067 pragma, and so has the usual applicability of configuration pragmas
6068 (i.e., it applies to either an entire partition, or to all units in a
6069 compilation, or to a single unit, depending on how it is used.
6070 ``unit_name`` is mapped to ``file_name_literal``. The identifier for
6071 the second argument is required, and indicates whether this is the file
6072 name for the spec or for the body.
6074 The optional Index argument should be used when a file contains multiple
6075 units, and when you do not want to use ``gnatchop`` to separate then
6076 into multiple files (which is the recommended procedure to limit the
6077 number of recompilations that are needed when some sources change).
6078 For instance, if the source file :file:`source.ada` contains
6094 you could use the following configuration pragmas:
6099 pragma Source_File_Name
6100 (B, Spec_File_Name => "source.ada", Index => 1);
6101 pragma Source_File_Name
6102 (A, Body_File_Name => "source.ada", Index => 2);
6105 Note that the ``gnatname`` utility can also be used to generate those
6106 configuration pragmas.
6108 Another form of the ``Source_File_Name`` pragma allows
6109 the specification of patterns defining alternative file naming schemes
6110 to apply to all files.
6115 pragma Source_File_Name
6116 ( [Spec_File_Name =>] STRING_LITERAL
6117 [,[Casing =>] CASING_SPEC]
6118 [,[Dot_Replacement =>] STRING_LITERAL]);
6120 pragma Source_File_Name
6121 ( [Body_File_Name =>] STRING_LITERAL
6122 [,[Casing =>] CASING_SPEC]
6123 [,[Dot_Replacement =>] STRING_LITERAL]);
6125 pragma Source_File_Name
6126 ( [Subunit_File_Name =>] STRING_LITERAL
6127 [,[Casing =>] CASING_SPEC]
6128 [,[Dot_Replacement =>] STRING_LITERAL]);
6130 CASING_SPEC ::= Lowercase | Uppercase | Mixedcase
6133 The first argument is a pattern that contains a single asterisk indicating
6134 the point at which the unit name is to be inserted in the pattern string
6135 to form the file name. The second argument is optional. If present it
6136 specifies the casing of the unit name in the resulting file name string.
6137 The default is lower case. Finally the third argument allows for systematic
6138 replacement of any dots in the unit name by the specified string literal.
6140 Note that Source_File_Name pragmas should not be used if you are using
6141 project files. The reason for this rule is that the project manager is not
6142 aware of these pragmas, and so other tools that use the projet file would not
6143 be aware of the intended naming conventions. If you are using project files,
6144 file naming is controlled by Source_File_Name_Project pragmas, which are
6145 usually supplied automatically by the project manager. A pragma
6146 Source_File_Name cannot appear after a :ref:`Pragma_Source_File_Name_Project`.
6148 For more details on the use of the ``Source_File_Name`` pragma, see the
6149 sections on ``Using Other File Names`` and `Alternative File Naming Schemes'
6150 in the :title:`GNAT User's Guide`.
6152 .. _Pragma_Source_File_Name_Project:
6154 Pragma Source_File_Name_Project
6155 ===============================
6157 This pragma has the same syntax and semantics as pragma Source_File_Name.
6158 It is only allowed as a stand-alone configuration pragma.
6159 It cannot appear after a :ref:`Pragma_Source_File_Name`, and
6160 most importantly, once pragma Source_File_Name_Project appears,
6161 no further Source_File_Name pragmas are allowed.
6163 The intention is that Source_File_Name_Project pragmas are always
6164 generated by the Project Manager in a manner consistent with the naming
6165 specified in a project file, and when naming is controlled in this manner,
6166 it is not permissible to attempt to modify this naming scheme using
6167 Source_File_Name or Source_File_Name_Project pragmas (which would not be
6168 known to the project manager).
6170 Pragma Source_Reference
6171 =======================
6178 pragma Source_Reference (INTEGER_LITERAL, STRING_LITERAL);
6181 This pragma must appear as the first line of a source file.
6182 ``integer_literal`` is the logical line number of the line following
6183 the pragma line (for use in error messages and debugging
6184 information). ``string_literal`` is a static string constant that
6185 specifies the file name to be used in error messages and debugging
6186 information. This is most notably used for the output of ``gnatchop``
6187 with the *-r* switch, to make sure that the original unchopped
6188 source file is the one referred to.
6190 The second argument must be a string literal, it cannot be a static
6191 string expression other than a string literal. This is because its value
6192 is needed for error messages issued by all phases of the compiler.
6194 .. _Pragma-SPARK_Mode:
6204 pragma SPARK_Mode [(On | Off)] ;
6207 In general a program can have some parts that are in SPARK 2014 (and
6208 follow all the rules in the SPARK Reference Manual), and some parts
6209 that are full Ada 2012.
6211 The SPARK_Mode pragma is used to identify which parts are in SPARK
6212 2014 (by default programs are in full Ada). The SPARK_Mode pragma can
6213 be used in the following places:
6217 As a configuration pragma, in which case it sets the default mode for
6218 all units compiled with this pragma.
6221 Immediately following a library-level subprogram spec
6224 Immediately within a library-level package body
6227 Immediately following the ``private`` keyword of a library-level
6231 Immediately following the ``begin`` keyword of a library-level
6235 Immediately within a library-level subprogram body
6238 Normally a subprogram or package spec/body inherits the current mode
6239 that is active at the point it is declared. But this can be overridden
6240 by pragma within the spec or body as above.
6242 The basic consistency rule is that you can't turn SPARK_Mode back
6243 ``On``, once you have explicitly (with a pragma) turned if
6244 ``Off``. So the following rules apply:
6246 If a subprogram spec has SPARK_Mode ``Off``, then the body must
6247 also have SPARK_Mode ``Off``.
6249 For a package, we have four parts:
6252 the package public declarations
6254 the package private part
6256 the body of the package
6258 the elaboration code after ``begin``
6260 For a package, the rule is that if you explicitly turn SPARK_Mode
6261 ``Off`` for any part, then all the following parts must have
6262 SPARK_Mode ``Off``. Note that this may require repeating a pragma
6263 SPARK_Mode (``Off``) in the body. For example, if we have a
6264 configuration pragma SPARK_Mode (``On``) that turns the mode on by
6265 default everywhere, and one particular package spec has pragma
6266 SPARK_Mode (``Off``), then that pragma will need to be repeated in
6269 Pragma Static_Elaboration_Desired
6270 =================================
6277 pragma Static_Elaboration_Desired;
6280 This pragma is used to indicate that the compiler should attempt to initialize
6281 statically the objects declared in the library unit to which the pragma applies,
6282 when these objects are initialized (explicitly or implicitly) by an aggregate.
6283 In the absence of this pragma, aggregates in object declarations are expanded
6284 into assignments and loops, even when the aggregate components are static
6285 constants. When the aggregate is present the compiler builds a static expression
6286 that requires no run-time code, so that the initialized object can be placed in
6287 read-only data space. If the components are not static, or the aggregate has
6288 more that 100 components, the compiler emits a warning that the pragma cannot
6289 be obeyed. (See also the restriction No_Implicit_Loops, which supports static
6290 construction of larger aggregates with static components that include an others
6293 Pragma Stream_Convert
6294 =====================
6301 pragma Stream_Convert (
6302 [Entity =>] type_LOCAL_NAME,
6303 [Read =>] function_NAME,
6304 [Write =>] function_NAME);
6307 This pragma provides an efficient way of providing user-defined stream
6308 attributes. Not only is it simpler to use than specifying the attributes
6309 directly, but more importantly, it allows the specification to be made in such
6310 a way that the predefined unit Ada.Streams is not loaded unless it is actually
6311 needed (i.e. unless the stream attributes are actually used); the use of
6312 the Stream_Convert pragma adds no overhead at all, unless the stream
6313 attributes are actually used on the designated type.
6315 The first argument specifies the type for which stream functions are
6316 provided. The second parameter provides a function used to read values
6317 of this type. It must name a function whose argument type may be any
6318 subtype, and whose returned type must be the type given as the first
6319 argument to the pragma.
6321 The meaning of the ``Read`` parameter is that if a stream attribute directly
6322 or indirectly specifies reading of the type given as the first parameter,
6323 then a value of the type given as the argument to the Read function is
6324 read from the stream, and then the Read function is used to convert this
6325 to the required target type.
6327 Similarly the ``Write`` parameter specifies how to treat write attributes
6328 that directly or indirectly apply to the type given as the first parameter.
6329 It must have an input parameter of the type specified by the first parameter,
6330 and the return type must be the same as the input type of the Read function.
6331 The effect is to first call the Write function to convert to the given stream
6332 type, and then write the result type to the stream.
6334 The Read and Write functions must not be overloaded subprograms. If necessary
6335 renamings can be supplied to meet this requirement.
6336 The usage of this attribute is best illustrated by a simple example, taken
6337 from the GNAT implementation of package Ada.Strings.Unbounded:
6342 function To_Unbounded (S : String) return Unbounded_String
6343 renames To_Unbounded_String;
6345 pragma Stream_Convert
6346 (Unbounded_String, To_Unbounded, To_String);
6349 The specifications of the referenced functions, as given in the Ada
6350 Reference Manual are:
6355 function To_Unbounded_String (Source : String)
6356 return Unbounded_String;
6358 function To_String (Source : Unbounded_String)
6362 The effect is that if the value of an unbounded string is written to a stream,
6363 then the representation of the item in the stream is in the same format that
6364 would be used for ``Standard.String'Output``, and this same representation
6365 is expected when a value of this type is read from the stream. Note that the
6366 value written always includes the bounds, even for Unbounded_String'Write,
6367 since Unbounded_String is not an array type.
6369 Note that the ``Stream_Convert`` pragma is not effective in the case of
6370 a derived type of a non-limited tagged type. If such a type is specified then
6371 the pragma is silently ignored, and the default implementation of the stream
6372 attributes is used instead.
6382 pragma Style_Checks (string_LITERAL | ALL_CHECKS |
6383 On | Off [, LOCAL_NAME]);
6386 This pragma is used in conjunction with compiler switches to control the
6387 built in style checking provided by GNAT. The compiler switches, if set,
6388 provide an initial setting for the switches, and this pragma may be used
6389 to modify these settings, or the settings may be provided entirely by
6390 the use of the pragma. This pragma can be used anywhere that a pragma
6391 is legal, including use as a configuration pragma (including use in
6392 the :file:`gnat.adc` file).
6394 The form with a string literal specifies which style options are to be
6395 activated. These are additive, so they apply in addition to any previously
6396 set style check options. The codes for the options are the same as those
6397 used in the *-gnaty* switch to *gcc* or *gnatmake*.
6398 For example the following two methods can be used to enable
6405 pragma Style_Checks ("l");
6415 The form ``ALL_CHECKS`` activates all standard checks (its use is equivalent
6416 to the use of the :switch:`gnaty` switch with no options.
6417 See the :title:`GNAT User's Guide` for details.)
6419 Note: the behavior is slightly different in GNAT mode (:switch:`-gnatg` used).
6420 In this case, ``ALL_CHECKS`` implies the standard set of GNAT mode style check
6421 options (i.e. equivalent to :switch:`-gnatyg`).
6423 The forms with ``Off`` and ``On``
6424 can be used to temporarily disable style checks
6425 as shown in the following example:
6430 pragma Style_Checks ("k"); -- requires keywords in lower case
6431 pragma Style_Checks (Off); -- turn off style checks
6432 NULL; -- this will not generate an error message
6433 pragma Style_Checks (On); -- turn style checks back on
6434 NULL; -- this will generate an error message
6437 Finally the two argument form is allowed only if the first argument is
6438 ``On`` or ``Off``. The effect is to turn of semantic style checks
6439 for the specified entity, as shown in the following example:
6444 pragma Style_Checks ("r"); -- require consistency of identifier casing
6446 Rf1 : Integer := ARG; -- incorrect, wrong case
6447 pragma Style_Checks (Off, Arg);
6448 Rf2 : Integer := ARG; -- OK, no error
6459 pragma Subtitle ([Subtitle =>] STRING_LITERAL);
6462 This pragma is recognized for compatibility with other Ada compilers
6463 but is ignored by GNAT.
6473 pragma Suppress (Identifier [, [On =>] Name]);
6476 This is a standard pragma, and supports all the check names required in
6477 the RM. It is included here because GNAT recognizes some additional check
6478 names that are implementation defined (as permitted by the RM):
6482 ``Alignment_Check`` can be used to suppress alignment checks
6483 on addresses used in address clauses. Such checks can also be suppressed
6484 by suppressing range checks, but the specific use of ``Alignment_Check``
6485 allows suppression of alignment checks without suppressing other range checks.
6486 Note that ``Alignment_Check`` is suppressed by default on machines (such as
6487 the x86) with non-strict alignment.
6490 ``Atomic_Synchronization`` can be used to suppress the special memory
6491 synchronization instructions that are normally generated for access to
6492 ``Atomic`` variables to ensure correct synchronization between tasks
6493 that use such variables for synchronization purposes.
6496 ``Duplicated_Tag_Check`` Can be used to suppress the check that is generated
6497 for a duplicated tag value when a tagged type is declared.
6500 ``Container_Checks`` Can be used to suppress all checks within Ada.Containers
6501 and instances of its children, including Tampering_Check.
6504 ``Tampering_Check`` Can be used to suppress tampering check in the containers.
6507 ``Predicate_Check`` can be used to control whether predicate checks are
6508 active. It is applicable only to predicates for which the policy is
6509 ``Check``. Unlike ``Assertion_Policy``, which determines if a given
6510 predicate is ignored or checked for the whole program, the use of
6511 ``Suppress`` and ``Unsuppress`` with this check name allows a given
6512 predicate to be turned on and off at specific points in the program.
6515 ``Validity_Check`` can be used specifically to control validity checks.
6516 If ``Suppress`` is used to suppress validity checks, then no validity
6517 checks are performed, including those specified by the appropriate compiler
6518 switch or the ``Validity_Checks`` pragma.
6521 Additional check names previously introduced by use of the ``Check_Name``
6522 pragma are also allowed.
6525 Note that pragma Suppress gives the compiler permission to omit
6526 checks, but does not require the compiler to omit checks. The compiler
6527 will generate checks if they are essentially free, even when they are
6528 suppressed. In particular, if the compiler can prove that a certain
6529 check will necessarily fail, it will generate code to do an
6530 unconditional 'raise', even if checks are suppressed. The compiler
6533 Of course, run-time checks are omitted whenever the compiler can prove
6534 that they will not fail, whether or not checks are suppressed.
6544 pragma Suppress_All;
6547 This pragma can appear anywhere within a unit.
6548 The effect is to apply ``Suppress (All_Checks)`` to the unit
6549 in which it appears. This pragma is implemented for compatibility with DEC
6550 Ada 83 usage where it appears at the end of a unit, and for compatibility
6551 with Rational Ada, where it appears as a program unit pragma.
6552 The use of the standard Ada pragma ``Suppress (All_Checks)``
6553 as a normal configuration pragma is the preferred usage in GNAT.
6555 .. _Pragma-Suppress_Debug_Info:
6557 Pragma Suppress_Debug_Info
6558 ==========================
6565 pragma Suppress_Debug_Info ([Entity =>] LOCAL_NAME);
6568 This pragma can be used to suppress generation of debug information
6569 for the specified entity. It is intended primarily for use in debugging
6570 the debugger, and navigating around debugger problems.
6572 Pragma Suppress_Exception_Locations
6573 ===================================
6580 pragma Suppress_Exception_Locations;
6583 In normal mode, a raise statement for an exception by default generates
6584 an exception message giving the file name and line number for the location
6585 of the raise. This is useful for debugging and logging purposes, but this
6586 entails extra space for the strings for the messages. The configuration
6587 pragma ``Suppress_Exception_Locations`` can be used to suppress the
6588 generation of these strings, with the result that space is saved, but the
6589 exception message for such raises is null. This configuration pragma may
6590 appear in a global configuration pragma file, or in a specific unit as
6591 usual. It is not required that this pragma be used consistently within
6592 a partition, so it is fine to have some units within a partition compiled
6593 with this pragma and others compiled in normal mode without it.
6595 .. _Pragma-Suppress_Initialization:
6597 Pragma Suppress_Initialization
6598 ==============================
6599 .. index:: Suppressing initialization
6601 .. index:: Initialization, suppression of
6608 pragma Suppress_Initialization ([Entity =>] variable_or_subtype_Name);
6611 Here variable_or_subtype_Name is the name introduced by a type declaration
6612 or subtype declaration or the name of a variable introduced by an
6615 In the case of a type or subtype
6616 this pragma suppresses any implicit or explicit initialization
6617 for all variables of the given type or subtype,
6618 including initialization resulting from the use of pragmas
6619 Normalize_Scalars or Initialize_Scalars.
6621 This is considered a representation item, so it cannot be given after
6622 the type is frozen. It applies to all subsequent object declarations,
6623 and also any allocator that creates objects of the type.
6625 If the pragma is given for the first subtype, then it is considered
6626 to apply to the base type and all its subtypes. If the pragma is given
6627 for other than a first subtype, then it applies only to the given subtype.
6628 The pragma may not be given after the type is frozen.
6630 Note that this includes eliminating initialization of discriminants
6631 for discriminated types, and tags for tagged types. In these cases,
6632 you will have to use some non-portable mechanism (e.g. address
6633 overlays or unchecked conversion) to achieve required initialization
6634 of these fields before accessing any object of the corresponding type.
6636 For the variable case, implicit initialization for the named variable
6637 is suppressed, just as though its subtype had been given in a pragma
6638 Suppress_Initialization, as described above.
6648 pragma Task_Name (string_EXPRESSION);
6651 This pragma appears within a task definition (like pragma
6652 ``Priority``) and applies to the task in which it appears. The
6653 argument must be of type String, and provides a name to be used for
6654 the task instance when the task is created. Note that this expression
6655 is not required to be static, and in particular, it can contain
6656 references to task discriminants. This facility can be used to
6657 provide different names for different tasks as they are created,
6658 as illustrated in the example below.
6660 The task name is recorded internally in the run-time structures
6661 and is accessible to tools like the debugger. In addition the
6662 routine ``Ada.Task_Identification.Image`` will return this
6663 string, with a unique task address appended.
6668 -- Example of the use of pragma Task_Name
6670 with Ada.Task_Identification;
6671 use Ada.Task_Identification;
6672 with Text_IO; use Text_IO;
6675 type Astring is access String;
6677 task type Task_Typ (Name : access String) is
6678 pragma Task_Name (Name.all);
6681 task body Task_Typ is
6682 Nam : constant String := Image (Current_Task);
6684 Put_Line ("-->" & Nam (1 .. 14) & "<--");
6687 type Ptr_Task is access Task_Typ;
6688 Task_Var : Ptr_Task;
6692 new Task_Typ (new String'("This is task 1"));
6694 new Task_Typ (new String'("This is task 2"));
6705 pragma Task_Storage (
6706 [Task_Type =>] LOCAL_NAME,
6707 [Top_Guard =>] static_integer_EXPRESSION);
6710 This pragma specifies the length of the guard area for tasks. The guard
6711 area is an additional storage area allocated to a task. A value of zero
6712 means that either no guard area is created or a minimal guard area is
6713 created, depending on the target. This pragma can appear anywhere a
6714 ``Storage_Size`` attribute definition clause is allowed for a task
6717 .. _Pragma-Test_Case:
6721 .. index:: Test cases
6730 [Name =>] static_string_Expression
6731 ,[Mode =>] (Nominal | Robustness)
6732 [, Requires => Boolean_Expression]
6733 [, Ensures => Boolean_Expression]);
6736 The ``Test_Case`` pragma allows defining fine-grain specifications
6737 for use by testing tools.
6738 The compiler checks the validity of the ``Test_Case`` pragma, but its
6739 presence does not lead to any modification of the code generated by the
6742 ``Test_Case`` pragmas may only appear immediately following the
6743 (separate) declaration of a subprogram in a package declaration, inside
6744 a package spec unit. Only other pragmas may intervene (that is appear
6745 between the subprogram declaration and a test case).
6747 The compiler checks that boolean expressions given in ``Requires`` and
6748 ``Ensures`` are valid, where the rules for ``Requires`` are the
6749 same as the rule for an expression in ``Precondition`` and the rules
6750 for ``Ensures`` are the same as the rule for an expression in
6751 ``Postcondition``. In particular, attributes ``'Old`` and
6752 ``'Result`` can only be used within the ``Ensures``
6753 expression. The following is an example of use within a package spec:
6758 package Math_Functions is
6760 function Sqrt (Arg : Float) return Float;
6761 pragma Test_Case (Name => "Test 1",
6763 Requires => Arg < 10000,
6764 Ensures => Sqrt'Result < 10);
6769 The meaning of a test case is that there is at least one context where
6770 ``Requires`` holds such that, if the associated subprogram is executed in
6771 that context, then ``Ensures`` holds when the subprogram returns.
6772 Mode ``Nominal`` indicates that the input context should also satisfy the
6773 precondition of the subprogram, and the output context should also satisfy its
6774 postcondition. Mode ``Robustness`` indicates that the precondition and
6775 postcondition of the subprogram should be ignored for this test case.
6777 .. _Pragma-Thread_Local_Storage:
6779 Pragma Thread_Local_Storage
6780 ===========================
6781 .. index:: Task specific storage
6783 .. index:: TLS (Thread Local Storage)
6785 .. index:: Task_Attributes
6792 pragma Thread_Local_Storage ([Entity =>] LOCAL_NAME);
6795 This pragma specifies that the specified entity, which must be
6796 a variable declared in a library-level package, is to be marked as
6797 "Thread Local Storage" (``TLS``). On systems supporting this (which
6798 include Windows, Solaris, GNU/Linux, and VxWorks 6), this causes each
6799 thread (and hence each Ada task) to see a distinct copy of the variable.
6801 The variable must not have default initialization, and if there is
6802 an explicit initialization, it must be either ``null`` for an
6803 access variable, a static expression for a scalar variable, or a fully
6804 static aggregate for a composite type, that is to say, an aggregate all
6805 of whose components are static, and which does not include packed or
6806 discriminated components.
6808 This provides a low-level mechanism similar to that provided by
6809 the ``Ada.Task_Attributes`` package, but much more efficient
6810 and is also useful in writing interface code that will interact
6811 with foreign threads.
6813 If this pragma is used on a system where ``TLS`` is not supported,
6814 then an error message will be generated and the program will be rejected.
6824 pragma Time_Slice (static_duration_EXPRESSION);
6827 For implementations of GNAT on operating systems where it is possible
6828 to supply a time slice value, this pragma may be used for this purpose.
6829 It is ignored if it is used in a system that does not allow this control,
6830 or if it appears in other than the main program unit.
6840 pragma Title (TITLING_OPTION [, TITLING OPTION]);
6843 [Title =>] STRING_LITERAL,
6844 | [Subtitle =>] STRING_LITERAL
6847 Syntax checked but otherwise ignored by GNAT. This is a listing control
6848 pragma used in DEC Ada 83 implementations to provide a title and/or
6849 subtitle for the program listing. The program listing generated by GNAT
6850 does not have titles or subtitles.
6852 Unlike other pragmas, the full flexibility of named notation is allowed
6853 for this pragma, i.e., the parameters may be given in any order if named
6854 notation is used, and named and positional notation can be mixed
6855 following the normal rules for procedure calls in Ada.
6857 Pragma Type_Invariant
6858 =====================
6865 pragma Type_Invariant
6866 ([Entity =>] type_LOCAL_NAME,
6867 [Check =>] EXPRESSION);
6870 The ``Type_Invariant`` pragma is intended to be an exact
6871 replacement for the language-defined ``Type_Invariant``
6872 aspect, and shares its restrictions and semantics. It differs
6873 from the language defined ``Invariant`` pragma in that it
6874 does not permit a string parameter, and it is
6875 controlled by the assertion identifier ``Type_Invariant``
6876 rather than ``Invariant``.
6878 .. _Pragma-Type_Invariant_Class:
6880 Pragma Type_Invariant_Class
6881 ===========================
6888 pragma Type_Invariant_Class
6889 ([Entity =>] type_LOCAL_NAME,
6890 [Check =>] EXPRESSION);
6893 The ``Type_Invariant_Class`` pragma is intended to be an exact
6894 replacement for the language-defined ``Type_Invariant'Class``
6895 aspect, and shares its restrictions and semantics.
6897 Note: This pragma is called ``Type_Invariant_Class`` rather than
6898 ``Type_Invariant'Class`` because the latter would not be strictly
6899 conforming to the allowed syntax for pragmas. The motivation
6900 for providing pragmas equivalent to the aspects is to allow a program
6901 to be written using the pragmas, and then compiled if necessary
6902 using an Ada compiler that does not recognize the pragmas or
6903 aspects, but is prepared to ignore the pragmas. The assertion
6904 policy that controls this pragma is ``Type_Invariant'Class``,
6905 not ``Type_Invariant_Class``.
6907 Pragma Unchecked_Union
6908 ======================
6909 .. index:: Unions in C
6917 pragma Unchecked_Union (first_subtype_LOCAL_NAME);
6920 This pragma is used to specify a representation of a record type that is
6921 equivalent to a C union. It was introduced as a GNAT implementation defined
6922 pragma in the GNAT Ada 95 mode. Ada 2005 includes an extended version of this
6923 pragma, making it language defined, and GNAT fully implements this extended
6924 version in all language modes (Ada 83, Ada 95, and Ada 2005). For full
6925 details, consult the Ada 2012 Reference Manual, section B.3.3.
6927 Pragma Unevaluated_Use_Of_Old
6928 =============================
6929 .. index:: Attribute Old
6931 .. index:: Attribute Loop_Entry
6933 .. index:: Unevaluated_Use_Of_Old
6941 pragma Unevaluated_Use_Of_Old (Error | Warn | Allow);
6944 This pragma controls the processing of attributes Old and Loop_Entry.
6945 If either of these attributes is used in a potentially unevaluated
6946 expression (e.g. the then or else parts of an if expression), then
6947 normally this usage is considered illegal if the prefix of the attribute
6948 is other than an entity name. The language requires this
6949 behavior for Old, and GNAT copies the same rule for Loop_Entry.
6951 The reason for this rule is that otherwise, we can have a situation
6952 where we save the Old value, and this results in an exception, even
6953 though we might not evaluate the attribute. Consider this example:
6958 package UnevalOld is
6960 procedure U (A : String; C : Boolean) -- ERROR
6961 with Post => (if C then A(1)'Old = K else True);
6965 If procedure U is called with a string with a lower bound of 2, and
6966 C false, then an exception would be raised trying to evaluate A(1)
6967 on entry even though the value would not be actually used.
6969 Although the rule guarantees against this possibility, it is sometimes
6970 too restrictive. For example if we know that the string has a lower
6971 bound of 1, then we will never raise an exception.
6972 The pragma ``Unevaluated_Use_Of_Old`` can be
6973 used to modify this behavior. If the argument is ``Error`` then an
6974 error is given (this is the default RM behavior). If the argument is
6975 ``Warn`` then the usage is allowed as legal but with a warning
6976 that an exception might be raised. If the argument is ``Allow``
6977 then the usage is allowed as legal without generating a warning.
6979 This pragma may appear as a configuration pragma, or in a declarative
6980 part or package specification. In the latter case it applies to
6981 uses up to the end of the corresponding statement sequence or
6982 sequence of package declarations.
6984 Pragma Unimplemented_Unit
6985 =========================
6992 pragma Unimplemented_Unit;
6995 If this pragma occurs in a unit that is processed by the compiler, GNAT
6996 aborts with the message :samp:`xxx not implemented`, where
6997 ``xxx`` is the name of the current compilation unit. This pragma is
6998 intended to allow the compiler to handle unimplemented library units in
7001 The abort only happens if code is being generated. Thus you can use
7002 specs of unimplemented packages in syntax or semantic checking mode.
7004 .. _Pragma-Universal_Aliasing:
7006 Pragma Universal_Aliasing
7007 =========================
7014 pragma Universal_Aliasing [([Entity =>] type_LOCAL_NAME)];
7017 ``type_LOCAL_NAME`` must refer to a type declaration in the current
7018 declarative part. The effect is to inhibit strict type-based aliasing
7019 optimization for the given type. In other words, the effect is as though
7020 access types designating this type were subject to pragma No_Strict_Aliasing.
7021 For a detailed description of the strict aliasing optimization, and the
7022 situations in which it must be suppressed, see the section on
7023 ``Optimization and Strict Aliasing`` in the :title:`GNAT User's Guide`.
7025 .. _Pragma-Universal_Data:
7027 Pragma Universal_Data
7028 =====================
7035 pragma Universal_Data [(library_unit_Name)];
7038 This pragma is supported only for the AAMP target and is ignored for
7039 other targets. The pragma specifies that all library-level objects
7040 (Counter 0 data) associated with the library unit are to be accessed
7041 and updated using universal addressing (24-bit addresses for AAMP5)
7042 rather than the default of 16-bit Data Environment (DENV) addressing.
7043 Use of this pragma will generally result in less efficient code for
7044 references to global data associated with the library unit, but
7045 allows such data to be located anywhere in memory. This pragma is
7046 a library unit pragma, but can also be used as a configuration pragma
7047 (including use in the :file:`gnat.adc` file). The functionality
7048 of this pragma is also available by applying the -univ switch on the
7049 compilations of units where universal addressing of the data is desired.
7051 .. _Pragma-Unmodified:
7055 .. index:: Warnings, unmodified
7062 pragma Unmodified (LOCAL_NAME {, LOCAL_NAME});
7065 This pragma signals that the assignable entities (variables,
7066 ``out`` parameters, ``in out`` parameters) whose names are listed are
7067 deliberately not assigned in the current source unit. This
7068 suppresses warnings about the
7069 entities being referenced but not assigned, and in addition a warning will be
7070 generated if one of these entities is in fact assigned in the
7071 same unit as the pragma (or in the corresponding body, or one
7074 This is particularly useful for clearly signaling that a particular
7075 parameter is not modified, even though the spec suggests that it might
7078 For the variable case, warnings are never given for unreferenced variables
7079 whose name contains one of the substrings
7080 ``DISCARD, DUMMY, IGNORE, JUNK, UNUSED`` in any casing. Such names
7081 are typically to be used in cases where such warnings are expected.
7082 Thus it is never necessary to use ``pragma Unmodified`` for such
7083 variables, though it is harmless to do so.
7085 .. _Pragma-Unreferenced:
7089 .. index:: Warnings, unreferenced
7096 pragma Unreferenced (LOCAL_NAME {, LOCAL_NAME});
7097 pragma Unreferenced (library_unit_NAME {, library_unit_NAME});
7100 This pragma signals that the entities whose names are listed are
7101 deliberately not referenced in the current source unit after the
7102 occurrence of the pragma. This
7103 suppresses warnings about the
7104 entities being unreferenced, and in addition a warning will be
7105 generated if one of these entities is in fact subsequently referenced in the
7106 same unit as the pragma (or in the corresponding body, or one
7109 This is particularly useful for clearly signaling that a particular
7110 parameter is not referenced in some particular subprogram implementation
7111 and that this is deliberate. It can also be useful in the case of
7112 objects declared only for their initialization or finalization side
7115 If ``LOCAL_NAME`` identifies more than one matching homonym in the
7116 current scope, then the entity most recently declared is the one to which
7117 the pragma applies. Note that in the case of accept formals, the pragma
7118 Unreferenced may appear immediately after the keyword ``do`` which
7119 allows the indication of whether or not accept formals are referenced
7120 or not to be given individually for each accept statement.
7122 The left hand side of an assignment does not count as a reference for the
7123 purpose of this pragma. Thus it is fine to assign to an entity for which
7124 pragma Unreferenced is given.
7126 Note that if a warning is desired for all calls to a given subprogram,
7127 regardless of whether they occur in the same unit as the subprogram
7128 declaration, then this pragma should not be used (calls from another
7129 unit would not be flagged); pragma Obsolescent can be used instead
7130 for this purpose, see :ref:`Pragma_Obsolescent`.
7132 The second form of pragma ``Unreferenced`` is used within a context
7133 clause. In this case the arguments must be unit names of units previously
7134 mentioned in ``with`` clauses (similar to the usage of pragma
7135 ``Elaborate_All``. The effect is to suppress warnings about unreferenced
7136 units and unreferenced entities within these units.
7138 For the variable case, warnings are never given for unreferenced variables
7139 whose name contains one of the substrings
7140 ``DISCARD, DUMMY, IGNORE, JUNK, UNUSED`` in any casing. Such names
7141 are typically to be used in cases where such warnings are expected.
7142 Thus it is never necessary to use ``pragma Unreferenced`` for such
7143 variables, though it is harmless to do so.
7145 .. _Pragma-Unreferenced_Objects:
7147 Pragma Unreferenced_Objects
7148 ===========================
7149 .. index:: Warnings, unreferenced
7156 pragma Unreferenced_Objects (local_subtype_NAME {, local_subtype_NAME});
7159 This pragma signals that for the types or subtypes whose names are
7160 listed, objects which are declared with one of these types or subtypes may
7161 not be referenced, and if no references appear, no warnings are given.
7163 This is particularly useful for objects which are declared solely for their
7164 initialization and finalization effect. Such variables are sometimes referred
7165 to as RAII variables (Resource Acquisition Is Initialization). Using this
7166 pragma on the relevant type (most typically a limited controlled type), the
7167 compiler will automatically suppress unwanted warnings about these variables
7168 not being referenced.
7170 Pragma Unreserve_All_Interrupts
7171 ===============================
7178 pragma Unreserve_All_Interrupts;
7181 Normally certain interrupts are reserved to the implementation. Any attempt
7182 to attach an interrupt causes Program_Error to be raised, as described in
7183 RM C.3.2(22). A typical example is the ``SIGINT`` interrupt used in
7184 many systems for a :kbd:`Ctrl-C` interrupt. Normally this interrupt is
7185 reserved to the implementation, so that :kbd:`Ctrl-C` can be used to
7186 interrupt execution.
7188 If the pragma ``Unreserve_All_Interrupts`` appears anywhere in any unit in
7189 a program, then all such interrupts are unreserved. This allows the
7190 program to handle these interrupts, but disables their standard
7191 functions. For example, if this pragma is used, then pressing
7192 :kbd:`Ctrl-C` will not automatically interrupt execution. However,
7193 a program can then handle the ``SIGINT`` interrupt as it chooses.
7195 For a full list of the interrupts handled in a specific implementation,
7196 see the source code for the spec of ``Ada.Interrupts.Names`` in
7197 file :file:`a-intnam.ads`. This is a target dependent file that contains the
7198 list of interrupts recognized for a given target. The documentation in
7199 this file also specifies what interrupts are affected by the use of
7200 the ``Unreserve_All_Interrupts`` pragma.
7202 For a more general facility for controlling what interrupts can be
7203 handled, see pragma ``Interrupt_State``, which subsumes the functionality
7204 of the ``Unreserve_All_Interrupts`` pragma.
7214 pragma Unsuppress (IDENTIFIER [, [On =>] NAME]);
7217 This pragma undoes the effect of a previous pragma ``Suppress``. If
7218 there is no corresponding pragma ``Suppress`` in effect, it has no
7219 effect. The range of the effect is the same as for pragma
7220 ``Suppress``. The meaning of the arguments is identical to that used
7221 in pragma ``Suppress``.
7223 One important application is to ensure that checks are on in cases where
7224 code depends on the checks for its correct functioning, so that the code
7225 will compile correctly even if the compiler switches are set to suppress
7226 checks. For example, in a program that depends on external names of tagged
7227 types and wants to ensure that the duplicated tag check occurs even if all
7228 run-time checks are suppressed by a compiler switch, the following
7229 configuration pragma will ensure this test is not suppressed:
7234 pragma Unsuppress (Duplicated_Tag_Check);
7237 This pragma is standard in Ada 2005. It is available in all earlier versions
7238 of Ada as an implementation-defined pragma.
7240 Note that in addition to the checks defined in the Ada RM, GNAT recogizes a
7241 number of implementation-defined check names. See the description of pragma
7242 ``Suppress`` for full details.
7244 Pragma Use_VADS_Size
7245 ====================
7246 .. index:: Size, VADS compatibility
7248 .. index:: Rational profile
7256 pragma Use_VADS_Size;
7259 This is a configuration pragma. In a unit to which it applies, any use
7260 of the 'Size attribute is automatically interpreted as a use of the
7261 'VADS_Size attribute. Note that this may result in incorrect semantic
7262 processing of valid Ada 95 or Ada 2005 programs. This is intended to aid in
7263 the handling of existing code which depends on the interpretation of Size
7264 as implemented in the VADS compiler. See description of the VADS_Size
7265 attribute for further details.
7271 .. index:: Warnings, unused
7278 pragma Unused (LOCAL_NAME {, LOCAL_NAME});
7281 This pragma signals that the assignable entities (variables,
7282 ``out`` parameters, and ``in out`` parameters) whose names are listed
7283 deliberately do not get assigned or referenced in the current source unit
7284 after the occurrence of the pragma in the current source unit. This
7285 suppresses warnings about the entities that are unreferenced and/or not
7286 assigned, and, in addition, a warning will be generated if one of these
7287 entities gets assigned or subsequently referenced in the same unit as the
7288 pragma (in the corresponding body or one of its subunits).
7290 This is particularly useful for clearly signaling that a particular
7291 parameter is not modified or referenced, even though the spec suggests
7294 For the variable case, warnings are never given for unreferenced
7295 variables whose name contains one of the substrings
7296 ``DISCARD, DUMMY, IGNORE, JUNK, UNUSED`` in any casing. Such names
7297 are typically to be used in cases where such warnings are expected.
7298 Thus it is never necessary to use ``pragma Unmodified`` for such
7299 variables, though it is harmless to do so.
7301 Pragma Validity_Checks
7302 ======================
7309 pragma Validity_Checks (string_LITERAL | ALL_CHECKS | On | Off);
7312 This pragma is used in conjunction with compiler switches to control the
7313 built-in validity checking provided by GNAT. The compiler switches, if set
7314 provide an initial setting for the switches, and this pragma may be used
7315 to modify these settings, or the settings may be provided entirely by
7316 the use of the pragma. This pragma can be used anywhere that a pragma
7317 is legal, including use as a configuration pragma (including use in
7318 the :file:`gnat.adc` file).
7320 The form with a string literal specifies which validity options are to be
7321 activated. The validity checks are first set to include only the default
7322 reference manual settings, and then a string of letters in the string
7323 specifies the exact set of options required. The form of this string
7324 is exactly as described for the *-gnatVx* compiler switch (see the
7325 GNAT User's Guide for details). For example the following two
7326 methods can be used to enable validity checking for mode ``in`` and
7327 ``in out`` subprogram parameters:
7333 pragma Validity_Checks ("im");
7340 $ gcc -c -gnatVim ...
7343 The form ALL_CHECKS activates all standard checks (its use is equivalent
7344 to the use of the :switch:`gnatVa` switch).
7346 The forms with ``Off`` and ``On`` can be used to temporarily disable
7347 validity checks as shown in the following example:
7352 pragma Validity_Checks ("c"); -- validity checks for copies
7353 pragma Validity_Checks (Off); -- turn off validity checks
7354 A := B; -- B will not be validity checked
7355 pragma Validity_Checks (On); -- turn validity checks back on
7356 A := C; -- C will be validity checked
7367 pragma Volatile (LOCAL_NAME);
7370 This pragma is defined by the Ada Reference Manual, and the GNAT
7371 implementation is fully conformant with this definition. The reason it
7372 is mentioned in this section is that a pragma of the same name was supplied
7373 in some Ada 83 compilers, including DEC Ada 83. The Ada 95 / Ada 2005
7374 implementation of pragma Volatile is upwards compatible with the
7375 implementation in DEC Ada 83.
7377 .. _Pragma-Volatile_Full_Access:
7379 Pragma Volatile_Full_Access
7380 ===========================
7387 pragma Volatile_Full_Access (LOCAL_NAME);
7390 This is similar in effect to pragma Volatile, except that any reference to the
7391 object is guaranteed to be done only with instructions that read or write all
7392 the bits of the object. Furthermore, if the object is of a composite type,
7393 then any reference to a component of the object is guaranteed to read and/or
7394 write all the bits of the object.
7396 The intention is that this be suitable for use with memory-mapped I/O devices
7397 on some machines. Note that there are two important respects in which this is
7398 different from ``pragma Atomic``. First a reference to a ``Volatile_Full_Access``
7399 object is not a sequential action in the RM 9.10 sense and, therefore, does
7400 not create a synchronization point. Second, in the case of ``pragma Atomic``,
7401 there is no guarantee that all the bits will be accessed if the reference
7402 is not to the whole object; the compiler is allowed (and generally will)
7403 access only part of the object in this case.
7405 It is not permissible to specify ``Atomic`` and ``Volatile_Full_Access`` for
7408 It is not permissible to specify ``Volatile_Full_Access`` for a composite
7409 (record or array) type or object that has at least one ``Aliased`` component.
7411 .. _Pragma-Volatile_Function:
7413 Pragma Volatile_Function
7414 ========================
7420 pragma Volatile_Function [ (boolean_EXPRESSION) ];
7422 For the semantics of this pragma, see the entry for aspect ``Volatile_Function``
7423 in the SPARK 2014 Reference Manual, section 7.1.2.
7425 Pragma Warning_As_Error
7426 =======================
7433 pragma Warning_As_Error (static_string_EXPRESSION);
7436 This configuration pragma allows the programmer to specify a set
7437 of warnings that will be treated as errors. Any warning which
7438 matches the pattern given by the pragma argument will be treated
7439 as an error. This gives much more precise control that -gnatwe
7440 which treats all warnings as errors.
7442 The pattern may contain asterisks, which match zero or more characters in
7443 the message. For example, you can use
7444 ``pragma Warning_As_Error ("bits of*unused")`` to treat the warning
7445 message ``warning: 960 bits of "a" unused`` as an error. No other regular
7446 expression notations are permitted. All characters other than asterisk in
7447 these three specific cases are treated as literal characters in the match.
7448 The match is case insensitive, for example XYZ matches xyz.
7450 Note that the pattern matches if it occurs anywhere within the warning
7451 message string (it is not necessary to put an asterisk at the start and
7452 the end of the message, since this is implied).
7454 Another possibility for the static_string_EXPRESSION which works whether
7455 or not error tags are enabled (*-gnatw.d*) is to use the
7456 *-gnatw* tag string, enclosed in brackets,
7457 as shown in the example below, to treat a class of warnings as errors.
7459 The above use of patterns to match the message applies only to warning
7460 messages generated by the front end. This pragma can also be applied to
7461 warnings provided by the back end and mentioned in :ref:`Pragma_Warnings`.
7462 By using a single full *-Wxxx* switch in the pragma, such warnings
7463 can also be treated as errors.
7465 The pragma can appear either in a global configuration pragma file
7466 (e.g. :file:`gnat.adc`), or at the start of a file. Given a global
7467 configuration pragma file containing:
7472 pragma Warning_As_Error ("[-gnatwj]");
7475 which will treat all obsolescent feature warnings as errors, the
7476 following program compiles as shown (compile options here are
7477 *-gnatwa.d -gnatl -gnatj55*).
7482 1. pragma Warning_As_Error ("*never assigned*");
7483 2. function Warnerr return String is
7486 >>> error: variable "X" is never read and
7487 never assigned [-gnatwv] [warning-as-error]
7491 >>> warning: variable "Y" is assigned but
7492 never read [-gnatwu]
7498 >>> error: use of "%" is an obsolescent
7499 feature (RM J.2(4)), use """ instead
7500 [-gnatwj] [warning-as-error]
7504 8 lines: No errors, 3 warnings (2 treated as errors)
7507 Note that this pragma does not affect the set of warnings issued in
7508 any way, it merely changes the effect of a matching warning if one
7509 is produced as a result of other warnings options. As shown in this
7510 example, if the pragma results in a warning being treated as an error,
7511 the tag is changed from "warning:" to "error:" and the string
7512 "[warning-as-error]" is appended to the end of the message.
7514 .. _Pragma_Warnings:
7524 pragma Warnings ([TOOL_NAME,] DETAILS [, REASON]);
7526 DETAILS ::= On | Off
7527 DETAILS ::= On | Off, local_NAME
7528 DETAILS ::= static_string_EXPRESSION
7529 DETAILS ::= On | Off, static_string_EXPRESSION
7531 TOOL_NAME ::= GNAT | GNATProve
7533 REASON ::= Reason => STRING_LITERAL {& STRING_LITERAL}
7535 Note: in Ada 83 mode, a string literal may be used in place of a static string
7536 expression (which does not exist in Ada 83).
7538 Note if the second argument of ``DETAILS`` is a ``local_NAME`` then the
7539 second form is always understood. If the intention is to use
7540 the fourth form, then you can write ``NAME & ""`` to force the
7541 intepretation as a *static_string_EXPRESSION*.
7543 Note: if the first argument is a valid ``TOOL_NAME``, it will be interpreted
7544 that way. The use of the ``TOOL_NAME`` argument is relevant only to users
7545 of SPARK and GNATprove, see last part of this section for details.
7547 Normally warnings are enabled, with the output being controlled by
7548 the command line switch. Warnings (``Off``) turns off generation of
7549 warnings until a Warnings (``On``) is encountered or the end of the
7550 current unit. If generation of warnings is turned off using this
7551 pragma, then some or all of the warning messages are suppressed,
7552 regardless of the setting of the command line switches.
7554 The ``Reason`` parameter may optionally appear as the last argument
7555 in any of the forms of this pragma. It is intended purely for the
7556 purposes of documenting the reason for the ``Warnings`` pragma.
7557 The compiler will check that the argument is a static string but
7558 otherwise ignore this argument. Other tools may provide specialized
7559 processing for this string.
7561 The form with a single argument (or two arguments if Reason present),
7562 where the first argument is ``ON`` or ``OFF``
7563 may be used as a configuration pragma.
7565 If the ``LOCAL_NAME`` parameter is present, warnings are suppressed for
7566 the specified entity. This suppression is effective from the point where
7567 it occurs till the end of the extended scope of the variable (similar to
7568 the scope of ``Suppress``). This form cannot be used as a configuration
7571 In the case where the first argument is other than ``ON`` or
7573 the third form with a single static_string_EXPRESSION argument (and possible
7574 reason) provides more precise
7575 control over which warnings are active. The string is a list of letters
7576 specifying which warnings are to be activated and which deactivated. The
7577 code for these letters is the same as the string used in the command
7578 line switch controlling warnings. For a brief summary, use the gnatmake
7579 command with no arguments, which will generate usage information containing
7580 the list of warnings switches supported. For
7581 full details see the section on ``Warning Message Control`` in the
7582 :title:`GNAT User's Guide`.
7583 This form can also be used as a configuration pragma.
7585 The warnings controlled by the :switch:`-gnatw` switch are generated by the
7586 front end of the compiler. The GCC back end can provide additional warnings
7587 and they are controlled by the :switch:`-W` switch. Such warnings can be
7588 identified by the appearance of a string of the form ``[-W{xxx}]`` in the
7589 message which designates the :switch:`-W{xxx}` switch that controls the message.
7590 The form with a single *static_string_EXPRESSION* argument also works for these
7591 warnings, but the string must be a single full :switch:`-W{xxx}` switch in this
7592 case. The above reference lists a few examples of these additional warnings.
7594 The specified warnings will be in effect until the end of the program
7595 or another pragma ``Warnings`` is encountered. The effect of the pragma is
7596 cumulative. Initially the set of warnings is the standard default set
7597 as possibly modified by compiler switches. Then each pragma Warning
7598 modifies this set of warnings as specified. This form of the pragma may
7599 also be used as a configuration pragma.
7601 The fourth form, with an ``On|Off`` parameter and a string, is used to
7602 control individual messages, based on their text. The string argument
7603 is a pattern that is used to match against the text of individual
7604 warning messages (not including the initial "warning: " tag).
7606 The pattern may contain asterisks, which match zero or more characters in
7607 the message. For example, you can use
7608 ``pragma Warnings (Off, "bits of*unused")`` to suppress the warning
7609 message ``warning: 960 bits of "a" unused``. No other regular
7610 expression notations are permitted. All characters other than asterisk in
7611 these three specific cases are treated as literal characters in the match.
7612 The match is case insensitive, for example XYZ matches xyz.
7614 Note that the pattern matches if it occurs anywhere within the warning
7615 message string (it is not necessary to put an asterisk at the start and
7616 the end of the message, since this is implied).
7618 The above use of patterns to match the message applies only to warning
7619 messages generated by the front end. This form of the pragma with a string
7620 argument can also be used to control warnings provided by the back end and
7621 mentioned above. By using a single full :switch:`-W{xxx}` switch in the pragma,
7622 such warnings can be turned on and off.
7624 There are two ways to use the pragma in this form. The OFF form can be used
7625 as a configuration pragma. The effect is to suppress all warnings (if any)
7626 that match the pattern string throughout the compilation (or match the
7627 -W switch in the back end case).
7629 The second usage is to suppress a warning locally, and in this case, two
7630 pragmas must appear in sequence:
7635 pragma Warnings (Off, Pattern);
7636 ... code where given warning is to be suppressed
7637 pragma Warnings (On, Pattern);
7640 In this usage, the pattern string must match in the Off and On
7641 pragmas, and (if *-gnatw.w* is given) at least one matching
7642 warning must be suppressed.
7644 Note: if the ON form is not found, then the effect of the OFF form extends
7645 until the end of the file (pragma Warnings is purely textual, so its effect
7646 does not stop at the end of the enclosing scope).
7648 Note: to write a string that will match any warning, use the string
7649 ``"***"``. It will not work to use a single asterisk or two
7650 asterisks since this looks like an operator name. This form with three
7651 asterisks is similar in effect to specifying ``pragma Warnings (Off)`` except (if :switch:`-gnatw.w` is given) that a matching
7652 ``pragma Warnings (On, "***")`` will be required. This can be
7653 helpful in avoiding forgetting to turn warnings back on.
7655 Note: the debug flag :switch:`-gnatd.i` (``/NOWARNINGS_PRAGMAS`` in VMS) can be
7656 used to cause the compiler to entirely ignore all WARNINGS pragmas. This can
7657 be useful in checking whether obsolete pragmas in existing programs are hiding
7660 Note: pragma Warnings does not affect the processing of style messages. See
7661 separate entry for pragma Style_Checks for control of style messages.
7663 Users of the formal verification tool GNATprove for the SPARK subset of Ada may
7664 use the version of the pragma with a ``TOOL_NAME`` parameter.
7666 If present, ``TOOL_NAME`` is the name of a tool, currently either ``GNAT`` for the
7667 compiler or ``GNATprove`` for the formal verification tool. A given tool only
7668 takes into account pragma Warnings that do not specify a tool name, or that
7669 specify the matching tool name. This makes it possible to disable warnings
7670 selectively for each tool, and as a consequence to detect useless pragma
7671 Warnings with switch :switch:`-gnatw.w`.
7673 Pragma Weak_External
7674 ====================
7681 pragma Weak_External ([Entity =>] LOCAL_NAME);
7684 ``LOCAL_NAME`` must refer to an object that is declared at the library
7685 level. This pragma specifies that the given entity should be marked as a
7686 weak symbol for the linker. It is equivalent to ``__attribute__((weak))``
7687 in GNU C and causes ``LOCAL_NAME`` to be emitted as a weak symbol instead
7688 of a regular symbol, that is to say a symbol that does not have to be
7689 resolved by the linker if used in conjunction with a pragma Import.
7691 When a weak symbol is not resolved by the linker, its address is set to
7692 zero. This is useful in writing interfaces to external modules that may
7693 or may not be linked in the final executable, for example depending on
7694 configuration settings.
7696 If a program references at run time an entity to which this pragma has been
7697 applied, and the corresponding symbol was not resolved at link time, then
7698 the execution of the program is erroneous. It is not erroneous to take the
7699 Address of such an entity, for example to guard potential references,
7700 as shown in the example below.
7702 Some file formats do not support weak symbols so not all target machines
7703 support this pragma.
7708 -- Example of the use of pragma Weak_External
7710 package External_Module is
7712 pragma Import (C, key);
7713 pragma Weak_External (key);
7714 function Present return boolean;
7715 end External_Module;
7717 with System; use System;
7718 package body External_Module is
7719 function Present return boolean is
7721 return key'Address /= System.Null_Address;
7723 end External_Module;
7726 Pragma Wide_Character_Encoding
7727 ==============================
7734 pragma Wide_Character_Encoding (IDENTIFIER | CHARACTER_LITERAL);
7737 This pragma specifies the wide character encoding to be used in program
7738 source text appearing subsequently. It is a configuration pragma, but may
7739 also be used at any point that a pragma is allowed, and it is permissible
7740 to have more than one such pragma in a file, allowing multiple encodings
7741 to appear within the same file.
7743 However, note that the pragma cannot immediately precede the relevant
7744 wide character, because then the previous encoding will still be in
7745 effect, causing "illegal character" errors.
7747 The argument can be an identifier or a character literal. In the identifier
7748 case, it is one of ``HEX``, ``UPPER``, ``SHIFT_JIS``,
7749 ``EUC``, ``UTF8``, or ``BRACKETS``. In the character literal
7750 case it is correspondingly one of the characters :kbd:`h`, :kbd:`u`,
7751 :kbd:`s`, :kbd:`e`, :kbd:`8`, or :kbd:`b`.
7753 Note that when the pragma is used within a file, it affects only the
7754 encoding within that file, and does not affect withed units, specs,