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 The current conditions required to support this pragma are:
3654 * Protected type declarations may not contain entries
3655 * Protected subprogram declarations may not have nonelementary parameters
3657 In addition, each protected subprogram body must satisfy:
3659 * May reference only one protected component
3660 * May not reference nonconstant entities outside the protected subprogram
3662 * May not contain address representation items, allocators, or quantified
3664 * May not contain delay, goto, loop, or procedure-call statements.
3665 * May not contain exported and imported entities
3666 * May not dereferenced access values
3667 * Function calls and attribute references must be static
3670 Pragma Loop_Invariant
3671 =====================
3678 pragma Loop_Invariant ( boolean_EXPRESSION );
3681 The effect of this pragma is similar to that of pragma ``Assert``,
3682 except that in an ``Assertion_Policy`` pragma, the identifier
3683 ``Loop_Invariant`` is used to control whether it is ignored or checked
3686 ``Loop_Invariant`` can only appear as one of the items in the sequence
3687 of statements of a loop body, or nested inside block statements that
3688 appear in the sequence of statements of a loop body.
3689 The intention is that it be used to
3690 represent a "loop invariant" assertion, i.e. something that is true each
3691 time through the loop, and which can be used to show that the loop is
3692 achieving its purpose.
3694 Multiple ``Loop_Invariant`` and ``Loop_Variant`` pragmas that
3695 apply to the same loop should be grouped in the same sequence of
3698 To aid in writing such invariants, the special attribute ``Loop_Entry``
3699 may be used to refer to the value of an expression on entry to the loop. This
3700 attribute can only be used within the expression of a ``Loop_Invariant``
3701 pragma. For full details, see documentation of attribute ``Loop_Entry``.
3703 Pragma Loop_Optimize
3704 ====================
3711 pragma Loop_Optimize (OPTIMIZATION_HINT {, OPTIMIZATION_HINT});
3713 OPTIMIZATION_HINT ::= Ivdep | No_Unroll | Unroll | No_Vector | Vector
3716 This pragma must appear immediately within a loop statement. It allows the
3717 programmer to specify optimization hints for the enclosing loop. The hints
3718 are not mutually exclusive and can be freely mixed, but not all combinations
3719 will yield a sensible outcome.
3721 There are five supported optimization hints for a loop:
3725 The programmer asserts that there are no loop-carried dependencies
3726 which would prevent consecutive iterations of the loop from being
3727 executed simultaneously.
3731 The loop must not be unrolled. This is a strong hint: the compiler will not
3732 unroll a loop marked with this hint.
3736 The loop should be unrolled. This is a weak hint: the compiler will try to
3737 apply unrolling to this loop preferably to other optimizations, notably
3738 vectorization, but there is no guarantee that the loop will be unrolled.
3742 The loop must not be vectorized. This is a strong hint: the compiler will not
3743 vectorize a loop marked with this hint.
3747 The loop should be vectorized. This is a weak hint: the compiler will try to
3748 apply vectorization to this loop preferably to other optimizations, notably
3749 unrolling, but there is no guarantee that the loop will be vectorized.
3752 These hints do not remove the need to pass the appropriate switches to the
3753 compiler in order to enable the relevant optimizations, that is to say
3754 *-funroll-loops* for unrolling and *-ftree-vectorize* for
3765 pragma Loop_Variant ( LOOP_VARIANT_ITEM {, LOOP_VARIANT_ITEM } );
3766 LOOP_VARIANT_ITEM ::= CHANGE_DIRECTION => discrete_EXPRESSION
3767 CHANGE_DIRECTION ::= Increases | Decreases
3770 ``Loop_Variant`` can only appear as one of the items in the sequence
3771 of statements of a loop body, or nested inside block statements that
3772 appear in the sequence of statements of a loop body.
3773 It allows the specification of quantities which must always
3774 decrease or increase in successive iterations of the loop. In its simplest
3775 form, just one expression is specified, whose value must increase or decrease
3776 on each iteration of the loop.
3778 In a more complex form, multiple arguments can be given which are intepreted
3779 in a nesting lexicographic manner. For example:
3783 pragma Loop_Variant (Increases => X, Decreases => Y);
3786 specifies that each time through the loop either X increases, or X stays
3787 the same and Y decreases. A ``Loop_Variant`` pragma ensures that the
3788 loop is making progress. It can be useful in helping to show informally
3789 or prove formally that the loop always terminates.
3791 ``Loop_Variant`` is an assertion whose effect can be controlled using
3792 an ``Assertion_Policy`` with a check name of ``Loop_Variant``. The
3793 policy can be ``Check`` to enable the loop variant check, ``Ignore``
3794 to ignore the check (in which case the pragma has no effect on the program),
3795 or ``Disable`` in which case the pragma is not even checked for correct
3798 Multiple ``Loop_Invariant`` and ``Loop_Variant`` pragmas that
3799 apply to the same loop should be grouped in the same sequence of
3802 The ``Loop_Entry`` attribute may be used within the expressions of the
3803 ``Loop_Variant`` pragma to refer to values on entry to the loop.
3805 Pragma Machine_Attribute
3806 ========================
3813 pragma Machine_Attribute (
3814 [Entity =>] LOCAL_NAME,
3815 [Attribute_Name =>] static_string_EXPRESSION
3816 [, [Info =>] static_EXPRESSION {, static_EXPRESSION}] );
3819 Machine-dependent attributes can be specified for types and/or
3820 declarations. This pragma is semantically equivalent to
3821 :samp:`__attribute__(({attribute_name}))` (if ``info`` is not
3822 specified) or :samp:`__attribute__(({attribute_name(info})))`
3823 or :samp:`__attribute__(({attribute_name(info,...})))` in GNU C,
3824 where *attribute_name* is recognized by the compiler middle-end
3825 or the ``TARGET_ATTRIBUTE_TABLE`` machine specific macro. Note
3826 that a string literal for the optional parameter ``info`` or the
3827 following ones is transformed by default into an identifier,
3828 which may make this pragma unusable for some attributes.
3829 For further information see :title:`GNU Compiler Collection (GCC) Internals`.
3837 (MAIN_OPTION [, MAIN_OPTION]);
3840 [Stack_Size =>] static_integer_EXPRESSION
3841 | [Task_Stack_Size_Default =>] static_integer_EXPRESSION
3842 | [Time_Slicing_Enabled =>] static_boolean_EXPRESSION
3845 This pragma is provided for compatibility with OpenVMS VAX Systems. It has
3846 no effect in GNAT, other than being syntax checked.
3854 (MAIN_STORAGE_OPTION [, MAIN_STORAGE_OPTION]);
3856 MAIN_STORAGE_OPTION ::=
3857 [WORKING_STORAGE =>] static_SIMPLE_EXPRESSION
3858 | [TOP_GUARD =>] static_SIMPLE_EXPRESSION
3861 This pragma is provided for compatibility with OpenVMS VAX Systems. It has
3862 no effect in GNAT, other than being syntax checked.
3864 .. _Pragma-Max_Queue_Length:
3866 Pragma Max_Queue_Length
3867 =======================
3871 pragma Max_Entry_Queue (static_integer_EXPRESSION);
3874 This pragma is used to specify the maximum callers per entry queue for
3875 individual protected entries and entry families. It accepts a single
3876 positive integer as a parameter and must appear after the declaration
3890 There are a number of cases in which a package spec does not require a body,
3891 and in fact a body is not permitted. GNAT will not permit the spec to be
3892 compiled if there is a body around. The pragma No_Body allows you to provide
3893 a body file, even in a case where no body is allowed. The body file must
3894 contain only comments and a single No_Body pragma. This is recognized by
3895 the compiler as indicating that no body is logically present.
3897 This is particularly useful during maintenance when a package is modified in
3898 such a way that a body needed before is no longer needed. The provision of a
3899 dummy body with a No_Body pragma ensures that there is no interference from
3900 earlier versions of the package body.
3902 .. _Pragma-No_Caching:
3911 pragma No_Caching [ (boolean_EXPRESSION) ];
3913 For the semantics of this pragma, see the entry for aspect ``No_Caching`` in
3914 the SPARK 2014 Reference Manual, section 7.1.2.
3916 Pragma No_Component_Reordering
3917 ==============================
3924 pragma No_Component_Reordering [([Entity =>] type_LOCAL_NAME)];
3927 ``type_LOCAL_NAME`` must refer to a record type declaration in the current
3928 declarative part. The effect is to preclude any reordering of components
3929 for the layout of the record, i.e. the record is laid out by the compiler
3930 in the order in which the components are declared textually. The form with
3931 no argument is a configuration pragma which applies to all record types
3932 declared in units to which the pragma applies and there is a requirement
3933 that this pragma be used consistently within a partition.
3935 .. _Pragma-No_Elaboration_Code_All:
3937 Pragma No_Elaboration_Code_All
3938 ==============================
3945 pragma No_Elaboration_Code_All [(program_unit_NAME)];
3948 This is a program unit pragma (there is also an equivalent aspect of the
3949 same name) that establishes the restriction ``No_Elaboration_Code`` for
3950 the current unit and any extended main source units (body and subunits).
3951 It also has the effect of enforcing a transitive application of this
3952 aspect, so that if any unit is implicitly or explicitly with'ed by the
3953 current unit, it must also have the No_Elaboration_Code_All aspect set.
3954 It may be applied to package or subprogram specs or their generic versions.
3956 Pragma No_Heap_Finalization
3957 ===========================
3964 pragma No_Heap_Finalization [ (first_subtype_LOCAL_NAME) ];
3967 Pragma ``No_Heap_Finalization`` may be used as a configuration pragma or as a
3968 type-specific pragma.
3970 In its configuration form, the pragma must appear within a configuration file
3971 such as gnat.adc, without an argument. The pragma suppresses the call to
3972 ``Finalize`` for heap-allocated objects created through library-level named
3973 access-to-object types in cases where the designated type requires finalization
3976 In its type-specific form, the argument of the pragma must denote a
3977 library-level named access-to-object type. The pragma suppresses the call to
3978 ``Finalize`` for heap-allocated objects created through the specific access type
3979 in cases where the designated type requires finalization actions.
3981 It is still possible to finalize such heap-allocated objects by explicitly
3984 A library-level named access-to-object type declared within a generic unit will
3985 lose its ``No_Heap_Finalization`` pragma when the corresponding instance does not
3986 appear at the library level.
3988 .. _Pragma-No_Inline:
3998 pragma No_Inline (NAME {, NAME});
4001 This pragma suppresses inlining for the callable entity or the instances of
4002 the generic subprogram designated by ``NAME``, including inlining that
4003 results from the use of pragma ``Inline``. This pragma is always active,
4004 in particular it is not subject to the use of option *-gnatn* or
4005 *-gnatN*. It is illegal to specify both pragma ``No_Inline`` and
4006 pragma ``Inline_Always`` for the same ``NAME``.
4016 pragma No_Return (procedure_LOCAL_NAME {, procedure_LOCAL_NAME});
4019 Each ``procedure_LOCAL_NAME`` argument must refer to one or more procedure
4020 declarations in the current declarative part. A procedure to which this
4021 pragma is applied may not contain any explicit ``return`` statements.
4022 In addition, if the procedure contains any implicit returns from falling
4023 off the end of a statement sequence, then execution of that implicit
4024 return will cause Program_Error to be raised.
4026 One use of this pragma is to identify procedures whose only purpose is to raise
4027 an exception. Another use of this pragma is to suppress incorrect warnings
4028 about missing returns in functions, where the last statement of a function
4029 statement sequence is a call to such a procedure.
4031 Note that in Ada 2005 mode, this pragma is part of the language. It is
4032 available in all earlier versions of Ada as an implementation-defined
4046 This is an obsolete configuration pragma that historically was used to
4047 set up a runtime library with no object code. It is now used only for
4048 internal testing. The pragma has been superseded by the reconfigurable
4049 runtime capability of GNAT.
4051 Pragma No_Strict_Aliasing
4052 =========================
4059 pragma No_Strict_Aliasing [([Entity =>] type_LOCAL_NAME)];
4062 ``type_LOCAL_NAME`` must refer to an access type
4063 declaration in the current declarative part. The effect is to inhibit
4064 strict aliasing optimization for the given type. The form with no
4065 arguments is a configuration pragma which applies to all access types
4066 declared in units to which the pragma applies. For a detailed
4067 description of the strict aliasing optimization, and the situations
4068 in which it must be suppressed, see the section on Optimization and Strict Aliasing
4069 in the :title:`GNAT User's Guide`.
4071 This pragma currently has no effects on access to unconstrained array types.
4073 .. _Pragma-No_Tagged_Streams:
4075 Pragma No_Tagged_Streams
4076 ========================
4083 pragma No_Tagged_Streams [([Entity =>] tagged_type_LOCAL_NAME)];
4086 Normally when a tagged type is introduced using a full type declaration,
4087 part of the processing includes generating stream access routines to be
4088 used by stream attributes referencing the type (or one of its subtypes
4089 or derived types). This can involve the generation of significant amounts
4090 of code which is wasted space if stream routines are not needed for the
4093 The ``No_Tagged_Streams`` pragma causes the generation of these stream
4094 routines to be skipped, and any attempt to use stream operations on
4095 types subject to this pragma will be statically rejected as illegal.
4097 There are two forms of the pragma. The form with no arguments must appear
4098 in a declarative sequence or in the declarations of a package spec. This
4099 pragma affects all subsequent root tagged types declared in the declaration
4100 sequence, and specifies that no stream routines be generated. The form with
4101 an argument (for which there is also a corresponding aspect) specifies a
4102 single root tagged type for which stream routines are not to be generated.
4104 Once the pragma has been given for a particular root tagged type, all subtypes
4105 and derived types of this type inherit the pragma automatically, so the effect
4106 applies to a complete hierarchy (this is necessary to deal with the class-wide
4107 dispatching versions of the stream routines).
4109 When pragmas ``Discard_Names`` and ``No_Tagged_Streams`` are simultaneously
4110 applied to a tagged type its Expanded_Name and External_Tag are initialized
4111 with empty strings. This is useful to avoid exposing entity names at binary
4112 level but has a negative impact on the debuggability of tagged types.
4114 Pragma Normalize_Scalars
4115 ========================
4122 pragma Normalize_Scalars;
4125 This is a language defined pragma which is fully implemented in GNAT. The
4126 effect is to cause all scalar objects that are not otherwise initialized
4127 to be initialized. The initial values are implementation dependent and
4132 *Standard.Character*
4133 Objects whose root type is Standard.Character are initialized to
4134 Character'Last unless the subtype range excludes NUL (in which case
4135 NUL is used). This choice will always generate an invalid value if
4139 *Standard.Wide_Character*
4140 Objects whose root type is Standard.Wide_Character are initialized to
4141 Wide_Character'Last unless the subtype range excludes NUL (in which case
4142 NUL is used). This choice will always generate an invalid value if
4146 *Standard.Wide_Wide_Character*
4147 Objects whose root type is Standard.Wide_Wide_Character are initialized to
4148 the invalid value 16#FFFF_FFFF# unless the subtype range excludes NUL (in
4149 which case NUL is used). This choice will always generate an invalid value if
4154 Objects of an integer type are treated differently depending on whether
4155 negative values are present in the subtype. If no negative values are
4156 present, then all one bits is used as the initial value except in the
4157 special case where zero is excluded from the subtype, in which case
4158 all zero bits are used. This choice will always generate an invalid
4159 value if one exists.
4161 For subtypes with negative values present, the largest negative number
4162 is used, except in the unusual case where this largest negative number
4163 is in the subtype, and the largest positive number is not, in which case
4164 the largest positive value is used. This choice will always generate
4165 an invalid value if one exists.
4168 *Floating-Point Types*
4169 Objects of all floating-point types are initialized to all 1-bits. For
4170 standard IEEE format, this corresponds to a NaN (not a number) which is
4171 indeed an invalid value.
4175 Objects of all fixed-point types are treated as described above for integers,
4176 with the rules applying to the underlying integer value used to represent
4177 the fixed-point value.
4181 Objects of a modular type are initialized to all one bits, except in
4182 the special case where zero is excluded from the subtype, in which
4183 case all zero bits are used. This choice will always generate an
4184 invalid value if one exists.
4188 Objects of an enumeration type are initialized to all one-bits, i.e., to
4189 the value ``2 ** typ'Size - 1`` unless the subtype excludes the literal
4190 whose Pos value is zero, in which case a code of zero is used. This choice
4191 will always generate an invalid value if one exists.
4193 .. _Pragma_Obsolescent:
4205 pragma Obsolescent (
4206 [Message =>] static_string_EXPRESSION
4207 [,[Version =>] Ada_05]]);
4209 pragma Obsolescent (
4211 [,[Message =>] static_string_EXPRESSION
4212 [,[Version =>] Ada_05]] );
4215 This pragma can occur immediately following a declaration of an entity,
4216 including the case of a record component. If no Entity argument is present,
4217 then this declaration is the one to which the pragma applies. If an Entity
4218 parameter is present, it must either match the name of the entity in this
4219 declaration, or alternatively, the pragma can immediately follow an enumeration
4220 type declaration, where the Entity argument names one of the enumeration
4223 This pragma is used to indicate that the named entity
4224 is considered obsolescent and should not be used. Typically this is
4225 used when an API must be modified by eventually removing or modifying
4226 existing subprograms or other entities. The pragma can be used at an
4227 intermediate stage when the entity is still present, but will be
4230 The effect of this pragma is to output a warning message on a reference to
4231 an entity thus marked that the subprogram is obsolescent if the appropriate
4232 warning option in the compiler is activated. If the ``Message`` parameter is
4233 present, then a second warning message is given containing this text. In
4234 addition, a reference to the entity is considered to be a violation of pragma
4235 ``Restrictions (No_Obsolescent_Features)``.
4237 This pragma can also be used as a program unit pragma for a package,
4238 in which case the entity name is the name of the package, and the
4239 pragma indicates that the entire package is considered
4240 obsolescent. In this case a client ``with``\ ing such a package
4241 violates the restriction, and the ``with`` clause is
4242 flagged with warnings if the warning option is set.
4244 If the ``Version`` parameter is present (which must be exactly
4245 the identifier ``Ada_05``, no other argument is allowed), then the
4246 indication of obsolescence applies only when compiling in Ada 2005
4247 mode. This is primarily intended for dealing with the situations
4248 in the predefined library where subprograms or packages
4249 have become defined as obsolescent in Ada 2005
4250 (e.g., in ``Ada.Characters.Handling``), but may be used anywhere.
4252 The following examples show typical uses of this pragma:
4258 pragma Obsolescent (p, Message => "use pp instead of p");
4263 pragma Obsolescent ("use q2new instead");
4265 type R is new integer;
4268 Message => "use RR in Ada 2005",
4278 type E is (a, bc, 'd', quack);
4279 pragma Obsolescent (Entity => bc)
4280 pragma Obsolescent (Entity => 'd')
4283 (a, b : character) return character;
4284 pragma Obsolescent (Entity => "+");
4288 Note that, as for all pragmas, if you use a pragma argument identifier,
4289 then all subsequent parameters must also use a pragma argument identifier.
4290 So if you specify ``Entity =>`` for the ``Entity`` argument, and a ``Message``
4291 argument is present, it must be preceded by ``Message =>``.
4293 Pragma Optimize_Alignment
4294 =========================
4295 .. index:: Alignment, default settings
4302 pragma Optimize_Alignment (TIME | SPACE | OFF);
4305 This is a configuration pragma which affects the choice of default alignments
4306 for types and objects where no alignment is explicitly specified. There is a
4307 time/space trade-off in the selection of these values. Large alignments result
4308 in more efficient code, at the expense of larger data space, since sizes have
4309 to be increased to match these alignments. Smaller alignments save space, but
4310 the access code is slower. The normal choice of default alignments for types
4311 and individual alignment promotions for objects (which is what you get if you
4312 do not use this pragma, or if you use an argument of OFF), tries to balance
4313 these two requirements.
4315 Specifying SPACE causes smaller default alignments to be chosen in two cases.
4316 First any packed record is given an alignment of 1. Second, if a size is given
4317 for the type, then the alignment is chosen to avoid increasing this size. For
4331 In the default mode, this type gets an alignment of 4, so that access to the
4332 Integer field X are efficient. But this means that objects of the type end up
4333 with a size of 8 bytes. This is a valid choice, since sizes of objects are
4334 allowed to be bigger than the size of the type, but it can waste space if for
4335 example fields of type R appear in an enclosing record. If the above type is
4336 compiled in ``Optimize_Alignment (Space)`` mode, the alignment is set to 1.
4338 However, there is one case in which SPACE is ignored. If a variable length
4339 record (that is a discriminated record with a component which is an array
4340 whose length depends on a discriminant), has a pragma Pack, then it is not
4341 in general possible to set the alignment of such a record to one, so the
4342 pragma is ignored in this case (with a warning).
4344 Specifying SPACE also disables alignment promotions for standalone objects,
4345 which occur when the compiler increases the alignment of a specific object
4346 without changing the alignment of its type.
4348 Specifying SPACE also disables component reordering in unpacked record types,
4349 which can result in larger sizes in order to meet alignment requirements.
4351 Specifying TIME causes larger default alignments to be chosen in the case of
4352 small types with sizes that are not a power of 2. For example, consider:
4367 The default alignment for this record is normally 1, but if this type is
4368 compiled in ``Optimize_Alignment (Time)`` mode, then the alignment is set
4369 to 4, which wastes space for objects of the type, since they are now 4 bytes
4370 long, but results in more efficient access when the whole record is referenced.
4372 As noted above, this is a configuration pragma, and there is a requirement
4373 that all units in a partition be compiled with a consistent setting of the
4374 optimization setting. This would normally be achieved by use of a configuration
4375 pragma file containing the appropriate setting. The exception to this rule is
4376 that units with an explicit configuration pragma in the same file as the source
4377 unit are excluded from the consistency check, as are all predefined units. The
4378 latter are compiled by default in pragma Optimize_Alignment (Off) mode if no
4379 pragma appears at the start of the file.
4389 pragma Ordered (enumeration_first_subtype_LOCAL_NAME);
4392 Most enumeration types are from a conceptual point of view unordered.
4393 For example, consider:
4398 type Color is (Red, Blue, Green, Yellow);
4401 By Ada semantics ``Blue > Red`` and ``Green > Blue``,
4402 but really these relations make no sense; the enumeration type merely
4403 specifies a set of possible colors, and the order is unimportant.
4405 For unordered enumeration types, it is generally a good idea if
4406 clients avoid comparisons (other than equality or inequality) and
4407 explicit ranges. (A *client* is a unit where the type is referenced,
4408 other than the unit where the type is declared, its body, and its subunits.)
4409 For example, if code buried in some client says:
4414 if Current_Color < Yellow then ...
4415 if Current_Color in Blue .. Green then ...
4418 then the client code is relying on the order, which is undesirable.
4419 It makes the code hard to read and creates maintenance difficulties if
4420 entries have to be added to the enumeration type. Instead,
4421 the code in the client should list the possibilities, or an
4422 appropriate subtype should be declared in the unit that declares
4423 the original enumeration type. E.g., the following subtype could
4424 be declared along with the type ``Color``:
4429 subtype RBG is Color range Red .. Green;
4432 and then the client could write:
4437 if Current_Color in RBG then ...
4438 if Current_Color = Blue or Current_Color = Green then ...
4441 However, some enumeration types are legitimately ordered from a conceptual
4442 point of view. For example, if you declare:
4447 type Day is (Mon, Tue, Wed, Thu, Fri, Sat, Sun);
4450 then the ordering imposed by the language is reasonable, and
4451 clients can depend on it, writing for example:
4456 if D in Mon .. Fri then ...
4460 The pragma *Ordered* is provided to mark enumeration types that
4461 are conceptually ordered, alerting the reader that clients may depend
4462 on the ordering. GNAT provides a pragma to mark enumerations as ordered
4463 rather than one to mark them as unordered, since in our experience,
4464 the great majority of enumeration types are conceptually unordered.
4466 The types ``Boolean``, ``Character``, ``Wide_Character``,
4467 and ``Wide_Wide_Character``
4468 are considered to be ordered types, so each is declared with a
4469 pragma ``Ordered`` in package ``Standard``.
4471 Normally pragma ``Ordered`` serves only as documentation and a guide for
4472 coding standards, but GNAT provides a warning switch *-gnatw.u* that
4473 requests warnings for inappropriate uses (comparisons and explicit
4474 subranges) for unordered types. If this switch is used, then any
4475 enumeration type not marked with pragma ``Ordered`` will be considered
4476 as unordered, and will generate warnings for inappropriate uses.
4478 Note that generic types are not considered ordered or unordered (since the
4479 template can be instantiated for both cases), so we never generate warnings
4480 for the case of generic enumerated types.
4482 For additional information please refer to the description of the
4483 *-gnatw.u* switch in the GNAT User's Guide.
4485 Pragma Overflow_Mode
4486 ====================
4493 pragma Overflow_Mode
4495 [,[Assertions =>] MODE]);
4497 MODE ::= STRICT | MINIMIZED | ELIMINATED
4500 This pragma sets the current overflow mode to the given setting. For details
4501 of the meaning of these modes, please refer to the
4502 'Overflow Check Handling in GNAT' appendix in the
4503 GNAT User's Guide. If only the ``General`` parameter is present,
4504 the given mode applies to all expressions. If both parameters are present,
4505 the ``General`` mode applies to expressions outside assertions, and
4506 the ``Eliminated`` mode applies to expressions within assertions.
4508 The case of the ``MODE`` parameter is ignored,
4509 so ``MINIMIZED``, ``Minimized`` and
4510 ``minimized`` all have the same effect.
4512 The ``Overflow_Mode`` pragma has the same scoping and placement
4513 rules as pragma ``Suppress``, so it can occur either as a
4514 configuration pragma, specifying a default for the whole
4515 program, or in a declarative scope, where it applies to the
4516 remaining declarations and statements in that scope.
4518 The pragma ``Suppress (Overflow_Check)`` suppresses
4519 overflow checking, but does not affect the overflow mode.
4521 The pragma ``Unsuppress (Overflow_Check)`` unsuppresses (enables)
4522 overflow checking, but does not affect the overflow mode.
4524 Pragma Overriding_Renamings
4525 ===========================
4526 .. index:: Rational profile
4528 .. index:: Rational compatibility
4535 pragma Overriding_Renamings;
4538 This is a GNAT configuration pragma to simplify porting
4539 legacy code accepted by the Rational
4540 Ada compiler. In the presence of this pragma, a renaming declaration that
4541 renames an inherited operation declared in the same scope is legal if selected
4542 notation is used as in:
4547 pragma Overriding_Renamings;
4552 function F (..) renames R.F;
4557 RM 8.3 (15) stipulates that an overridden operation is not visible within the
4558 declaration of the overriding operation.
4560 Pragma Partition_Elaboration_Policy
4561 ===================================
4568 pragma Partition_Elaboration_Policy (POLICY_IDENTIFIER);
4570 POLICY_IDENTIFIER ::= Concurrent | Sequential
4573 This pragma is standard in Ada 2005, but is available in all earlier
4574 versions of Ada as an implementation-defined pragma.
4575 See Ada 2012 Reference Manual for details.
4586 pragma Part_Of (ABSTRACT_STATE);
4588 ABSTRACT_STATE ::= NAME
4590 For the semantics of this pragma, see the entry for aspect ``Part_Of`` in the
4591 SPARK 2014 Reference Manual, section 7.2.6.
4601 pragma Passive [(Semaphore | No)];
4604 Syntax checked, but otherwise ignored by GNAT. This is recognized for
4605 compatibility with DEC Ada 83 implementations, where it is used within a
4606 task definition to request that a task be made passive. If the argument
4607 ``Semaphore`` is present, or the argument is omitted, then DEC Ada 83
4608 treats the pragma as an assertion that the containing task is passive
4609 and that optimization of context switch with this task is permitted and
4610 desired. If the argument ``No`` is present, the task must not be
4611 optimized. GNAT does not attempt to optimize any tasks in this manner
4612 (since protected objects are available in place of passive tasks).
4614 For more information on the subject of passive tasks, see the section
4615 'Passive Task Optimization' in the GNAT Users Guide.
4617 .. _Pragma-Persistent_BSS:
4619 Pragma Persistent_BSS
4620 =====================
4627 pragma Persistent_BSS [(LOCAL_NAME)]
4630 This pragma allows selected objects to be placed in the ``.persistent_bss``
4631 section. On some targets the linker and loader provide for special
4632 treatment of this section, allowing a program to be reloaded without
4633 affecting the contents of this data (hence the name persistent).
4635 There are two forms of usage. If an argument is given, it must be the
4636 local name of a library-level object, with no explicit initialization
4637 and whose type is potentially persistent. If no argument is given, then
4638 the pragma is a configuration pragma, and applies to all library-level
4639 objects with no explicit initialization of potentially persistent types.
4641 A potentially persistent type is a scalar type, or an untagged,
4642 non-discriminated record, all of whose components have no explicit
4643 initialization and are themselves of a potentially persistent type,
4644 or an array, all of whose constraints are static, and whose component
4645 type is potentially persistent.
4647 If this pragma is used on a target where this feature is not supported,
4648 then the pragma will be ignored. See also ``pragma Linker_Section``.
4658 pragma Polling (ON | OFF);
4661 This pragma controls the generation of polling code. This is normally off.
4662 If ``pragma Polling (ON)`` is used then periodic calls are generated to
4663 the routine ``Ada.Exceptions.Poll``. This routine is a separate unit in the
4664 runtime library, and can be found in file :file:`a-excpol.adb`.
4666 Pragma ``Polling`` can appear as a configuration pragma (for example it
4667 can be placed in the :file:`gnat.adc` file) to enable polling globally, or it
4668 can be used in the statement or declaration sequence to control polling
4671 A call to the polling routine is generated at the start of every loop and
4672 at the start of every subprogram call. This guarantees that the ``Poll``
4673 routine is called frequently, and places an upper bound (determined by
4674 the complexity of the code) on the period between two ``Poll`` calls.
4676 The primary purpose of the polling interface is to enable asynchronous
4677 aborts on targets that cannot otherwise support it (for example Windows
4678 NT), but it may be used for any other purpose requiring periodic polling.
4679 The standard version is null, and can be replaced by a user program. This
4680 will require re-compilation of the ``Ada.Exceptions`` package that can
4681 be found in files :file:`a-except.ads` and :file:`a-except.adb`.
4683 A standard alternative unit (in file :file:`4wexcpol.adb` in the standard GNAT
4684 distribution) is used to enable the asynchronous abort capability on
4685 targets that do not normally support the capability. The version of
4686 ``Poll`` in this file makes a call to the appropriate runtime routine
4687 to test for an abort condition.
4689 Note that polling can also be enabled by use of the *-gnatP* switch.
4690 See the section on switches for gcc in the :title:`GNAT User's Guide`.
4696 .. index:: Checks, postconditions
4704 pragma Post (Boolean_Expression);
4707 The ``Post`` pragma is intended to be an exact replacement for
4708 the language-defined
4709 ``Post`` aspect, and shares its restrictions and semantics.
4710 It must appear either immediately following the corresponding
4711 subprogram declaration (only other pragmas may intervene), or
4712 if there is no separate subprogram declaration, then it can
4713 appear at the start of the declarations in a subprogram body
4714 (preceded only by other pragmas).
4716 Pragma Postcondition
4717 ====================
4718 .. index:: Postcondition
4720 .. index:: Checks, postconditions
4728 pragma Postcondition (
4729 [Check =>] Boolean_Expression
4730 [,[Message =>] String_Expression]);
4733 The ``Postcondition`` pragma allows specification of automatic
4734 postcondition checks for subprograms. These checks are similar to
4735 assertions, but are automatically inserted just prior to the return
4736 statements of the subprogram with which they are associated (including
4737 implicit returns at the end of procedure bodies and associated
4738 exception handlers).
4740 In addition, the boolean expression which is the condition which
4741 must be true may contain references to function'Result in the case
4742 of a function to refer to the returned value.
4744 ``Postcondition`` pragmas may appear either immediately following the
4745 (separate) declaration of a subprogram, or at the start of the
4746 declarations of a subprogram body. Only other pragmas may intervene
4747 (that is appear between the subprogram declaration and its
4748 postconditions, or appear before the postcondition in the
4749 declaration sequence in a subprogram body). In the case of a
4750 postcondition appearing after a subprogram declaration, the
4751 formal arguments of the subprogram are visible, and can be
4752 referenced in the postcondition expressions.
4754 The postconditions are collected and automatically tested just
4755 before any return (implicit or explicit) in the subprogram body.
4756 A postcondition is only recognized if postconditions are active
4757 at the time the pragma is encountered. The compiler switch *gnata*
4758 turns on all postconditions by default, and pragma ``Check_Policy``
4759 with an identifier of ``Postcondition`` can also be used to
4760 control whether postconditions are active.
4762 The general approach is that postconditions are placed in the spec
4763 if they represent functional aspects which make sense to the client.
4764 For example we might have:
4769 function Direction return Integer;
4770 pragma Postcondition
4771 (Direction'Result = +1
4773 Direction'Result = -1);
4776 which serves to document that the result must be +1 or -1, and
4777 will test that this is the case at run time if postcondition
4780 Postconditions within the subprogram body can be used to
4781 check that some internal aspect of the implementation,
4782 not visible to the client, is operating as expected.
4783 For instance if a square root routine keeps an internal
4784 counter of the number of times it is called, then we
4785 might have the following postcondition:
4790 Sqrt_Calls : Natural := 0;
4792 function Sqrt (Arg : Float) return Float is
4793 pragma Postcondition
4794 (Sqrt_Calls = Sqrt_Calls'Old + 1);
4799 As this example, shows, the use of the ``Old`` attribute
4800 is often useful in postconditions to refer to the state on
4801 entry to the subprogram.
4803 Note that postconditions are only checked on normal returns
4804 from the subprogram. If an abnormal return results from
4805 raising an exception, then the postconditions are not checked.
4807 If a postcondition fails, then the exception
4808 ``System.Assertions.Assert_Failure`` is raised. If
4809 a message argument was supplied, then the given string
4810 will be used as the exception message. If no message
4811 argument was supplied, then the default message has
4812 the form "Postcondition failed at file_name:line". The
4813 exception is raised in the context of the subprogram
4814 body, so it is possible to catch postcondition failures
4815 within the subprogram body itself.
4817 Within a package spec, normal visibility rules
4818 in Ada would prevent forward references within a
4819 postcondition pragma to functions defined later in
4820 the same package. This would introduce undesirable
4821 ordering constraints. To avoid this problem, all
4822 postcondition pragmas are analyzed at the end of
4823 the package spec, allowing forward references.
4825 The following example shows that this even allows
4826 mutually recursive postconditions as in:
4831 package Parity_Functions is
4832 function Odd (X : Natural) return Boolean;
4833 pragma Postcondition
4837 (x /= 0 and then Even (X - 1))));
4839 function Even (X : Natural) return Boolean;
4840 pragma Postcondition
4844 (x /= 1 and then Odd (X - 1))));
4846 end Parity_Functions;
4849 There are no restrictions on the complexity or form of
4850 conditions used within ``Postcondition`` pragmas.
4851 The following example shows that it is even possible
4852 to verify performance behavior.
4859 Performance : constant Float;
4860 -- Performance constant set by implementation
4861 -- to match target architecture behavior.
4863 procedure Treesort (Arg : String);
4864 -- Sorts characters of argument using N*logN sort
4865 pragma Postcondition
4866 (Float (Clock - Clock'Old) <=
4867 Float (Arg'Length) *
4868 log (Float (Arg'Length)) *
4873 Note: postcondition pragmas associated with subprograms that are
4874 marked as Inline_Always, or those marked as Inline with front-end
4875 inlining (-gnatN option set) are accepted and legality-checked
4876 by the compiler, but are ignored at run-time even if postcondition
4877 checking is enabled.
4879 Note that pragma ``Postcondition`` differs from the language-defined
4880 ``Post`` aspect (and corresponding ``Post`` pragma) in allowing
4881 multiple occurrences, allowing occurences in the body even if there
4882 is a separate spec, and allowing a second string parameter, and the
4883 use of the pragma identifier ``Check``. Historically, pragma
4884 ``Postcondition`` was implemented prior to the development of
4885 Ada 2012, and has been retained in its original form for
4886 compatibility purposes.
4892 .. index:: Checks, postconditions
4900 pragma Post_Class (Boolean_Expression);
4903 The ``Post_Class`` pragma is intended to be an exact replacement for
4904 the language-defined
4905 ``Post'Class`` aspect, and shares its restrictions and semantics.
4906 It must appear either immediately following the corresponding
4907 subprogram declaration (only other pragmas may intervene), or
4908 if there is no separate subprogram declaration, then it can
4909 appear at the start of the declarations in a subprogram body
4910 (preceded only by other pragmas).
4912 Note: This pragma is called ``Post_Class`` rather than
4913 ``Post'Class`` because the latter would not be strictly
4914 conforming to the allowed syntax for pragmas. The motivation
4915 for provinding pragmas equivalent to the aspects is to allow a program
4916 to be written using the pragmas, and then compiled if necessary
4917 using an Ada compiler that does not recognize the pragmas or
4918 aspects, but is prepared to ignore the pragmas. The assertion
4919 policy that controls this pragma is ``Post'Class``, not
4922 Pragma Rename_Pragma
4923 ============================
4924 .. index:: Pragmas, synonyms
4931 pragma Rename_Pragma (
4932 [New_Name =>] IDENTIFIER,
4933 [Renamed =>] pragma_IDENTIFIER);
4935 This pragma provides a mechanism for supplying new names for existing
4936 pragmas. The ``New_Name`` identifier can subsequently be used as a synonym for
4937 the Renamed pragma. For example, suppose you have code that was originally
4938 developed on a compiler that supports Inline_Only as an implementation defined
4939 pragma. And suppose the semantics of pragma Inline_Only are identical to (or at
4940 least very similar to) the GNAT implementation defined pragma
4941 Inline_Always. You could globally replace Inline_Only with Inline_Always.
4943 However, to avoid that source modification, you could instead add a
4944 configuration pragma:
4948 pragma Rename_Pragma (
4949 New_Name => Inline_Only,
4950 Renamed => Inline_Always);
4953 Then GNAT will treat "pragma Inline_Only ..." as if you had written
4954 "pragma Inline_Always ...".
4956 Pragma Inline_Only will not necessarily mean the same thing as the other Ada
4957 compiler; it's up to you to make sure the semantics are close enough.
4963 .. index:: Checks, preconditions
4971 pragma Pre (Boolean_Expression);
4974 The ``Pre`` pragma is intended to be an exact replacement for
4975 the language-defined
4976 ``Pre`` aspect, and shares its restrictions and semantics.
4977 It must appear either immediately following the corresponding
4978 subprogram declaration (only other pragmas may intervene), or
4979 if there is no separate subprogram declaration, then it can
4980 appear at the start of the declarations in a subprogram body
4981 (preceded only by other pragmas).
4985 .. index:: Preconditions
4987 .. index:: Checks, preconditions
4995 pragma Precondition (
4996 [Check =>] Boolean_Expression
4997 [,[Message =>] String_Expression]);
5000 The ``Precondition`` pragma is similar to ``Postcondition``
5001 except that the corresponding checks take place immediately upon
5002 entry to the subprogram, and if a precondition fails, the exception
5003 is raised in the context of the caller, and the attribute 'Result
5004 cannot be used within the precondition expression.
5006 Otherwise, the placement and visibility rules are identical to those
5007 described for postconditions. The following is an example of use
5008 within a package spec:
5013 package Math_Functions is
5015 function Sqrt (Arg : Float) return Float;
5016 pragma Precondition (Arg >= 0.0)
5021 ``Precondition`` pragmas may appear either immediately following the
5022 (separate) declaration of a subprogram, or at the start of the
5023 declarations of a subprogram body. Only other pragmas may intervene
5024 (that is appear between the subprogram declaration and its
5025 postconditions, or appear before the postcondition in the
5026 declaration sequence in a subprogram body).
5028 Note: precondition pragmas associated with subprograms that are
5029 marked as Inline_Always, or those marked as Inline with front-end
5030 inlining (-gnatN option set) are accepted and legality-checked
5031 by the compiler, but are ignored at run-time even if precondition
5032 checking is enabled.
5034 Note that pragma ``Precondition`` differs from the language-defined
5035 ``Pre`` aspect (and corresponding ``Pre`` pragma) in allowing
5036 multiple occurrences, allowing occurences in the body even if there
5037 is a separate spec, and allowing a second string parameter, and the
5038 use of the pragma identifier ``Check``. Historically, pragma
5039 ``Precondition`` was implemented prior to the development of
5040 Ada 2012, and has been retained in its original form for
5041 compatibility purposes.
5043 .. _Pragma-Predicate:
5054 ([Entity =>] type_LOCAL_NAME,
5055 [Check =>] EXPRESSION);
5058 This pragma (available in all versions of Ada in GNAT) encompasses both
5059 the ``Static_Predicate`` and ``Dynamic_Predicate`` aspects in
5060 Ada 2012. A predicate is regarded as static if it has an allowed form
5061 for ``Static_Predicate`` and is otherwise treated as a
5062 ``Dynamic_Predicate``. Otherwise, predicates specified by this
5063 pragma behave exactly as described in the Ada 2012 reference manual.
5064 For example, if we have
5069 type R is range 1 .. 10;
5071 pragma Predicate (Entity => S, Check => S not in 4 .. 6);
5073 pragma Predicate (Entity => Q, Check => F(Q) or G(Q));
5076 the effect is identical to the following Ada 2012 code:
5081 type R is range 1 .. 10;
5083 Static_Predicate => S not in 4 .. 6;
5085 Dynamic_Predicate => F(Q) or G(Q);
5088 Note that there are no pragmas ``Dynamic_Predicate``
5089 or ``Static_Predicate``. That is
5090 because these pragmas would affect legality and semantics of
5091 the program and thus do not have a neutral effect if ignored.
5092 The motivation behind providing pragmas equivalent to
5093 corresponding aspects is to allow a program to be written
5094 using the pragmas, and then compiled with a compiler that
5095 will ignore the pragmas. That doesn't work in the case of
5096 static and dynamic predicates, since if the corresponding
5097 pragmas are ignored, then the behavior of the program is
5098 fundamentally changed (for example a membership test
5099 ``A in B`` would not take into account a predicate
5100 defined for subtype B). When following this approach, the
5101 use of predicates should be avoided.
5103 Pragma Predicate_Failure
5104 ========================
5111 pragma Predicate_Failure
5112 ([Entity =>] type_LOCAL_NAME,
5113 [Message =>] String_Expression);
5116 The ``Predicate_Failure`` pragma is intended to be an exact replacement for
5117 the language-defined
5118 ``Predicate_Failure`` aspect, and shares its restrictions and semantics.
5120 Pragma Preelaborable_Initialization
5121 ===================================
5128 pragma Preelaborable_Initialization (DIRECT_NAME);
5131 This pragma is standard in Ada 2005, but is available in all earlier
5132 versions of Ada as an implementation-defined pragma.
5133 See Ada 2012 Reference Manual for details.
5135 Pragma Prefix_Exception_Messages
5136 ================================
5137 .. index:: Prefix_Exception_Messages
5139 .. index:: exception
5141 .. index:: Exception_Message
5149 pragma Prefix_Exception_Messages;
5152 This is an implementation-defined configuration pragma that affects the
5153 behavior of raise statements with a message given as a static string
5154 constant (typically a string literal). In such cases, the string will
5155 be automatically prefixed by the name of the enclosing entity (giving
5156 the package and subprogram containing the raise statement). This helps
5157 to identify where messages are coming from, and this mode is automatic
5158 for the run-time library.
5160 The pragma has no effect if the message is computed with an expression other
5161 than a static string constant, since the assumption in this case is that
5162 the program computes exactly the string it wants. If you still want the
5163 prefixing in this case, you can always call
5164 ``GNAT.Source_Info.Enclosing_Entity`` and prepend the string manually.
5168 .. index:: Pre_Class
5170 .. index:: Checks, preconditions
5178 pragma Pre_Class (Boolean_Expression);
5181 The ``Pre_Class`` pragma is intended to be an exact replacement for
5182 the language-defined
5183 ``Pre'Class`` aspect, and shares its restrictions and semantics.
5184 It must appear either immediately following the corresponding
5185 subprogram declaration (only other pragmas may intervene), or
5186 if there is no separate subprogram declaration, then it can
5187 appear at the start of the declarations in a subprogram body
5188 (preceded only by other pragmas).
5190 Note: This pragma is called ``Pre_Class`` rather than
5191 ``Pre'Class`` because the latter would not be strictly
5192 conforming to the allowed syntax for pragmas. The motivation
5193 for providing pragmas equivalent to the aspects is to allow a program
5194 to be written using the pragmas, and then compiled if necessary
5195 using an Ada compiler that does not recognize the pragmas or
5196 aspects, but is prepared to ignore the pragmas. The assertion
5197 policy that controls this pragma is ``Pre'Class``, not
5200 Pragma Priority_Specific_Dispatching
5201 ====================================
5208 pragma Priority_Specific_Dispatching (
5210 first_priority_EXPRESSION,
5211 last_priority_EXPRESSION)
5213 POLICY_IDENTIFIER ::=
5214 EDF_Across_Priorities |
5215 FIFO_Within_Priorities |
5216 Non_Preemptive_Within_Priorities |
5217 Round_Robin_Within_Priorities
5220 This pragma is standard in Ada 2005, but is available in all earlier
5221 versions of Ada as an implementation-defined pragma.
5222 See Ada 2012 Reference Manual for details.
5232 pragma Profile (Ravenscar | Restricted | Rational |
5233 GNAT_Extended_Ravenscar | GNAT_Ravenscar_EDF );
5236 This pragma is standard in Ada 2005, but is available in all earlier
5237 versions of Ada as an implementation-defined pragma. This is a
5238 configuration pragma that establishes a set of configuration pragmas
5239 that depend on the argument. ``Ravenscar`` is standard in Ada 2005.
5240 The other possibilities (``Restricted``, ``Rational``,
5241 ``GNAT_Extended_Ravenscar``, ``GNAT_Ravenscar_EDF``)
5242 are implementation-defined. The set of configuration pragmas
5243 is defined in the following sections.
5246 * Pragma Profile (Ravenscar)
5248 The ``Ravenscar`` profile is standard in Ada 2005,
5249 but is available in all earlier
5250 versions of Ada as an implementation-defined pragma. This profile
5251 establishes the following set of configuration pragmas:
5253 * ``Task_Dispatching_Policy (FIFO_Within_Priorities)``
5255 [RM D.2.2] Tasks are dispatched following a preemptive
5256 priority-ordered scheduling policy.
5259 * ``Locking_Policy (Ceiling_Locking)``
5261 [RM D.3] While tasks and interrupts execute a protected action, they inherit
5262 the ceiling priority of the corresponding protected object.
5265 * ``Detect_Blocking``
5267 This pragma forces the detection of potentially blocking operations within a
5268 protected operation, and to raise Program_Error if that happens.
5270 plus the following set of restrictions:
5272 * ``Max_Entry_Queue_Length => 1``
5274 No task can be queued on a protected entry.
5276 * ``Max_Protected_Entries => 1``
5278 * ``Max_Task_Entries => 0``
5280 No rendezvous statements are allowed.
5282 * ``No_Abort_Statements``
5284 * ``No_Dynamic_Attachment``
5286 * ``No_Dynamic_Priorities``
5288 * ``No_Implicit_Heap_Allocations``
5290 * ``No_Local_Protected_Objects``
5292 * ``No_Local_Timing_Events``
5294 * ``No_Protected_Type_Allocators``
5296 * ``No_Relative_Delay``
5298 * ``No_Requeue_Statements``
5300 * ``No_Select_Statements``
5302 * ``No_Specific_Termination_Handlers``
5304 * ``No_Task_Allocators``
5306 * ``No_Task_Hierarchy``
5308 * ``No_Task_Termination``
5310 * ``Simple_Barriers``
5312 The Ravenscar profile also includes the following restrictions that specify
5313 that there are no semantic dependences on the corresponding predefined
5316 * ``No_Dependence => Ada.Asynchronous_Task_Control``
5318 * ``No_Dependence => Ada.Calendar``
5320 * ``No_Dependence => Ada.Execution_Time.Group_Budget``
5322 * ``No_Dependence => Ada.Execution_Time.Timers``
5324 * ``No_Dependence => Ada.Task_Attributes``
5326 * ``No_Dependence => System.Multiprocessors.Dispatching_Domains``
5328 This set of configuration pragmas and restrictions correspond to the
5329 definition of the 'Ravenscar Profile' for limited tasking, devised and
5330 published by the :title:`International Real-Time Ada Workshop, 1997`.
5331 A description is also available at
5332 `http://www-users.cs.york.ac.uk/~burns/ravenscar.ps <http://www-users.cs.york.ac.uk/~burns/ravenscar.ps>`_.
5334 The original definition of the profile was revised at subsequent IRTAW
5335 meetings. It has been included in the ISO
5336 :title:`Guide for the Use of the Ada Programming Language in High Integrity Systems`,
5337 and was made part of the Ada 2005 standard.
5338 The formal definition given by
5339 the Ada Rapporteur Group (ARG) can be found in two Ada Issues (AI-249 and
5340 AI-305) available at
5341 `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
5342 `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>`_.
5344 The above set is a superset of the restrictions provided by pragma
5345 ``Profile (Restricted)``, it includes six additional restrictions
5346 (``Simple_Barriers``, ``No_Select_Statements``,
5347 ``No_Calendar``, ``No_Implicit_Heap_Allocations``,
5348 ``No_Relative_Delay`` and ``No_Task_Termination``). This means
5349 that pragma ``Profile (Ravenscar)``, like the pragma
5350 ``Profile (Restricted)``,
5351 automatically causes the use of a simplified,
5352 more efficient version of the tasking run-time library.
5354 * Pragma Profile (GNAT_Extended_Ravenscar)
5356 This profile corresponds to a GNAT specific extension of the
5357 Ravenscar profile. The profile may change in the future although
5358 only in a compatible way: some restrictions may be removed or
5359 relaxed. It is defined as a variation of the Ravenscar profile.
5361 The ``No_Implicit_Heap_Allocations`` restriction has been replaced
5362 by ``No_Implicit_Task_Allocations`` and
5363 ``No_Implicit_Protected_Object_Allocations``.
5365 The ``Simple_Barriers`` restriction has been replaced by
5368 The ``Max_Protected_Entries``, ``Max_Entry_Queue_Length``, and
5369 ``No_Relative_Delay`` restrictions have been removed.
5371 * Pragma Profile (GNAT_Ravenscar_EDF)
5373 This profile corresponds to the Ravenscar profile but using
5374 EDF_Across_Priority as the Task_Scheduling_Policy.
5376 * Pragma Profile (Restricted)
5378 This profile corresponds to the GNAT restricted run time. It
5379 establishes the following set of restrictions:
5381 * ``No_Abort_Statements``
5382 * ``No_Entry_Queue``
5383 * ``No_Task_Hierarchy``
5384 * ``No_Task_Allocators``
5385 * ``No_Dynamic_Priorities``
5386 * ``No_Terminate_Alternatives``
5387 * ``No_Dynamic_Attachment``
5388 * ``No_Protected_Type_Allocators``
5389 * ``No_Local_Protected_Objects``
5390 * ``No_Requeue_Statements``
5391 * ``No_Task_Attributes_Package``
5392 * ``Max_Asynchronous_Select_Nesting = 0``
5393 * ``Max_Task_Entries = 0``
5394 * ``Max_Protected_Entries = 1``
5395 * ``Max_Select_Alternatives = 0``
5397 This set of restrictions causes the automatic selection of a simplified
5398 version of the run time that provides improved performance for the
5399 limited set of tasking functionality permitted by this set of restrictions.
5401 * Pragma Profile (Rational)
5403 The Rational profile is intended to facilitate porting legacy code that
5404 compiles with the Rational APEX compiler, even when the code includes non-
5405 conforming Ada constructs. The profile enables the following three pragmas:
5407 * ``pragma Implicit_Packing``
5408 * ``pragma Overriding_Renamings``
5409 * ``pragma Use_VADS_Size``
5412 Pragma Profile_Warnings
5413 =======================
5420 pragma Profile_Warnings (Ravenscar | Restricted | Rational);
5423 This is an implementation-defined pragma that is similar in
5424 effect to ``pragma Profile`` except that instead of
5425 generating ``Restrictions`` pragmas, it generates
5426 ``Restriction_Warnings`` pragmas. The result is that
5427 violations of the profile generate warning messages instead
5430 Pragma Propagate_Exceptions
5431 ===========================
5432 .. index:: Interfacing to C++
5440 pragma Propagate_Exceptions;
5443 This pragma is now obsolete and, other than generating a warning if warnings
5444 on obsolescent features are enabled, is ignored.
5445 It is retained for compatibility
5446 purposes. It used to be used in connection with optimization of
5447 a now-obsolete mechanism for implementation of exceptions.
5449 Pragma Provide_Shift_Operators
5450 ==============================
5451 .. index:: Shift operators
5459 pragma Provide_Shift_Operators (integer_first_subtype_LOCAL_NAME);
5462 This pragma can be applied to a first subtype local name that specifies
5463 either an unsigned or signed type. It has the effect of providing the
5464 five shift operators (Shift_Left, Shift_Right, Shift_Right_Arithmetic,
5465 Rotate_Left and Rotate_Right) for the given type. It is similar to
5466 including the function declarations for these five operators, together
5467 with the pragma Import (Intrinsic, ...) statements.
5477 pragma Psect_Object (
5478 [Internal =>] LOCAL_NAME,
5479 [, [External =>] EXTERNAL_SYMBOL]
5480 [, [Size =>] EXTERNAL_SYMBOL]);
5484 | static_string_EXPRESSION
5487 This pragma is identical in effect to pragma ``Common_Object``.
5489 .. _Pragma-Pure_Function:
5491 Pragma Pure_Function
5492 ====================
5499 pragma Pure_Function ([Entity =>] function_LOCAL_NAME);
5502 This pragma appears in the same declarative part as a function
5503 declaration (or a set of function declarations if more than one
5504 overloaded declaration exists, in which case the pragma applies
5505 to all entities). It specifies that the function ``Entity`` is
5506 to be considered pure for the purposes of code generation. This means
5507 that the compiler can assume that there are no side effects, and
5508 in particular that two calls with identical arguments produce the
5509 same result. It also means that the function can be used in an
5512 Note that, quite deliberately, there are no static checks to try
5513 to ensure that this promise is met, so ``Pure_Function`` can be used
5514 with functions that are conceptually pure, even if they do modify
5515 global variables. For example, a square root function that is
5516 instrumented to count the number of times it is called is still
5517 conceptually pure, and can still be optimized, even though it
5518 modifies a global variable (the count). Memo functions are another
5519 example (where a table of previous calls is kept and consulted to
5520 avoid re-computation).
5522 Note also that the normal rules excluding optimization of subprograms
5523 in pure units (when parameter types are descended from System.Address,
5524 or when the full view of a parameter type is limited), do not apply
5525 for the Pure_Function case. If you explicitly specify Pure_Function,
5526 the compiler may optimize away calls with identical arguments, and
5527 if that results in unexpected behavior, the proper action is not to
5528 use the pragma for subprograms that are not (conceptually) pure.
5530 Note: Most functions in a ``Pure`` package are automatically pure, and
5531 there is no need to use pragma ``Pure_Function`` for such functions. One
5532 exception is any function that has at least one formal of type
5533 ``System.Address`` or a type derived from it. Such functions are not
5534 considered pure by default, since the compiler assumes that the
5535 ``Address`` parameter may be functioning as a pointer and that the
5536 referenced data may change even if the address value does not.
5537 Similarly, imported functions are not considered to be pure by default,
5538 since there is no way of checking that they are in fact pure. The use
5539 of pragma ``Pure_Function`` for such a function will override these default
5540 assumption, and cause the compiler to treat a designated subprogram as pure
5543 Note: If pragma ``Pure_Function`` is applied to a renamed function, it
5544 applies to the underlying renamed function. This can be used to
5545 disambiguate cases of overloading where some but not all functions
5546 in a set of overloaded functions are to be designated as pure.
5548 If pragma ``Pure_Function`` is applied to a library-level function, the
5549 function is also considered pure from an optimization point of view, but the
5550 unit is not a Pure unit in the categorization sense. So for example, a function
5551 thus marked is free to ``with`` non-pure units.
5564 This pragma is considered obsolescent, but is retained for
5565 compatibility purposes. It is equivalent to:
5570 pragma Profile (Rational);
5584 This pragma is considered obsolescent, but is retained for
5585 compatibility purposes. It is equivalent to:
5590 pragma Profile (Ravenscar);
5593 which is the preferred method of setting the ``Ravenscar`` profile.
5595 .. _Pragma-Refined_Depends:
5597 Pragma Refined_Depends
5598 ======================
5604 pragma Refined_Depends (DEPENDENCY_RELATION);
5606 DEPENDENCY_RELATION ::=
5608 | (DEPENDENCY_CLAUSE {, DEPENDENCY_CLAUSE})
5610 DEPENDENCY_CLAUSE ::=
5611 OUTPUT_LIST =>[+] INPUT_LIST
5612 | NULL_DEPENDENCY_CLAUSE
5614 NULL_DEPENDENCY_CLAUSE ::= null => INPUT_LIST
5616 OUTPUT_LIST ::= OUTPUT | (OUTPUT {, OUTPUT})
5618 INPUT_LIST ::= null | INPUT | (INPUT {, INPUT})
5620 OUTPUT ::= NAME | FUNCTION_RESULT
5623 where FUNCTION_RESULT is a function Result attribute_reference
5625 For the semantics of this pragma, see the entry for aspect ``Refined_Depends`` in
5626 the SPARK 2014 Reference Manual, section 6.1.5.
5628 .. _Pragma-Refined_Global:
5630 Pragma Refined_Global
5631 =====================
5637 pragma Refined_Global (GLOBAL_SPECIFICATION);
5639 GLOBAL_SPECIFICATION ::=
5642 | (MODED_GLOBAL_LIST {, MODED_GLOBAL_LIST})
5644 MODED_GLOBAL_LIST ::= MODE_SELECTOR => GLOBAL_LIST
5646 MODE_SELECTOR ::= In_Out | Input | Output | Proof_In
5647 GLOBAL_LIST ::= GLOBAL_ITEM | (GLOBAL_ITEM {, GLOBAL_ITEM})
5648 GLOBAL_ITEM ::= NAME
5650 For the semantics of this pragma, see the entry for aspect ``Refined_Global`` in
5651 the SPARK 2014 Reference Manual, section 6.1.4.
5653 .. _Pragma-Refined_Post:
5662 pragma Refined_Post (boolean_EXPRESSION);
5664 For the semantics of this pragma, see the entry for aspect ``Refined_Post`` in
5665 the SPARK 2014 Reference Manual, section 7.2.7.
5667 .. _Pragma-Refined_State:
5669 Pragma Refined_State
5670 ====================
5676 pragma Refined_State (REFINEMENT_LIST);
5679 (REFINEMENT_CLAUSE {, REFINEMENT_CLAUSE})
5681 REFINEMENT_CLAUSE ::= state_NAME => CONSTITUENT_LIST
5683 CONSTITUENT_LIST ::=
5686 | (CONSTITUENT {, CONSTITUENT})
5688 CONSTITUENT ::= object_NAME | state_NAME
5690 For the semantics of this pragma, see the entry for aspect ``Refined_State`` in
5691 the SPARK 2014 Reference Manual, section 7.2.2.
5693 Pragma Relative_Deadline
5694 ========================
5701 pragma Relative_Deadline (time_span_EXPRESSION);
5704 This pragma is standard in Ada 2005, but is available in all earlier
5705 versions of Ada as an implementation-defined pragma.
5706 See Ada 2012 Reference Manual for details.
5708 .. _Pragma-Remote_Access_Type:
5710 Pragma Remote_Access_Type
5711 =========================
5718 pragma Remote_Access_Type ([Entity =>] formal_access_type_LOCAL_NAME);
5721 This pragma appears in the formal part of a generic declaration.
5722 It specifies an exception to the RM rule from E.2.2(17/2), which forbids
5723 the use of a remote access to class-wide type as actual for a formal
5726 When this pragma applies to a formal access type ``Entity``, that
5727 type is treated as a remote access to class-wide type in the generic.
5728 It must be a formal general access type, and its designated type must
5729 be the class-wide type of a formal tagged limited private type from the
5730 same generic declaration.
5732 In the generic unit, the formal type is subject to all restrictions
5733 pertaining to remote access to class-wide types. At instantiation, the
5734 actual type must be a remote access to class-wide type.
5736 Pragma Restricted_Run_Time
5737 ==========================
5744 pragma Restricted_Run_Time;
5747 This pragma is considered obsolescent, but is retained for
5748 compatibility purposes. It is equivalent to:
5753 pragma Profile (Restricted);
5756 which is the preferred method of setting the restricted run time
5759 Pragma Restriction_Warnings
5760 ===========================
5767 pragma Restriction_Warnings
5768 (restriction_IDENTIFIER {, restriction_IDENTIFIER});
5771 This pragma allows a series of restriction identifiers to be
5772 specified (the list of allowed identifiers is the same as for
5773 pragma ``Restrictions``). For each of these identifiers
5774 the compiler checks for violations of the restriction, but
5775 generates a warning message rather than an error message
5776 if the restriction is violated.
5778 One use of this is in situations where you want to know
5779 about violations of a restriction, but you want to ignore some of
5780 these violations. Consider this example, where you want to set
5781 Ada_95 mode and enable style checks, but you want to know about
5782 any other use of implementation pragmas:
5787 pragma Restriction_Warnings (No_Implementation_Pragmas);
5788 pragma Warnings (Off, "violation of No_Implementation_Pragmas");
5790 pragma Style_Checks ("2bfhkM160");
5791 pragma Warnings (On, "violation of No_Implementation_Pragmas");
5794 By including the above lines in a configuration pragmas file,
5795 the Ada_95 and Style_Checks pragmas are accepted without
5796 generating a warning, but any other use of implementation
5797 defined pragmas will cause a warning to be generated.
5810 This pragma is an RM-defined standard pragma, but has no effect on the
5811 program being compiled, or on the code generated for the program.
5813 To obtain the required output specified in RM H.3.1, the compiler must be
5814 run with various special switches as follows:
5816 * *Where compiler-generated run-time checks remain*
5818 The switch *-gnatGL*
5819 may be used to list the expanded code in pseudo-Ada form.
5820 Runtime checks show up in the listing either as explicit
5821 checks or operators marked with {} to indicate a check is present.
5824 * *An identification of known exceptions at compile time*
5826 If the program is compiled with *-gnatwa*,
5827 the compiler warning messages will indicate all cases where the compiler
5828 detects that an exception is certain to occur at run time.
5831 * *Possible reads of uninitialized variables*
5833 The compiler warns of many such cases, but its output is incomplete.
5835 .. only:: PRO or GPL
5837 The CodePeer analysis tool
5838 may be used to obtain a comprehensive list of all
5839 possible points at which uninitialized data may be read.
5843 A supplemental static analysis tool
5844 may be used to obtain a comprehensive list of all
5845 possible points at which uninitialized data may be read.
5848 * *Where run-time support routines are implicitly invoked*
5850 In the output from *-gnatGL*,
5851 run-time calls are explicitly listed as calls to the relevant
5855 * *Object code listing*
5857 This may be obtained either by using the *-S* switch,
5858 or the objdump utility.
5861 * *Constructs known to be erroneous at compile time*
5863 These are identified by warnings issued by the compiler (use *-gnatwa*).
5866 * *Stack usage information*
5868 Static stack usage data (maximum per-subprogram) can be obtained via the
5869 *-fstack-usage* switch to the compiler.
5870 Dynamic stack usage data (per task) can be obtained via the *-u* switch
5873 .. only:: PRO or GPL
5875 The gnatstack utility
5876 can be used to provide additional information on stack usage.
5879 * *Object code listing of entire partition*
5881 This can be obtained by compiling the partition with *-S*,
5882 or by applying objdump
5883 to all the object files that are part of the partition.
5886 * *A description of the run-time model*
5888 The full sources of the run-time are available, and the documentation of
5889 these routines describes how these run-time routines interface to the
5890 underlying operating system facilities.
5893 * *Control and data-flow information*
5895 .. only:: PRO or GPL
5898 may be used to obtain complete control and data-flow information, as well as
5899 comprehensive messages identifying possible problems based on this
5904 A supplemental static analysis tool
5905 may be used to obtain complete control and data-flow information, as well as
5906 comprehensive messages identifying possible problems based on this
5909 .. _Pragma-Secondary_Stack_Size:
5911 Pragma Secondary_Stack_Size
5912 ===========================
5918 pragma Secondary_Stack_Size (integer_EXPRESSION);
5920 This pragma appears within the task definition of a single task declaration
5921 or a task type declaration (like pragma ``Storage_Size``) and applies to all
5922 task objects of that type. The argument specifies the size of the secondary
5923 stack to be used by these task objects, and must be of an integer type. The
5924 secondary stack is used to handle functions that return a variable-sized
5925 result, for example a function returning an unconstrained String.
5927 Note this pragma only applies to targets using fixed secondary stacks, like
5928 VxWorks 653 and bare board targets, where a fixed block for the
5929 secondary stack is allocated from the primary stack of the task. By default,
5930 these targets assign a percentage of the primary stack for the secondary stack,
5931 as defined by ``System.Parameter.Sec_Stack_Percentage``. With this pragma,
5932 an ``integer_EXPRESSION`` of bytes is assigned from the primary stack instead.
5934 For most targets, the pragma does not apply as the secondary stack grows on
5935 demand: allocated as a chain of blocks in the heap. The default size of these
5936 blocks can be modified via the :switch:`-D` binder option as described in
5937 :title:`GNAT User's Guide`.
5939 Note that no check is made to see if the secondary stack can fit inside the
5942 Note the pragma cannot appear when the restriction ``No_Secondary_Stack``
5945 Pragma Share_Generic
5946 ====================
5953 pragma Share_Generic (GNAME {, GNAME});
5955 GNAME ::= generic_unit_NAME | generic_instance_NAME
5958 This pragma is provided for compatibility with Dec Ada 83. It has
5959 no effect in GNAT (which does not implement shared generics), other
5960 than to check that the given names are all names of generic units or
5968 This pragma is provided for compatibility with Ada 83. The syntax and
5969 semantics are identical to pragma Atomic.
5971 Pragma Short_Circuit_And_Or
5972 ===========================
5979 pragma Short_Circuit_And_Or;
5982 This configuration pragma causes any occurrence of the AND operator applied to
5983 operands of type Standard.Boolean to be short-circuited (i.e. the AND operator
5984 is treated as if it were AND THEN). Or is similarly treated as OR ELSE. This
5985 may be useful in the context of certification protocols requiring the use of
5986 short-circuited logical operators. If this configuration pragma occurs locally
5987 within the file being compiled, it applies only to the file being compiled.
5988 There is no requirement that all units in a partition use this option.
5990 Pragma Short_Descriptors
5991 ========================
5998 pragma Short_Descriptors
6001 This pragma is provided for compatibility with other Ada implementations. It
6002 is recognized but ignored by all current versions of GNAT.
6004 .. _Pragma-Simple_Storage_Pool_Type:
6006 Pragma Simple_Storage_Pool_Type
6007 ===============================
6008 .. index:: Storage pool, simple
6010 .. index:: Simple storage pool
6017 pragma Simple_Storage_Pool_Type (type_LOCAL_NAME);
6020 A type can be established as a 'simple storage pool type' by applying
6021 the representation pragma ``Simple_Storage_Pool_Type`` to the type.
6022 A type named in the pragma must be a library-level immutably limited record
6023 type or limited tagged type declared immediately within a package declaration.
6024 The type can also be a limited private type whose full type is allowed as
6025 a simple storage pool type.
6027 For a simple storage pool type ``SSP``, nonabstract primitive subprograms
6028 ``Allocate``, ``Deallocate``, and ``Storage_Size`` can be declared that
6029 are subtype conformant with the following subprogram declarations:
6036 Storage_Address : out System.Address;
6037 Size_In_Storage_Elements : System.Storage_Elements.Storage_Count;
6038 Alignment : System.Storage_Elements.Storage_Count);
6040 procedure Deallocate
6042 Storage_Address : System.Address;
6043 Size_In_Storage_Elements : System.Storage_Elements.Storage_Count;
6044 Alignment : System.Storage_Elements.Storage_Count);
6046 function Storage_Size (Pool : SSP)
6047 return System.Storage_Elements.Storage_Count;
6050 Procedure ``Allocate`` must be declared, whereas ``Deallocate`` and
6051 ``Storage_Size`` are optional. If ``Deallocate`` is not declared, then
6052 applying an unchecked deallocation has no effect other than to set its actual
6053 parameter to null. If ``Storage_Size`` is not declared, then the
6054 ``Storage_Size`` attribute applied to an access type associated with
6055 a pool object of type SSP returns zero. Additional operations can be declared
6056 for a simple storage pool type (such as for supporting a mark/release
6057 storage-management discipline).
6059 An object of a simple storage pool type can be associated with an access
6060 type by specifying the attribute
6061 :ref:`Simple_Storage_Pool <Attribute_Simple_Storage_Pool>`. For example:
6066 My_Pool : My_Simple_Storage_Pool_Type;
6068 type Acc is access My_Data_Type;
6070 for Acc'Simple_Storage_Pool use My_Pool;
6074 See attribute :ref:`Simple_Storage_Pool <Attribute_Simple_Storage_Pool>`
6075 for further details.
6077 .. _Pragma_Source_File_Name:
6079 Pragma Source_File_Name
6080 =======================
6087 pragma Source_File_Name (
6088 [Unit_Name =>] unit_NAME,
6089 Spec_File_Name => STRING_LITERAL,
6090 [Index => INTEGER_LITERAL]);
6092 pragma Source_File_Name (
6093 [Unit_Name =>] unit_NAME,
6094 Body_File_Name => STRING_LITERAL,
6095 [Index => INTEGER_LITERAL]);
6098 Use this to override the normal naming convention. It is a configuration
6099 pragma, and so has the usual applicability of configuration pragmas
6100 (i.e., it applies to either an entire partition, or to all units in a
6101 compilation, or to a single unit, depending on how it is used.
6102 ``unit_name`` is mapped to ``file_name_literal``. The identifier for
6103 the second argument is required, and indicates whether this is the file
6104 name for the spec or for the body.
6106 The optional Index argument should be used when a file contains multiple
6107 units, and when you do not want to use ``gnatchop`` to separate then
6108 into multiple files (which is the recommended procedure to limit the
6109 number of recompilations that are needed when some sources change).
6110 For instance, if the source file :file:`source.ada` contains
6126 you could use the following configuration pragmas:
6131 pragma Source_File_Name
6132 (B, Spec_File_Name => "source.ada", Index => 1);
6133 pragma Source_File_Name
6134 (A, Body_File_Name => "source.ada", Index => 2);
6137 Note that the ``gnatname`` utility can also be used to generate those
6138 configuration pragmas.
6140 Another form of the ``Source_File_Name`` pragma allows
6141 the specification of patterns defining alternative file naming schemes
6142 to apply to all files.
6147 pragma Source_File_Name
6148 ( [Spec_File_Name =>] STRING_LITERAL
6149 [,[Casing =>] CASING_SPEC]
6150 [,[Dot_Replacement =>] STRING_LITERAL]);
6152 pragma Source_File_Name
6153 ( [Body_File_Name =>] STRING_LITERAL
6154 [,[Casing =>] CASING_SPEC]
6155 [,[Dot_Replacement =>] STRING_LITERAL]);
6157 pragma Source_File_Name
6158 ( [Subunit_File_Name =>] STRING_LITERAL
6159 [,[Casing =>] CASING_SPEC]
6160 [,[Dot_Replacement =>] STRING_LITERAL]);
6162 CASING_SPEC ::= Lowercase | Uppercase | Mixedcase
6165 The first argument is a pattern that contains a single asterisk indicating
6166 the point at which the unit name is to be inserted in the pattern string
6167 to form the file name. The second argument is optional. If present it
6168 specifies the casing of the unit name in the resulting file name string.
6169 The default is lower case. Finally the third argument allows for systematic
6170 replacement of any dots in the unit name by the specified string literal.
6172 Note that Source_File_Name pragmas should not be used if you are using
6173 project files. The reason for this rule is that the project manager is not
6174 aware of these pragmas, and so other tools that use the projet file would not
6175 be aware of the intended naming conventions. If you are using project files,
6176 file naming is controlled by Source_File_Name_Project pragmas, which are
6177 usually supplied automatically by the project manager. A pragma
6178 Source_File_Name cannot appear after a :ref:`Pragma_Source_File_Name_Project`.
6180 For more details on the use of the ``Source_File_Name`` pragma, see the
6181 sections on ``Using Other File Names`` and `Alternative File Naming Schemes'
6182 in the :title:`GNAT User's Guide`.
6184 .. _Pragma_Source_File_Name_Project:
6186 Pragma Source_File_Name_Project
6187 ===============================
6189 This pragma has the same syntax and semantics as pragma Source_File_Name.
6190 It is only allowed as a stand-alone configuration pragma.
6191 It cannot appear after a :ref:`Pragma_Source_File_Name`, and
6192 most importantly, once pragma Source_File_Name_Project appears,
6193 no further Source_File_Name pragmas are allowed.
6195 The intention is that Source_File_Name_Project pragmas are always
6196 generated by the Project Manager in a manner consistent with the naming
6197 specified in a project file, and when naming is controlled in this manner,
6198 it is not permissible to attempt to modify this naming scheme using
6199 Source_File_Name or Source_File_Name_Project pragmas (which would not be
6200 known to the project manager).
6202 Pragma Source_Reference
6203 =======================
6210 pragma Source_Reference (INTEGER_LITERAL, STRING_LITERAL);
6213 This pragma must appear as the first line of a source file.
6214 ``integer_literal`` is the logical line number of the line following
6215 the pragma line (for use in error messages and debugging
6216 information). ``string_literal`` is a static string constant that
6217 specifies the file name to be used in error messages and debugging
6218 information. This is most notably used for the output of ``gnatchop``
6219 with the *-r* switch, to make sure that the original unchopped
6220 source file is the one referred to.
6222 The second argument must be a string literal, it cannot be a static
6223 string expression other than a string literal. This is because its value
6224 is needed for error messages issued by all phases of the compiler.
6226 .. _Pragma-SPARK_Mode:
6236 pragma SPARK_Mode [(On | Off)] ;
6239 In general a program can have some parts that are in SPARK 2014 (and
6240 follow all the rules in the SPARK Reference Manual), and some parts
6241 that are full Ada 2012.
6243 The SPARK_Mode pragma is used to identify which parts are in SPARK
6244 2014 (by default programs are in full Ada). The SPARK_Mode pragma can
6245 be used in the following places:
6249 As a configuration pragma, in which case it sets the default mode for
6250 all units compiled with this pragma.
6253 Immediately following a library-level subprogram spec
6256 Immediately within a library-level package body
6259 Immediately following the ``private`` keyword of a library-level
6263 Immediately following the ``begin`` keyword of a library-level
6267 Immediately within a library-level subprogram body
6270 Normally a subprogram or package spec/body inherits the current mode
6271 that is active at the point it is declared. But this can be overridden
6272 by pragma within the spec or body as above.
6274 The basic consistency rule is that you can't turn SPARK_Mode back
6275 ``On``, once you have explicitly (with a pragma) turned if
6276 ``Off``. So the following rules apply:
6278 If a subprogram spec has SPARK_Mode ``Off``, then the body must
6279 also have SPARK_Mode ``Off``.
6281 For a package, we have four parts:
6284 the package public declarations
6286 the package private part
6288 the body of the package
6290 the elaboration code after ``begin``
6292 For a package, the rule is that if you explicitly turn SPARK_Mode
6293 ``Off`` for any part, then all the following parts must have
6294 SPARK_Mode ``Off``. Note that this may require repeating a pragma
6295 SPARK_Mode (``Off``) in the body. For example, if we have a
6296 configuration pragma SPARK_Mode (``On``) that turns the mode on by
6297 default everywhere, and one particular package spec has pragma
6298 SPARK_Mode (``Off``), then that pragma will need to be repeated in
6301 Pragma Static_Elaboration_Desired
6302 =================================
6309 pragma Static_Elaboration_Desired;
6312 This pragma is used to indicate that the compiler should attempt to initialize
6313 statically the objects declared in the library unit to which the pragma applies,
6314 when these objects are initialized (explicitly or implicitly) by an aggregate.
6315 In the absence of this pragma, aggregates in object declarations are expanded
6316 into assignments and loops, even when the aggregate components are static
6317 constants. When the aggregate is present the compiler builds a static expression
6318 that requires no run-time code, so that the initialized object can be placed in
6319 read-only data space. If the components are not static, or the aggregate has
6320 more that 100 components, the compiler emits a warning that the pragma cannot
6321 be obeyed. (See also the restriction No_Implicit_Loops, which supports static
6322 construction of larger aggregates with static components that include an others
6325 Pragma Stream_Convert
6326 =====================
6333 pragma Stream_Convert (
6334 [Entity =>] type_LOCAL_NAME,
6335 [Read =>] function_NAME,
6336 [Write =>] function_NAME);
6339 This pragma provides an efficient way of providing user-defined stream
6340 attributes. Not only is it simpler to use than specifying the attributes
6341 directly, but more importantly, it allows the specification to be made in such
6342 a way that the predefined unit Ada.Streams is not loaded unless it is actually
6343 needed (i.e. unless the stream attributes are actually used); the use of
6344 the Stream_Convert pragma adds no overhead at all, unless the stream
6345 attributes are actually used on the designated type.
6347 The first argument specifies the type for which stream functions are
6348 provided. The second parameter provides a function used to read values
6349 of this type. It must name a function whose argument type may be any
6350 subtype, and whose returned type must be the type given as the first
6351 argument to the pragma.
6353 The meaning of the ``Read`` parameter is that if a stream attribute directly
6354 or indirectly specifies reading of the type given as the first parameter,
6355 then a value of the type given as the argument to the Read function is
6356 read from the stream, and then the Read function is used to convert this
6357 to the required target type.
6359 Similarly the ``Write`` parameter specifies how to treat write attributes
6360 that directly or indirectly apply to the type given as the first parameter.
6361 It must have an input parameter of the type specified by the first parameter,
6362 and the return type must be the same as the input type of the Read function.
6363 The effect is to first call the Write function to convert to the given stream
6364 type, and then write the result type to the stream.
6366 The Read and Write functions must not be overloaded subprograms. If necessary
6367 renamings can be supplied to meet this requirement.
6368 The usage of this attribute is best illustrated by a simple example, taken
6369 from the GNAT implementation of package Ada.Strings.Unbounded:
6374 function To_Unbounded (S : String) return Unbounded_String
6375 renames To_Unbounded_String;
6377 pragma Stream_Convert
6378 (Unbounded_String, To_Unbounded, To_String);
6381 The specifications of the referenced functions, as given in the Ada
6382 Reference Manual are:
6387 function To_Unbounded_String (Source : String)
6388 return Unbounded_String;
6390 function To_String (Source : Unbounded_String)
6394 The effect is that if the value of an unbounded string is written to a stream,
6395 then the representation of the item in the stream is in the same format that
6396 would be used for ``Standard.String'Output``, and this same representation
6397 is expected when a value of this type is read from the stream. Note that the
6398 value written always includes the bounds, even for Unbounded_String'Write,
6399 since Unbounded_String is not an array type.
6401 Note that the ``Stream_Convert`` pragma is not effective in the case of
6402 a derived type of a non-limited tagged type. If such a type is specified then
6403 the pragma is silently ignored, and the default implementation of the stream
6404 attributes is used instead.
6414 pragma Style_Checks (string_LITERAL | ALL_CHECKS |
6415 On | Off [, LOCAL_NAME]);
6418 This pragma is used in conjunction with compiler switches to control the
6419 built in style checking provided by GNAT. The compiler switches, if set,
6420 provide an initial setting for the switches, and this pragma may be used
6421 to modify these settings, or the settings may be provided entirely by
6422 the use of the pragma. This pragma can be used anywhere that a pragma
6423 is legal, including use as a configuration pragma (including use in
6424 the :file:`gnat.adc` file).
6426 The form with a string literal specifies which style options are to be
6427 activated. These are additive, so they apply in addition to any previously
6428 set style check options. The codes for the options are the same as those
6429 used in the *-gnaty* switch to *gcc* or *gnatmake*.
6430 For example the following two methods can be used to enable
6437 pragma Style_Checks ("l");
6447 The form ``ALL_CHECKS`` activates all standard checks (its use is equivalent
6448 to the use of the :switch:`gnaty` switch with no options.
6449 See the :title:`GNAT User's Guide` for details.)
6451 Note: the behavior is slightly different in GNAT mode (:switch:`-gnatg` used).
6452 In this case, ``ALL_CHECKS`` implies the standard set of GNAT mode style check
6453 options (i.e. equivalent to :switch:`-gnatyg`).
6455 The forms with ``Off`` and ``On``
6456 can be used to temporarily disable style checks
6457 as shown in the following example:
6462 pragma Style_Checks ("k"); -- requires keywords in lower case
6463 pragma Style_Checks (Off); -- turn off style checks
6464 NULL; -- this will not generate an error message
6465 pragma Style_Checks (On); -- turn style checks back on
6466 NULL; -- this will generate an error message
6469 Finally the two argument form is allowed only if the first argument is
6470 ``On`` or ``Off``. The effect is to turn of semantic style checks
6471 for the specified entity, as shown in the following example:
6476 pragma Style_Checks ("r"); -- require consistency of identifier casing
6478 Rf1 : Integer := ARG; -- incorrect, wrong case
6479 pragma Style_Checks (Off, Arg);
6480 Rf2 : Integer := ARG; -- OK, no error
6491 pragma Subtitle ([Subtitle =>] STRING_LITERAL);
6494 This pragma is recognized for compatibility with other Ada compilers
6495 but is ignored by GNAT.
6505 pragma Suppress (Identifier [, [On =>] Name]);
6508 This is a standard pragma, and supports all the check names required in
6509 the RM. It is included here because GNAT recognizes some additional check
6510 names that are implementation defined (as permitted by the RM):
6514 ``Alignment_Check`` can be used to suppress alignment checks
6515 on addresses used in address clauses. Such checks can also be suppressed
6516 by suppressing range checks, but the specific use of ``Alignment_Check``
6517 allows suppression of alignment checks without suppressing other range checks.
6518 Note that ``Alignment_Check`` is suppressed by default on machines (such as
6519 the x86) with non-strict alignment.
6522 ``Atomic_Synchronization`` can be used to suppress the special memory
6523 synchronization instructions that are normally generated for access to
6524 ``Atomic`` variables to ensure correct synchronization between tasks
6525 that use such variables for synchronization purposes.
6528 ``Duplicated_Tag_Check`` Can be used to suppress the check that is generated
6529 for a duplicated tag value when a tagged type is declared.
6532 ``Container_Checks`` Can be used to suppress all checks within Ada.Containers
6533 and instances of its children, including Tampering_Check.
6536 ``Tampering_Check`` Can be used to suppress tampering check in the containers.
6539 ``Predicate_Check`` can be used to control whether predicate checks are
6540 active. It is applicable only to predicates for which the policy is
6541 ``Check``. Unlike ``Assertion_Policy``, which determines if a given
6542 predicate is ignored or checked for the whole program, the use of
6543 ``Suppress`` and ``Unsuppress`` with this check name allows a given
6544 predicate to be turned on and off at specific points in the program.
6547 ``Validity_Check`` can be used specifically to control validity checks.
6548 If ``Suppress`` is used to suppress validity checks, then no validity
6549 checks are performed, including those specified by the appropriate compiler
6550 switch or the ``Validity_Checks`` pragma.
6553 Additional check names previously introduced by use of the ``Check_Name``
6554 pragma are also allowed.
6557 Note that pragma Suppress gives the compiler permission to omit
6558 checks, but does not require the compiler to omit checks. The compiler
6559 will generate checks if they are essentially free, even when they are
6560 suppressed. In particular, if the compiler can prove that a certain
6561 check will necessarily fail, it will generate code to do an
6562 unconditional 'raise', even if checks are suppressed. The compiler
6565 Of course, run-time checks are omitted whenever the compiler can prove
6566 that they will not fail, whether or not checks are suppressed.
6576 pragma Suppress_All;
6579 This pragma can appear anywhere within a unit.
6580 The effect is to apply ``Suppress (All_Checks)`` to the unit
6581 in which it appears. This pragma is implemented for compatibility with DEC
6582 Ada 83 usage where it appears at the end of a unit, and for compatibility
6583 with Rational Ada, where it appears as a program unit pragma.
6584 The use of the standard Ada pragma ``Suppress (All_Checks)``
6585 as a normal configuration pragma is the preferred usage in GNAT.
6587 .. _Pragma-Suppress_Debug_Info:
6589 Pragma Suppress_Debug_Info
6590 ==========================
6597 pragma Suppress_Debug_Info ([Entity =>] LOCAL_NAME);
6600 This pragma can be used to suppress generation of debug information
6601 for the specified entity. It is intended primarily for use in debugging
6602 the debugger, and navigating around debugger problems.
6604 Pragma Suppress_Exception_Locations
6605 ===================================
6612 pragma Suppress_Exception_Locations;
6615 In normal mode, a raise statement for an exception by default generates
6616 an exception message giving the file name and line number for the location
6617 of the raise. This is useful for debugging and logging purposes, but this
6618 entails extra space for the strings for the messages. The configuration
6619 pragma ``Suppress_Exception_Locations`` can be used to suppress the
6620 generation of these strings, with the result that space is saved, but the
6621 exception message for such raises is null. This configuration pragma may
6622 appear in a global configuration pragma file, or in a specific unit as
6623 usual. It is not required that this pragma be used consistently within
6624 a partition, so it is fine to have some units within a partition compiled
6625 with this pragma and others compiled in normal mode without it.
6627 .. _Pragma-Suppress_Initialization:
6629 Pragma Suppress_Initialization
6630 ==============================
6631 .. index:: Suppressing initialization
6633 .. index:: Initialization, suppression of
6640 pragma Suppress_Initialization ([Entity =>] variable_or_subtype_Name);
6643 Here variable_or_subtype_Name is the name introduced by a type declaration
6644 or subtype declaration or the name of a variable introduced by an
6647 In the case of a type or subtype
6648 this pragma suppresses any implicit or explicit initialization
6649 for all variables of the given type or subtype,
6650 including initialization resulting from the use of pragmas
6651 Normalize_Scalars or Initialize_Scalars.
6653 This is considered a representation item, so it cannot be given after
6654 the type is frozen. It applies to all subsequent object declarations,
6655 and also any allocator that creates objects of the type.
6657 If the pragma is given for the first subtype, then it is considered
6658 to apply to the base type and all its subtypes. If the pragma is given
6659 for other than a first subtype, then it applies only to the given subtype.
6660 The pragma may not be given after the type is frozen.
6662 Note that this includes eliminating initialization of discriminants
6663 for discriminated types, and tags for tagged types. In these cases,
6664 you will have to use some non-portable mechanism (e.g. address
6665 overlays or unchecked conversion) to achieve required initialization
6666 of these fields before accessing any object of the corresponding type.
6668 For the variable case, implicit initialization for the named variable
6669 is suppressed, just as though its subtype had been given in a pragma
6670 Suppress_Initialization, as described above.
6680 pragma Task_Name (string_EXPRESSION);
6683 This pragma appears within a task definition (like pragma
6684 ``Priority``) and applies to the task in which it appears. The
6685 argument must be of type String, and provides a name to be used for
6686 the task instance when the task is created. Note that this expression
6687 is not required to be static, and in particular, it can contain
6688 references to task discriminants. This facility can be used to
6689 provide different names for different tasks as they are created,
6690 as illustrated in the example below.
6692 The task name is recorded internally in the run-time structures
6693 and is accessible to tools like the debugger. In addition the
6694 routine ``Ada.Task_Identification.Image`` will return this
6695 string, with a unique task address appended.
6700 -- Example of the use of pragma Task_Name
6702 with Ada.Task_Identification;
6703 use Ada.Task_Identification;
6704 with Text_IO; use Text_IO;
6707 type Astring is access String;
6709 task type Task_Typ (Name : access String) is
6710 pragma Task_Name (Name.all);
6713 task body Task_Typ is
6714 Nam : constant String := Image (Current_Task);
6716 Put_Line ("-->" & Nam (1 .. 14) & "<--");
6719 type Ptr_Task is access Task_Typ;
6720 Task_Var : Ptr_Task;
6724 new Task_Typ (new String'("This is task 1"));
6726 new Task_Typ (new String'("This is task 2"));
6737 pragma Task_Storage (
6738 [Task_Type =>] LOCAL_NAME,
6739 [Top_Guard =>] static_integer_EXPRESSION);
6742 This pragma specifies the length of the guard area for tasks. The guard
6743 area is an additional storage area allocated to a task. A value of zero
6744 means that either no guard area is created or a minimal guard area is
6745 created, depending on the target. This pragma can appear anywhere a
6746 ``Storage_Size`` attribute definition clause is allowed for a task
6749 .. _Pragma-Test_Case:
6753 .. index:: Test cases
6762 [Name =>] static_string_Expression
6763 ,[Mode =>] (Nominal | Robustness)
6764 [, Requires => Boolean_Expression]
6765 [, Ensures => Boolean_Expression]);
6768 The ``Test_Case`` pragma allows defining fine-grain specifications
6769 for use by testing tools.
6770 The compiler checks the validity of the ``Test_Case`` pragma, but its
6771 presence does not lead to any modification of the code generated by the
6774 ``Test_Case`` pragmas may only appear immediately following the
6775 (separate) declaration of a subprogram in a package declaration, inside
6776 a package spec unit. Only other pragmas may intervene (that is appear
6777 between the subprogram declaration and a test case).
6779 The compiler checks that boolean expressions given in ``Requires`` and
6780 ``Ensures`` are valid, where the rules for ``Requires`` are the
6781 same as the rule for an expression in ``Precondition`` and the rules
6782 for ``Ensures`` are the same as the rule for an expression in
6783 ``Postcondition``. In particular, attributes ``'Old`` and
6784 ``'Result`` can only be used within the ``Ensures``
6785 expression. The following is an example of use within a package spec:
6790 package Math_Functions is
6792 function Sqrt (Arg : Float) return Float;
6793 pragma Test_Case (Name => "Test 1",
6795 Requires => Arg < 10000,
6796 Ensures => Sqrt'Result < 10);
6801 The meaning of a test case is that there is at least one context where
6802 ``Requires`` holds such that, if the associated subprogram is executed in
6803 that context, then ``Ensures`` holds when the subprogram returns.
6804 Mode ``Nominal`` indicates that the input context should also satisfy the
6805 precondition of the subprogram, and the output context should also satisfy its
6806 postcondition. Mode ``Robustness`` indicates that the precondition and
6807 postcondition of the subprogram should be ignored for this test case.
6809 .. _Pragma-Thread_Local_Storage:
6811 Pragma Thread_Local_Storage
6812 ===========================
6813 .. index:: Task specific storage
6815 .. index:: TLS (Thread Local Storage)
6817 .. index:: Task_Attributes
6824 pragma Thread_Local_Storage ([Entity =>] LOCAL_NAME);
6827 This pragma specifies that the specified entity, which must be
6828 a variable declared in a library-level package, is to be marked as
6829 "Thread Local Storage" (``TLS``). On systems supporting this (which
6830 include Windows, Solaris, GNU/Linux, and VxWorks 6), this causes each
6831 thread (and hence each Ada task) to see a distinct copy of the variable.
6833 The variable must not have default initialization, and if there is
6834 an explicit initialization, it must be either ``null`` for an
6835 access variable, a static expression for a scalar variable, or a fully
6836 static aggregate for a composite type, that is to say, an aggregate all
6837 of whose components are static, and which does not include packed or
6838 discriminated components.
6840 This provides a low-level mechanism similar to that provided by
6841 the ``Ada.Task_Attributes`` package, but much more efficient
6842 and is also useful in writing interface code that will interact
6843 with foreign threads.
6845 If this pragma is used on a system where ``TLS`` is not supported,
6846 then an error message will be generated and the program will be rejected.
6856 pragma Time_Slice (static_duration_EXPRESSION);
6859 For implementations of GNAT on operating systems where it is possible
6860 to supply a time slice value, this pragma may be used for this purpose.
6861 It is ignored if it is used in a system that does not allow this control,
6862 or if it appears in other than the main program unit.
6872 pragma Title (TITLING_OPTION [, TITLING OPTION]);
6875 [Title =>] STRING_LITERAL,
6876 | [Subtitle =>] STRING_LITERAL
6879 Syntax checked but otherwise ignored by GNAT. This is a listing control
6880 pragma used in DEC Ada 83 implementations to provide a title and/or
6881 subtitle for the program listing. The program listing generated by GNAT
6882 does not have titles or subtitles.
6884 Unlike other pragmas, the full flexibility of named notation is allowed
6885 for this pragma, i.e., the parameters may be given in any order if named
6886 notation is used, and named and positional notation can be mixed
6887 following the normal rules for procedure calls in Ada.
6889 Pragma Type_Invariant
6890 =====================
6897 pragma Type_Invariant
6898 ([Entity =>] type_LOCAL_NAME,
6899 [Check =>] EXPRESSION);
6902 The ``Type_Invariant`` pragma is intended to be an exact
6903 replacement for the language-defined ``Type_Invariant``
6904 aspect, and shares its restrictions and semantics. It differs
6905 from the language defined ``Invariant`` pragma in that it
6906 does not permit a string parameter, and it is
6907 controlled by the assertion identifier ``Type_Invariant``
6908 rather than ``Invariant``.
6910 .. _Pragma-Type_Invariant_Class:
6912 Pragma Type_Invariant_Class
6913 ===========================
6920 pragma Type_Invariant_Class
6921 ([Entity =>] type_LOCAL_NAME,
6922 [Check =>] EXPRESSION);
6925 The ``Type_Invariant_Class`` pragma is intended to be an exact
6926 replacement for the language-defined ``Type_Invariant'Class``
6927 aspect, and shares its restrictions and semantics.
6929 Note: This pragma is called ``Type_Invariant_Class`` rather than
6930 ``Type_Invariant'Class`` because the latter would not be strictly
6931 conforming to the allowed syntax for pragmas. The motivation
6932 for providing pragmas equivalent to the aspects is to allow a program
6933 to be written using the pragmas, and then compiled if necessary
6934 using an Ada compiler that does not recognize the pragmas or
6935 aspects, but is prepared to ignore the pragmas. The assertion
6936 policy that controls this pragma is ``Type_Invariant'Class``,
6937 not ``Type_Invariant_Class``.
6939 Pragma Unchecked_Union
6940 ======================
6941 .. index:: Unions in C
6949 pragma Unchecked_Union (first_subtype_LOCAL_NAME);
6952 This pragma is used to specify a representation of a record type that is
6953 equivalent to a C union. It was introduced as a GNAT implementation defined
6954 pragma in the GNAT Ada 95 mode. Ada 2005 includes an extended version of this
6955 pragma, making it language defined, and GNAT fully implements this extended
6956 version in all language modes (Ada 83, Ada 95, and Ada 2005). For full
6957 details, consult the Ada 2012 Reference Manual, section B.3.3.
6959 Pragma Unevaluated_Use_Of_Old
6960 =============================
6961 .. index:: Attribute Old
6963 .. index:: Attribute Loop_Entry
6965 .. index:: Unevaluated_Use_Of_Old
6973 pragma Unevaluated_Use_Of_Old (Error | Warn | Allow);
6976 This pragma controls the processing of attributes Old and Loop_Entry.
6977 If either of these attributes is used in a potentially unevaluated
6978 expression (e.g. the then or else parts of an if expression), then
6979 normally this usage is considered illegal if the prefix of the attribute
6980 is other than an entity name. The language requires this
6981 behavior for Old, and GNAT copies the same rule for Loop_Entry.
6983 The reason for this rule is that otherwise, we can have a situation
6984 where we save the Old value, and this results in an exception, even
6985 though we might not evaluate the attribute. Consider this example:
6990 package UnevalOld is
6992 procedure U (A : String; C : Boolean) -- ERROR
6993 with Post => (if C then A(1)'Old = K else True);
6997 If procedure U is called with a string with a lower bound of 2, and
6998 C false, then an exception would be raised trying to evaluate A(1)
6999 on entry even though the value would not be actually used.
7001 Although the rule guarantees against this possibility, it is sometimes
7002 too restrictive. For example if we know that the string has a lower
7003 bound of 1, then we will never raise an exception.
7004 The pragma ``Unevaluated_Use_Of_Old`` can be
7005 used to modify this behavior. If the argument is ``Error`` then an
7006 error is given (this is the default RM behavior). If the argument is
7007 ``Warn`` then the usage is allowed as legal but with a warning
7008 that an exception might be raised. If the argument is ``Allow``
7009 then the usage is allowed as legal without generating a warning.
7011 This pragma may appear as a configuration pragma, or in a declarative
7012 part or package specification. In the latter case it applies to
7013 uses up to the end of the corresponding statement sequence or
7014 sequence of package declarations.
7016 Pragma Unimplemented_Unit
7017 =========================
7024 pragma Unimplemented_Unit;
7027 If this pragma occurs in a unit that is processed by the compiler, GNAT
7028 aborts with the message :samp:`xxx not implemented`, where
7029 ``xxx`` is the name of the current compilation unit. This pragma is
7030 intended to allow the compiler to handle unimplemented library units in
7033 The abort only happens if code is being generated. Thus you can use
7034 specs of unimplemented packages in syntax or semantic checking mode.
7036 .. _Pragma-Universal_Aliasing:
7038 Pragma Universal_Aliasing
7039 =========================
7046 pragma Universal_Aliasing [([Entity =>] type_LOCAL_NAME)];
7049 ``type_LOCAL_NAME`` must refer to a type declaration in the current
7050 declarative part. The effect is to inhibit strict type-based aliasing
7051 optimization for the given type. In other words, the effect is as though
7052 access types designating this type were subject to pragma No_Strict_Aliasing.
7053 For a detailed description of the strict aliasing optimization, and the
7054 situations in which it must be suppressed, see the section on
7055 ``Optimization and Strict Aliasing`` in the :title:`GNAT User's Guide`.
7057 .. _Pragma-Universal_Data:
7059 Pragma Universal_Data
7060 =====================
7067 pragma Universal_Data [(library_unit_Name)];
7070 This pragma is supported only for the AAMP target and is ignored for
7071 other targets. The pragma specifies that all library-level objects
7072 (Counter 0 data) associated with the library unit are to be accessed
7073 and updated using universal addressing (24-bit addresses for AAMP5)
7074 rather than the default of 16-bit Data Environment (DENV) addressing.
7075 Use of this pragma will generally result in less efficient code for
7076 references to global data associated with the library unit, but
7077 allows such data to be located anywhere in memory. This pragma is
7078 a library unit pragma, but can also be used as a configuration pragma
7079 (including use in the :file:`gnat.adc` file). The functionality
7080 of this pragma is also available by applying the -univ switch on the
7081 compilations of units where universal addressing of the data is desired.
7083 .. _Pragma-Unmodified:
7087 .. index:: Warnings, unmodified
7094 pragma Unmodified (LOCAL_NAME {, LOCAL_NAME});
7097 This pragma signals that the assignable entities (variables,
7098 ``out`` parameters, ``in out`` parameters) whose names are listed are
7099 deliberately not assigned in the current source unit. This
7100 suppresses warnings about the
7101 entities being referenced but not assigned, and in addition a warning will be
7102 generated if one of these entities is in fact assigned in the
7103 same unit as the pragma (or in the corresponding body, or one
7106 This is particularly useful for clearly signaling that a particular
7107 parameter is not modified, even though the spec suggests that it might
7110 For the variable case, warnings are never given for unreferenced variables
7111 whose name contains one of the substrings
7112 ``DISCARD, DUMMY, IGNORE, JUNK, UNUSED`` in any casing. Such names
7113 are typically to be used in cases where such warnings are expected.
7114 Thus it is never necessary to use ``pragma Unmodified`` for such
7115 variables, though it is harmless to do so.
7117 .. _Pragma-Unreferenced:
7121 .. index:: Warnings, unreferenced
7128 pragma Unreferenced (LOCAL_NAME {, LOCAL_NAME});
7129 pragma Unreferenced (library_unit_NAME {, library_unit_NAME});
7132 This pragma signals that the entities whose names are listed are
7133 deliberately not referenced in the current source unit after the
7134 occurrence of the pragma. This
7135 suppresses warnings about the
7136 entities being unreferenced, and in addition a warning will be
7137 generated if one of these entities is in fact subsequently referenced in the
7138 same unit as the pragma (or in the corresponding body, or one
7141 This is particularly useful for clearly signaling that a particular
7142 parameter is not referenced in some particular subprogram implementation
7143 and that this is deliberate. It can also be useful in the case of
7144 objects declared only for their initialization or finalization side
7147 If ``LOCAL_NAME`` identifies more than one matching homonym in the
7148 current scope, then the entity most recently declared is the one to which
7149 the pragma applies. Note that in the case of accept formals, the pragma
7150 Unreferenced may appear immediately after the keyword ``do`` which
7151 allows the indication of whether or not accept formals are referenced
7152 or not to be given individually for each accept statement.
7154 The left hand side of an assignment does not count as a reference for the
7155 purpose of this pragma. Thus it is fine to assign to an entity for which
7156 pragma Unreferenced is given.
7158 Note that if a warning is desired for all calls to a given subprogram,
7159 regardless of whether they occur in the same unit as the subprogram
7160 declaration, then this pragma should not be used (calls from another
7161 unit would not be flagged); pragma Obsolescent can be used instead
7162 for this purpose, see :ref:`Pragma_Obsolescent`.
7164 The second form of pragma ``Unreferenced`` is used within a context
7165 clause. In this case the arguments must be unit names of units previously
7166 mentioned in ``with`` clauses (similar to the usage of pragma
7167 ``Elaborate_All``. The effect is to suppress warnings about unreferenced
7168 units and unreferenced entities within these units.
7170 For the variable case, warnings are never given for unreferenced variables
7171 whose name contains one of the substrings
7172 ``DISCARD, DUMMY, IGNORE, JUNK, UNUSED`` in any casing. Such names
7173 are typically to be used in cases where such warnings are expected.
7174 Thus it is never necessary to use ``pragma Unreferenced`` for such
7175 variables, though it is harmless to do so.
7177 .. _Pragma-Unreferenced_Objects:
7179 Pragma Unreferenced_Objects
7180 ===========================
7181 .. index:: Warnings, unreferenced
7188 pragma Unreferenced_Objects (local_subtype_NAME {, local_subtype_NAME});
7191 This pragma signals that for the types or subtypes whose names are
7192 listed, objects which are declared with one of these types or subtypes may
7193 not be referenced, and if no references appear, no warnings are given.
7195 This is particularly useful for objects which are declared solely for their
7196 initialization and finalization effect. Such variables are sometimes referred
7197 to as RAII variables (Resource Acquisition Is Initialization). Using this
7198 pragma on the relevant type (most typically a limited controlled type), the
7199 compiler will automatically suppress unwanted warnings about these variables
7200 not being referenced.
7202 Pragma Unreserve_All_Interrupts
7203 ===============================
7210 pragma Unreserve_All_Interrupts;
7213 Normally certain interrupts are reserved to the implementation. Any attempt
7214 to attach an interrupt causes Program_Error to be raised, as described in
7215 RM C.3.2(22). A typical example is the ``SIGINT`` interrupt used in
7216 many systems for a :kbd:`Ctrl-C` interrupt. Normally this interrupt is
7217 reserved to the implementation, so that :kbd:`Ctrl-C` can be used to
7218 interrupt execution.
7220 If the pragma ``Unreserve_All_Interrupts`` appears anywhere in any unit in
7221 a program, then all such interrupts are unreserved. This allows the
7222 program to handle these interrupts, but disables their standard
7223 functions. For example, if this pragma is used, then pressing
7224 :kbd:`Ctrl-C` will not automatically interrupt execution. However,
7225 a program can then handle the ``SIGINT`` interrupt as it chooses.
7227 For a full list of the interrupts handled in a specific implementation,
7228 see the source code for the spec of ``Ada.Interrupts.Names`` in
7229 file :file:`a-intnam.ads`. This is a target dependent file that contains the
7230 list of interrupts recognized for a given target. The documentation in
7231 this file also specifies what interrupts are affected by the use of
7232 the ``Unreserve_All_Interrupts`` pragma.
7234 For a more general facility for controlling what interrupts can be
7235 handled, see pragma ``Interrupt_State``, which subsumes the functionality
7236 of the ``Unreserve_All_Interrupts`` pragma.
7246 pragma Unsuppress (IDENTIFIER [, [On =>] NAME]);
7249 This pragma undoes the effect of a previous pragma ``Suppress``. If
7250 there is no corresponding pragma ``Suppress`` in effect, it has no
7251 effect. The range of the effect is the same as for pragma
7252 ``Suppress``. The meaning of the arguments is identical to that used
7253 in pragma ``Suppress``.
7255 One important application is to ensure that checks are on in cases where
7256 code depends on the checks for its correct functioning, so that the code
7257 will compile correctly even if the compiler switches are set to suppress
7258 checks. For example, in a program that depends on external names of tagged
7259 types and wants to ensure that the duplicated tag check occurs even if all
7260 run-time checks are suppressed by a compiler switch, the following
7261 configuration pragma will ensure this test is not suppressed:
7266 pragma Unsuppress (Duplicated_Tag_Check);
7269 This pragma is standard in Ada 2005. It is available in all earlier versions
7270 of Ada as an implementation-defined pragma.
7272 Note that in addition to the checks defined in the Ada RM, GNAT recogizes a
7273 number of implementation-defined check names. See the description of pragma
7274 ``Suppress`` for full details.
7276 Pragma Use_VADS_Size
7277 ====================
7278 .. index:: Size, VADS compatibility
7280 .. index:: Rational profile
7288 pragma Use_VADS_Size;
7291 This is a configuration pragma. In a unit to which it applies, any use
7292 of the 'Size attribute is automatically interpreted as a use of the
7293 'VADS_Size attribute. Note that this may result in incorrect semantic
7294 processing of valid Ada 95 or Ada 2005 programs. This is intended to aid in
7295 the handling of existing code which depends on the interpretation of Size
7296 as implemented in the VADS compiler. See description of the VADS_Size
7297 attribute for further details.
7303 .. index:: Warnings, unused
7310 pragma Unused (LOCAL_NAME {, LOCAL_NAME});
7313 This pragma signals that the assignable entities (variables,
7314 ``out`` parameters, and ``in out`` parameters) whose names are listed
7315 deliberately do not get assigned or referenced in the current source unit
7316 after the occurrence of the pragma in the current source unit. This
7317 suppresses warnings about the entities that are unreferenced and/or not
7318 assigned, and, in addition, a warning will be generated if one of these
7319 entities gets assigned or subsequently referenced in the same unit as the
7320 pragma (in the corresponding body or one of its subunits).
7322 This is particularly useful for clearly signaling that a particular
7323 parameter is not modified or referenced, even though the spec suggests
7326 For the variable case, warnings are never given for unreferenced
7327 variables whose name contains one of the substrings
7328 ``DISCARD, DUMMY, IGNORE, JUNK, UNUSED`` in any casing. Such names
7329 are typically to be used in cases where such warnings are expected.
7330 Thus it is never necessary to use ``pragma Unmodified`` for such
7331 variables, though it is harmless to do so.
7333 Pragma Validity_Checks
7334 ======================
7341 pragma Validity_Checks (string_LITERAL | ALL_CHECKS | On | Off);
7344 This pragma is used in conjunction with compiler switches to control the
7345 built-in validity checking provided by GNAT. The compiler switches, if set
7346 provide an initial setting for the switches, and this pragma may be used
7347 to modify these settings, or the settings may be provided entirely by
7348 the use of the pragma. This pragma can be used anywhere that a pragma
7349 is legal, including use as a configuration pragma (including use in
7350 the :file:`gnat.adc` file).
7352 The form with a string literal specifies which validity options are to be
7353 activated. The validity checks are first set to include only the default
7354 reference manual settings, and then a string of letters in the string
7355 specifies the exact set of options required. The form of this string
7356 is exactly as described for the *-gnatVx* compiler switch (see the
7357 GNAT User's Guide for details). For example the following two
7358 methods can be used to enable validity checking for mode ``in`` and
7359 ``in out`` subprogram parameters:
7365 pragma Validity_Checks ("im");
7372 $ gcc -c -gnatVim ...
7375 The form ALL_CHECKS activates all standard checks (its use is equivalent
7376 to the use of the :switch:`gnatVa` switch).
7378 The forms with ``Off`` and ``On`` can be used to temporarily disable
7379 validity checks as shown in the following example:
7384 pragma Validity_Checks ("c"); -- validity checks for copies
7385 pragma Validity_Checks (Off); -- turn off validity checks
7386 A := B; -- B will not be validity checked
7387 pragma Validity_Checks (On); -- turn validity checks back on
7388 A := C; -- C will be validity checked
7390 .. _Pragma-Volatile:
7400 pragma Volatile (LOCAL_NAME);
7403 This pragma is defined by the Ada Reference Manual, and the GNAT
7404 implementation is fully conformant with this definition. The reason it
7405 is mentioned in this section is that a pragma of the same name was supplied
7406 in some Ada 83 compilers, including DEC Ada 83. The Ada 95 / Ada 2005
7407 implementation of pragma Volatile is upwards compatible with the
7408 implementation in DEC Ada 83.
7410 .. _Pragma-Volatile_Full_Access:
7412 Pragma Volatile_Full_Access
7413 ===========================
7420 pragma Volatile_Full_Access (LOCAL_NAME);
7423 This is similar in effect to pragma Volatile, except that any reference to the
7424 object is guaranteed to be done only with instructions that read or write all
7425 the bits of the object. Furthermore, if the object is of a composite type,
7426 then any reference to a component of the object is guaranteed to read and/or
7427 write all the bits of the object.
7429 The intention is that this be suitable for use with memory-mapped I/O devices
7430 on some machines. Note that there are two important respects in which this is
7431 different from ``pragma Atomic``. First a reference to a ``Volatile_Full_Access``
7432 object is not a sequential action in the RM 9.10 sense and, therefore, does
7433 not create a synchronization point. Second, in the case of ``pragma Atomic``,
7434 there is no guarantee that all the bits will be accessed if the reference
7435 is not to the whole object; the compiler is allowed (and generally will)
7436 access only part of the object in this case.
7438 It is not permissible to specify ``Atomic`` and ``Volatile_Full_Access`` for
7441 It is not permissible to specify ``Volatile_Full_Access`` for a composite
7442 (record or array) type or object that has at least one ``Aliased`` component.
7444 .. _Pragma-Volatile_Function:
7446 Pragma Volatile_Function
7447 ========================
7453 pragma Volatile_Function [ (boolean_EXPRESSION) ];
7455 For the semantics of this pragma, see the entry for aspect ``Volatile_Function``
7456 in the SPARK 2014 Reference Manual, section 7.1.2.
7458 Pragma Warning_As_Error
7459 =======================
7466 pragma Warning_As_Error (static_string_EXPRESSION);
7469 This configuration pragma allows the programmer to specify a set
7470 of warnings that will be treated as errors. Any warning that
7471 matches the pattern given by the pragma argument will be treated
7472 as an error. This gives more precise control than -gnatwe,
7473 which treats warnings as errors.
7475 This pragma can apply to regular warnings (messages enabled by -gnatw)
7476 and to style warnings (messages that start with "(style)",
7479 The pattern may contain asterisks, which match zero or more characters
7480 in the message. For example, you can use ``pragma Warning_As_Error
7481 ("bits of*unused")`` to treat the warning message ``warning: 960 bits of
7482 "a" unused`` as an error. All characters other than asterisk are treated
7483 as literal characters in the match. The match is case insensitive; for
7484 example XYZ matches xyz.
7486 Note that the pattern matches if it occurs anywhere within the warning
7487 message string (it is not necessary to put an asterisk at the start and
7488 the end of the message, since this is implied).
7490 Another possibility for the static_string_EXPRESSION which works whether
7491 or not error tags are enabled (*-gnatw.d*) is to use the
7492 *-gnatw* tag string, enclosed in brackets,
7493 as shown in the example below, to treat a class of warnings as errors.
7495 The above use of patterns to match the message applies only to warning
7496 messages generated by the front end. This pragma can also be applied to
7497 warnings provided by the back end and mentioned in :ref:`Pragma_Warnings`.
7498 By using a single full *-Wxxx* switch in the pragma, such warnings
7499 can also be treated as errors.
7501 The pragma can appear either in a global configuration pragma file
7502 (e.g. :file:`gnat.adc`), or at the start of a file. Given a global
7503 configuration pragma file containing:
7508 pragma Warning_As_Error ("[-gnatwj]");
7511 which will treat all obsolescent feature warnings as errors, the
7512 following program compiles as shown (compile options here are
7513 *-gnatwa.d -gnatl -gnatj55*).
7518 1. pragma Warning_As_Error ("*never assigned*");
7519 2. function Warnerr return String is
7522 >>> error: variable "X" is never read and
7523 never assigned [-gnatwv] [warning-as-error]
7527 >>> warning: variable "Y" is assigned but
7528 never read [-gnatwu]
7534 >>> error: use of "%" is an obsolescent
7535 feature (RM J.2(4)), use """ instead
7536 [-gnatwj] [warning-as-error]
7540 8 lines: No errors, 3 warnings (2 treated as errors)
7543 Note that this pragma does not affect the set of warnings issued in
7544 any way, it merely changes the effect of a matching warning if one
7545 is produced as a result of other warnings options. As shown in this
7546 example, if the pragma results in a warning being treated as an error,
7547 the tag is changed from "warning:" to "error:" and the string
7548 "[warning-as-error]" is appended to the end of the message.
7550 .. _Pragma_Warnings:
7560 pragma Warnings ([TOOL_NAME,] DETAILS [, REASON]);
7562 DETAILS ::= On | Off
7563 DETAILS ::= On | Off, local_NAME
7564 DETAILS ::= static_string_EXPRESSION
7565 DETAILS ::= On | Off, static_string_EXPRESSION
7567 TOOL_NAME ::= GNAT | GNATProve
7569 REASON ::= Reason => STRING_LITERAL {& STRING_LITERAL}
7571 Note: in Ada 83 mode, a string literal may be used in place of a static string
7572 expression (which does not exist in Ada 83).
7574 Note if the second argument of ``DETAILS`` is a ``local_NAME`` then the
7575 second form is always understood. If the intention is to use
7576 the fourth form, then you can write ``NAME & ""`` to force the
7577 intepretation as a *static_string_EXPRESSION*.
7579 Note: if the first argument is a valid ``TOOL_NAME``, it will be interpreted
7580 that way. The use of the ``TOOL_NAME`` argument is relevant only to users
7581 of SPARK and GNATprove, see last part of this section for details.
7583 Normally warnings are enabled, with the output being controlled by
7584 the command line switch. Warnings (``Off``) turns off generation of
7585 warnings until a Warnings (``On``) is encountered or the end of the
7586 current unit. If generation of warnings is turned off using this
7587 pragma, then some or all of the warning messages are suppressed,
7588 regardless of the setting of the command line switches.
7590 The ``Reason`` parameter may optionally appear as the last argument
7591 in any of the forms of this pragma. It is intended purely for the
7592 purposes of documenting the reason for the ``Warnings`` pragma.
7593 The compiler will check that the argument is a static string but
7594 otherwise ignore this argument. Other tools may provide specialized
7595 processing for this string.
7597 The form with a single argument (or two arguments if Reason present),
7598 where the first argument is ``ON`` or ``OFF``
7599 may be used as a configuration pragma.
7601 If the ``LOCAL_NAME`` parameter is present, warnings are suppressed for
7602 the specified entity. This suppression is effective from the point where
7603 it occurs till the end of the extended scope of the variable (similar to
7604 the scope of ``Suppress``). This form cannot be used as a configuration
7607 In the case where the first argument is other than ``ON`` or
7609 the third form with a single static_string_EXPRESSION argument (and possible
7610 reason) provides more precise
7611 control over which warnings are active. The string is a list of letters
7612 specifying which warnings are to be activated and which deactivated. The
7613 code for these letters is the same as the string used in the command
7614 line switch controlling warnings. For a brief summary, use the gnatmake
7615 command with no arguments, which will generate usage information containing
7616 the list of warnings switches supported. For
7617 full details see the section on ``Warning Message Control`` in the
7618 :title:`GNAT User's Guide`.
7619 This form can also be used as a configuration pragma.
7621 The warnings controlled by the :switch:`-gnatw` switch are generated by the
7622 front end of the compiler. The GCC back end can provide additional warnings
7623 and they are controlled by the :switch:`-W` switch. Such warnings can be
7624 identified by the appearance of a string of the form ``[-W{xxx}]`` in the
7625 message which designates the :switch:`-W{xxx}` switch that controls the message.
7626 The form with a single *static_string_EXPRESSION* argument also works for these
7627 warnings, but the string must be a single full :switch:`-W{xxx}` switch in this
7628 case. The above reference lists a few examples of these additional warnings.
7630 The specified warnings will be in effect until the end of the program
7631 or another pragma ``Warnings`` is encountered. The effect of the pragma is
7632 cumulative. Initially the set of warnings is the standard default set
7633 as possibly modified by compiler switches. Then each pragma Warning
7634 modifies this set of warnings as specified. This form of the pragma may
7635 also be used as a configuration pragma.
7637 The fourth form, with an ``On|Off`` parameter and a string, is used to
7638 control individual messages, based on their text. The string argument
7639 is a pattern that is used to match against the text of individual
7640 warning messages (not including the initial "warning: " tag).
7642 The pattern may contain asterisks, which match zero or more characters in
7643 the message. For example, you can use
7644 ``pragma Warnings (Off, "bits of*unused")`` to suppress the warning
7645 message ``warning: 960 bits of "a" unused``. No other regular
7646 expression notations are permitted. All characters other than asterisk in
7647 these three specific cases are treated as literal characters in the match.
7648 The match is case insensitive, for example XYZ matches xyz.
7650 Note that the pattern matches if it occurs anywhere within the warning
7651 message string (it is not necessary to put an asterisk at the start and
7652 the end of the message, since this is implied).
7654 The above use of patterns to match the message applies only to warning
7655 messages generated by the front end. This form of the pragma with a string
7656 argument can also be used to control warnings provided by the back end and
7657 mentioned above. By using a single full :switch:`-W{xxx}` switch in the pragma,
7658 such warnings can be turned on and off.
7660 There are two ways to use the pragma in this form. The OFF form can be used
7661 as a configuration pragma. The effect is to suppress all warnings (if any)
7662 that match the pattern string throughout the compilation (or match the
7663 -W switch in the back end case).
7665 The second usage is to suppress a warning locally, and in this case, two
7666 pragmas must appear in sequence:
7671 pragma Warnings (Off, Pattern);
7672 ... code where given warning is to be suppressed
7673 pragma Warnings (On, Pattern);
7676 In this usage, the pattern string must match in the Off and On
7677 pragmas, and (if *-gnatw.w* is given) at least one matching
7678 warning must be suppressed.
7680 Note: if the ON form is not found, then the effect of the OFF form extends
7681 until the end of the file (pragma Warnings is purely textual, so its effect
7682 does not stop at the end of the enclosing scope).
7684 Note: to write a string that will match any warning, use the string
7685 ``"***"``. It will not work to use a single asterisk or two
7686 asterisks since this looks like an operator name. This form with three
7687 asterisks is similar in effect to specifying ``pragma Warnings (Off)`` except (if :switch:`-gnatw.w` is given) that a matching
7688 ``pragma Warnings (On, "***")`` will be required. This can be
7689 helpful in avoiding forgetting to turn warnings back on.
7691 Note: the debug flag :switch:`-gnatd.i` (``/NOWARNINGS_PRAGMAS`` in VMS) can be
7692 used to cause the compiler to entirely ignore all WARNINGS pragmas. This can
7693 be useful in checking whether obsolete pragmas in existing programs are hiding
7696 Note: pragma Warnings does not affect the processing of style messages. See
7697 separate entry for pragma Style_Checks for control of style messages.
7699 Users of the formal verification tool GNATprove for the SPARK subset of Ada may
7700 use the version of the pragma with a ``TOOL_NAME`` parameter.
7702 If present, ``TOOL_NAME`` is the name of a tool, currently either ``GNAT`` for the
7703 compiler or ``GNATprove`` for the formal verification tool. A given tool only
7704 takes into account pragma Warnings that do not specify a tool name, or that
7705 specify the matching tool name. This makes it possible to disable warnings
7706 selectively for each tool, and as a consequence to detect useless pragma
7707 Warnings with switch :switch:`-gnatw.w`.
7709 Pragma Weak_External
7710 ====================
7717 pragma Weak_External ([Entity =>] LOCAL_NAME);
7720 ``LOCAL_NAME`` must refer to an object that is declared at the library
7721 level. This pragma specifies that the given entity should be marked as a
7722 weak symbol for the linker. It is equivalent to ``__attribute__((weak))``
7723 in GNU C and causes ``LOCAL_NAME`` to be emitted as a weak symbol instead
7724 of a regular symbol, that is to say a symbol that does not have to be
7725 resolved by the linker if used in conjunction with a pragma Import.
7727 When a weak symbol is not resolved by the linker, its address is set to
7728 zero. This is useful in writing interfaces to external modules that may
7729 or may not be linked in the final executable, for example depending on
7730 configuration settings.
7732 If a program references at run time an entity to which this pragma has been
7733 applied, and the corresponding symbol was not resolved at link time, then
7734 the execution of the program is erroneous. It is not erroneous to take the
7735 Address of such an entity, for example to guard potential references,
7736 as shown in the example below.
7738 Some file formats do not support weak symbols so not all target machines
7739 support this pragma.
7744 -- Example of the use of pragma Weak_External
7746 package External_Module is
7748 pragma Import (C, key);
7749 pragma Weak_External (key);
7750 function Present return boolean;
7751 end External_Module;
7753 with System; use System;
7754 package body External_Module is
7755 function Present return boolean is
7757 return key'Address /= System.Null_Address;
7759 end External_Module;
7762 Pragma Wide_Character_Encoding
7763 ==============================
7770 pragma Wide_Character_Encoding (IDENTIFIER | CHARACTER_LITERAL);
7773 This pragma specifies the wide character encoding to be used in program
7774 source text appearing subsequently. It is a configuration pragma, but may
7775 also be used at any point that a pragma is allowed, and it is permissible
7776 to have more than one such pragma in a file, allowing multiple encodings
7777 to appear within the same file.
7779 However, note that the pragma cannot immediately precede the relevant
7780 wide character, because then the previous encoding will still be in
7781 effect, causing "illegal character" errors.
7783 The argument can be an identifier or a character literal. In the identifier
7784 case, it is one of ``HEX``, ``UPPER``, ``SHIFT_JIS``,
7785 ``EUC``, ``UTF8``, or ``BRACKETS``. In the character literal
7786 case it is correspondingly one of the characters :kbd:`h`, :kbd:`u`,
7787 :kbd:`s`, :kbd:`e`, :kbd:`8`, or :kbd:`b`.
7789 Note that when the pragma is used within a file, it affects only the
7790 encoding within that file, and does not affect withed units, specs,