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.
102 A configuration pragma that establishes Ada 83 mode for the unit to
103 which it applies, regardless of the mode set by the command line
104 switches. In Ada 83 mode, GNAT attempts to be as compatible with
105 the syntax and semantics of Ada 83, as defined in the original Ada
106 83 Reference Manual as possible. In particular, the keywords added by Ada 95
107 and Ada 2005 are not recognized, optional package bodies are allowed,
108 and generics may name types with unknown discriminants without using
109 the ``(<>)`` notation. In addition, some but not all of the additional
110 restrictions of Ada 83 are enforced.
112 Ada 83 mode is intended for two purposes. Firstly, it allows existing
113 Ada 83 code to be compiled and adapted to GNAT with less effort.
114 Secondly, it aids in keeping code backwards compatible with Ada 83.
115 However, there is no guarantee that code that is processed correctly
116 by GNAT in Ada 83 mode will in fact compile and execute with an Ada
117 83 compiler, since GNAT does not enforce all the additional checks
130 A configuration pragma that establishes Ada 95 mode for the unit to which
131 it applies, regardless of the mode set by the command line switches.
132 This mode is set automatically for the ``Ada`` and ``System``
133 packages and their children, so you need not specify it in these
134 contexts. This pragma is useful when writing a reusable component that
135 itself uses Ada 95 features, but which is intended to be usable from
136 either Ada 83 or Ada 95 programs.
146 pragma Ada_05 (local_NAME);
149 A configuration pragma that establishes Ada 2005 mode for the unit to which
150 it applies, regardless of the mode set by the command line switches.
151 This pragma is useful when writing a reusable component that
152 itself uses Ada 2005 features, but which is intended to be usable from
153 either Ada 83 or Ada 95 programs.
155 The one argument form (which is not a configuration pragma)
156 is used for managing the transition from
157 Ada 95 to Ada 2005 in the run-time library. If an entity is marked
158 as Ada_2005 only, then referencing the entity in Ada_83 or Ada_95
159 mode will generate a warning. In addition, in Ada_83 or Ada_95
160 mode, a preference rule is established which does not choose
161 such an entity unless it is unambiguously specified. This avoids
162 extra subprograms marked this way from generating ambiguities in
163 otherwise legal pre-Ada_2005 programs. The one argument form is
164 intended for exclusive use in the GNAT run-time library.
176 This configuration pragma is a synonym for pragma Ada_05 and has the
177 same syntax and effect.
187 pragma Ada_12 (local_NAME);
190 A configuration pragma that establishes Ada 2012 mode for the unit to which
191 it applies, regardless of the mode set by the command line switches.
192 This mode is set automatically for the ``Ada`` and ``System``
193 packages and their children, so you need not specify it in these
194 contexts. This pragma is useful when writing a reusable component that
195 itself uses Ada 2012 features, but which is intended to be usable from
196 Ada 83, Ada 95, or Ada 2005 programs.
198 The one argument form, which is not a configuration pragma,
199 is used for managing the transition from Ada
200 2005 to Ada 2012 in the run-time library. If an entity is marked
201 as Ada_2012 only, then referencing the entity in any pre-Ada_2012
202 mode will generate a warning. In addition, in any pre-Ada_2012
203 mode, a preference rule is established which does not choose
204 such an entity unless it is unambiguously specified. This avoids
205 extra subprograms marked this way from generating ambiguities in
206 otherwise legal pre-Ada_2012 programs. The one argument form is
207 intended for exclusive use in the GNAT run-time library.
219 This configuration pragma is a synonym for pragma Ada_12 and has the
220 same syntax and effect.
222 Pragma Allow_Integer_Address
223 ============================
229 pragma Allow_Integer_Address;
232 In almost all versions of GNAT, ``System.Address`` is a private
233 type in accordance with the implementation advice in the RM. This
234 means that integer values,
235 in particular integer literals, are not allowed as address values.
236 If the configuration pragma
237 ``Allow_Integer_Address`` is given, then integer expressions may
238 be used anywhere a value of type ``System.Address`` is required.
239 The effect is to introduce an implicit unchecked conversion from the
240 integer value to type ``System.Address``. The reverse case of using
241 an address where an integer type is required is handled analogously.
242 The following example compiles without errors:
247 pragma Allow_Integer_Address;
248 with System; use System;
252 for X'Address use 16#1240#;
253 for Y use at 16#3230#;
254 m : Address := 16#4000#;
255 n : constant Address := 4000;
256 p : constant Address := Address (X + Y);
257 v : Integer := y'Address;
258 w : constant Integer := Integer (Y'Address);
259 type R is new integer;
262 for Z'Address use RR;
266 Note that pragma ``Allow_Integer_Address`` is ignored if ``System.Address``
267 is not a private type. In implementations of ``GNAT`` where
268 System.Address is a visible integer type,
269 this pragma serves no purpose but is ignored
270 rather than rejected to allow common sets of sources to be used
271 in the two situations.
280 pragma Annotate (IDENTIFIER [, IDENTIFIER {, ARG}] [, entity => local_NAME]);
282 ARG ::= NAME | EXPRESSION
285 This pragma is used to annotate programs. IDENTIFIER identifies
286 the type of annotation. GNAT verifies that it is an identifier, but does
287 not otherwise analyze it. The second optional identifier is also left
288 unanalyzed, and by convention is used to control the action of the tool to
289 which the annotation is addressed. The remaining ARG arguments
290 can be either string literals or more generally expressions.
291 String literals are assumed to be either of type
292 ``Standard.String`` or else ``Wide_String`` or ``Wide_Wide_String``
293 depending on the character literals they contain.
294 All other kinds of arguments are analyzed as expressions, and must be
295 unambiguous. The last argument if present must have the identifier
296 ``Entity`` and GNAT verifies that a local name is given.
298 The analyzed pragma is retained in the tree, but not otherwise processed
299 by any part of the GNAT compiler, except to generate corresponding note
300 lines in the generated ALI file. For the format of these note lines, see
301 the compiler source file lib-writ.ads. This pragma is intended for use by
302 external tools, including ASIS. The use of pragma Annotate does not
303 affect the compilation process in any way. This pragma may be used as
304 a configuration pragma.
313 [, string_EXPRESSION]);
316 The effect of this pragma depends on whether the corresponding command
317 line switch is set to activate assertions. The pragma expands into code
318 equivalent to the following:
322 if assertions-enabled then
323 if not boolean_EXPRESSION then
324 System.Assertions.Raise_Assert_Failure
330 The string argument, if given, is the message that will be associated
331 with the exception occurrence if the exception is raised. If no second
332 argument is given, the default message is ``file``:``nnn``,
333 where ``file`` is the name of the source file containing the assert,
334 and ``nnn`` is the line number of the assert.
336 Note that, as with the ``if`` statement to which it is equivalent, the
337 type of the expression is either ``Standard.Boolean``, or any type derived
338 from this standard type.
340 Assert checks can be either checked or ignored. By default they are ignored.
341 They will be checked if either the command line switch *-gnata* is
342 used, or if an ``Assertion_Policy`` or ``Check_Policy`` pragma is used
343 to enable ``Assert_Checks``.
345 If assertions are ignored, then there
346 is no run-time effect (and in particular, any side effects from the
347 expression will not occur at run time). (The expression is still
348 analyzed at compile time, and may cause types to be frozen if they are
349 mentioned here for the first time).
351 If assertions are checked, then the given expression is tested, and if
352 it is ``False`` then ``System.Assertions.Raise_Assert_Failure`` is called
353 which results in the raising of ``Assert_Failure`` with the given message.
355 You should generally avoid side effects in the expression arguments of
356 this pragma, because these side effects will turn on and off with the
357 setting of the assertions mode, resulting in assertions that have an
358 effect on the program. However, the expressions are analyzed for
359 semantic correctness whether or not assertions are enabled, so turning
360 assertions on and off cannot affect the legality of a program.
362 Note that the implementation defined policy ``DISABLE``, given in a
363 pragma ``Assertion_Policy``, can be used to suppress this semantic analysis.
365 Note: this is a standard language-defined pragma in versions
366 of Ada from 2005 on. In GNAT, it is implemented in all versions
367 of Ada, and the DISABLE policy is an implementation-defined
370 Pragma Assert_And_Cut
371 =====================
375 pragma Assert_And_Cut (
377 [, string_EXPRESSION]);
380 The effect of this pragma is identical to that of pragma ``Assert``,
381 except that in an ``Assertion_Policy`` pragma, the identifier
382 ``Assert_And_Cut`` is used to control whether it is ignored or checked
385 The intention is that this be used within a subprogram when the
386 given test expresion sums up all the work done so far in the
387 subprogram, so that the rest of the subprogram can be verified
388 (informally or formally) using only the entry preconditions,
389 and the expression in this pragma. This allows dividing up
390 a subprogram into sections for the purposes of testing or
391 formal verification. The pragma also serves as useful
394 Pragma Assertion_Policy
395 =======================
399 pragma Assertion_Policy (CHECK | DISABLE | IGNORE);
401 pragma Assertion_Policy (
402 ASSERTION_KIND => POLICY_IDENTIFIER
403 {, ASSERTION_KIND => POLICY_IDENTIFIER});
405 ASSERTION_KIND ::= RM_ASSERTION_KIND | ID_ASSERTION_KIND
407 RM_ASSERTION_KIND ::= Assert |
417 ID_ASSERTION_KIND ::= Assertions |
433 POLICY_IDENTIFIER ::= Check | Disable | Ignore | Suppressible
436 This is a standard Ada 2012 pragma that is available as an
437 implementation-defined pragma in earlier versions of Ada.
438 The assertion kinds ``RM_ASSERTION_KIND`` are those defined in
439 the Ada standard. The assertion kinds ``ID_ASSERTION_KIND``
440 are implementation defined additions recognized by the GNAT compiler.
442 The pragma applies in both cases to pragmas and aspects with matching
443 names, e.g. ``Pre`` applies to the Pre aspect, and ``Precondition``
444 applies to both the ``Precondition`` pragma
445 and the aspect ``Precondition``. Note that the identifiers for
446 pragmas Pre_Class and Post_Class are Pre'Class and Post'Class (not
447 Pre_Class and Post_Class), since these pragmas are intended to be
448 identical to the corresponding aspects).
450 If the policy is ``CHECK``, then assertions are enabled, i.e.
451 the corresponding pragma or aspect is activated.
452 If the policy is ``IGNORE``, then assertions are ignored, i.e.
453 the corresponding pragma or aspect is deactivated.
454 This pragma overrides the effect of the *-gnata* switch on the
456 If the policy is ``SUPPRESSIBLE``, then assertions are enabled by default,
457 however, if the *-gnatp* switch is specified all assertions are ignored.
459 The implementation defined policy ``DISABLE`` is like
460 ``IGNORE`` except that it completely disables semantic
461 checking of the corresponding pragma or aspect. This is
462 useful when the pragma or aspect argument references subprograms
463 in a with'ed package which is replaced by a dummy package
466 The implementation defined assertion kind ``Assertions`` applies to all
467 assertion kinds. The form with no assertion kind given implies this
468 choice, so it applies to all assertion kinds (RM defined, and
469 implementation defined).
471 The implementation defined assertion kind ``Statement_Assertions``
472 applies to ``Assert``, ``Assert_And_Cut``,
473 ``Assume``, ``Loop_Invariant``, and ``Loop_Variant``.
484 [, string_EXPRESSION]);
487 The effect of this pragma is identical to that of pragma ``Assert``,
488 except that in an ``Assertion_Policy`` pragma, the identifier
489 ``Assume`` is used to control whether it is ignored or checked
492 The intention is that this be used for assumptions about the
493 external environment. So you cannot expect to verify formally
494 or informally that the condition is met, this must be
495 established by examining things outside the program itself.
496 For example, we may have code that depends on the size of
497 ``Long_Long_Integer`` being at least 64. So we could write:
501 pragma Assume (Long_Long_Integer'Size >= 64);
504 This assumption cannot be proved from the program itself,
505 but it acts as a useful run-time check that the assumption
506 is met, and documents the need to ensure that it is met by
507 reference to information outside the program.
509 Pragma Assume_No_Invalid_Values
510 ===============================
511 .. index:: Invalid representations
513 .. index:: Invalid values
519 pragma Assume_No_Invalid_Values (On | Off);
522 This is a configuration pragma that controls the assumptions made by the
523 compiler about the occurrence of invalid representations (invalid values)
526 The default behavior (corresponding to an Off argument for this pragma), is
527 to assume that values may in general be invalid unless the compiler can
528 prove they are valid. Consider the following example:
532 V1 : Integer range 1 .. 10;
533 V2 : Integer range 11 .. 20;
535 for J in V2 .. V1 loop
540 if V1 and V2 have valid values, then the loop is known at compile
541 time not to execute since the lower bound must be greater than the
542 upper bound. However in default mode, no such assumption is made,
543 and the loop may execute. If ``Assume_No_Invalid_Values (On)``
544 is given, the compiler will assume that any occurrence of a variable
545 other than in an explicit ``'Valid`` test always has a valid
546 value, and the loop above will be optimized away.
548 The use of ``Assume_No_Invalid_Values (On)`` is appropriate if
549 you know your code is free of uninitialized variables and other
550 possible sources of invalid representations, and may result in
551 more efficient code. A program that accesses an invalid representation
552 with this pragma in effect is erroneous, so no guarantees can be made
555 It is peculiar though permissible to use this pragma in conjunction
556 with validity checking (-gnatVa). In such cases, accessing invalid
557 values will generally give an exception, though formally the program
558 is erroneous so there are no guarantees that this will always be the
559 case, and it is recommended that these two options not be used together.
561 .. _Pragma-Async_Readers:
570 pragma Asynch_Readers [ (boolean_EXPRESSION) ];
572 For the semantics of this pragma, see the entry for aspect ``Async_Readers`` in
573 the SPARK 2014 Reference Manual, section 7.1.2.
575 .. _Pragma-Async_Writers:
584 pragma Asynch_Writers [ (boolean_EXPRESSION) ];
586 For the semantics of this pragma, see the entry for aspect ``Async_Writers`` in
587 the SPARK 2014 Reference Manual, section 7.1.2.
589 Pragma Attribute_Definition
590 ===========================
596 pragma Attribute_Definition
597 ([Attribute =>] ATTRIBUTE_DESIGNATOR,
598 [Entity =>] LOCAL_NAME,
599 [Expression =>] EXPRESSION | NAME);
602 If ``Attribute`` is a known attribute name, this pragma is equivalent to
603 the attribute definition clause:
608 for Entity'Attribute use Expression;
611 If ``Attribute`` is not a recognized attribute name, the pragma is
612 ignored, and a warning is emitted. This allows source
613 code to be written that takes advantage of some new attribute, while remaining
614 compilable with earlier compilers.
616 Pragma C_Pass_By_Copy
617 =====================
618 .. index:: Passing by copy
625 pragma C_Pass_By_Copy
626 ([Max_Size =>] static_integer_EXPRESSION);
629 Normally the default mechanism for passing C convention records to C
630 convention subprograms is to pass them by reference, as suggested by RM
631 B.3(69). Use the configuration pragma ``C_Pass_By_Copy`` to change
632 this default, by requiring that record formal parameters be passed by
633 copy if all of the following conditions are met:
636 The size of the record type does not exceed the value specified for
639 The record type has ``Convention C``.
641 The formal parameter has this record type, and the subprogram has a
642 foreign (non-Ada) convention.
644 If these conditions are met the argument is passed by copy; i.e., in a
645 manner consistent with what C expects if the corresponding formal in the
646 C prototype is a struct (rather than a pointer to a struct).
648 You can also pass records by copy by specifying the convention
649 ``C_Pass_By_Copy`` for the record type, or by using the extended
650 ``Import`` and ``Export`` pragmas, which allow specification of
651 passing mechanisms on a parameter by parameter basis.
655 .. index:: Assertions
657 .. index:: Named assertions
665 [Name =>] CHECK_KIND,
666 [Check =>] Boolean_EXPRESSION
667 [, [Message =>] string_EXPRESSION] );
669 CHECK_KIND ::= IDENTIFIER |
672 Type_Invariant'Class |
676 This pragma is similar to the predefined pragma ``Assert`` except that an
677 extra identifier argument is present. In conjunction with pragma
678 ``Check_Policy``, this can be used to define groups of assertions that can
679 be independently controlled. The identifier ``Assertion`` is special, it
680 refers to the normal set of pragma ``Assert`` statements.
682 Checks introduced by this pragma are normally deactivated by default. They can
683 be activated either by the command line option *-gnata*, which turns on
684 all checks, or individually controlled using pragma ``Check_Policy``.
686 The identifiers ``Assertions`` and ``Statement_Assertions`` are not
687 permitted as check kinds, since this would cause confusion with the use
688 of these identifiers in ``Assertion_Policy`` and ``Check_Policy``
689 pragmas, where they are used to refer to sets of assertions.
691 Pragma Check_Float_Overflow
692 ===========================
693 .. index:: Floating-point overflow
700 pragma Check_Float_Overflow;
703 In Ada, the predefined floating-point types (``Short_Float``,
704 ``Float``, ``Long_Float``, ``Long_Long_Float``) are
705 defined to be *unconstrained*. This means that even though each
706 has a well-defined base range, an operation that delivers a result
707 outside this base range is not required to raise an exception.
708 This implementation permission accommodates the notion
709 of infinities in IEEE floating-point, and corresponds to the
710 efficient execution mode on most machines. GNAT will not raise
711 overflow exceptions on these machines; instead it will generate
712 infinities and NaN's as defined in the IEEE standard.
714 Generating infinities, although efficient, is not always desirable.
715 Often the preferable approach is to check for overflow, even at the
716 (perhaps considerable) expense of run-time performance.
717 This can be accomplished by defining your own constrained floating-point subtypes -- i.e., by supplying explicit
718 range constraints -- and indeed such a subtype
719 can have the same base range as its base type. For example:
724 subtype My_Float is Float range Float'Range;
727 Here ``My_Float`` has the same range as
728 ``Float`` but is constrained, so operations on
729 ``My_Float`` values will be checked for overflow
732 This style will achieve the desired goal, but
733 it is often more convenient to be able to simply use
734 the standard predefined floating-point types as long
735 as overflow checking could be guaranteed.
736 The ``Check_Float_Overflow``
737 configuration pragma achieves this effect. If a unit is compiled
738 subject to this configuration pragma, then all operations
739 on predefined floating-point types including operations on
740 base types of these floating-point types will be treated as
741 though those types were constrained, and overflow checks
742 will be generated. The ``Constraint_Error``
743 exception is raised if the result is out of range.
745 This mode can also be set by use of the compiler
750 .. index:: Defining check names
752 .. index:: Check names, defining
759 pragma Check_Name (check_name_IDENTIFIER);
762 This is a configuration pragma that defines a new implementation
763 defined check name (unless IDENTIFIER matches one of the predefined
764 check names, in which case the pragma has no effect). Check names
765 are global to a partition, so if two or more configuration pragmas
766 are present in a partition mentioning the same name, only one new
767 check name is introduced.
769 An implementation defined check name introduced with this pragma may
770 be used in only three contexts: ``pragma Suppress``,
771 ``pragma Unsuppress``,
772 and as the prefix of a ``Check_Name'Enabled`` attribute reference. For
773 any of these three cases, the check name must be visible. A check
774 name is visible if it is in the configuration pragmas applying to
775 the current unit, or if it appears at the start of any unit that
776 is part of the dependency set of the current unit (e.g., units that
777 are mentioned in ``with`` clauses).
779 Check names introduced by this pragma are subject to control by compiler
780 switches (in particular -gnatp) in the usual manner.
784 .. index:: Controlling assertions
786 .. index:: Assertions, control
788 .. index:: Check pragma control
790 .. index:: Named assertions
798 ([Name =>] CHECK_KIND,
799 [Policy =>] POLICY_IDENTIFIER);
801 pragma Check_Policy (
802 CHECK_KIND => POLICY_IDENTIFIER
803 {, CHECK_KIND => POLICY_IDENTIFIER});
805 ASSERTION_KIND ::= RM_ASSERTION_KIND | ID_ASSERTION_KIND
807 CHECK_KIND ::= IDENTIFIER |
810 Type_Invariant'Class |
813 The identifiers Name and Policy are not allowed as CHECK_KIND values. This
814 avoids confusion between the two possible syntax forms for this pragma.
816 POLICY_IDENTIFIER ::= ON | OFF | CHECK | DISABLE | IGNORE
819 This pragma is used to set the checking policy for assertions (specified
820 by aspects or pragmas), the ``Debug`` pragma, or additional checks
821 to be checked using the ``Check`` pragma. It may appear either as
822 a configuration pragma, or within a declarative part of package. In the
823 latter case, it applies from the point where it appears to the end of
824 the declarative region (like pragma ``Suppress``).
826 The ``Check_Policy`` pragma is similar to the
827 predefined ``Assertion_Policy`` pragma,
828 and if the check kind corresponds to one of the assertion kinds that
829 are allowed by ``Assertion_Policy``, then the effect is identical.
831 If the first argument is Debug, then the policy applies to Debug pragmas,
832 disabling their effect if the policy is ``OFF``, ``DISABLE``, or
833 ``IGNORE``, and allowing them to execute with normal semantics if
834 the policy is ``ON`` or ``CHECK``. In addition if the policy is
835 ``DISABLE``, then the procedure call in ``Debug`` pragmas will
836 be totally ignored and not analyzed semantically.
838 Finally the first argument may be some other identifier than the above
839 possibilities, in which case it controls a set of named assertions
840 that can be checked using pragma ``Check``. For example, if the pragma:
845 pragma Check_Policy (Critical_Error, OFF);
848 is given, then subsequent ``Check`` pragmas whose first argument is also
849 ``Critical_Error`` will be disabled.
851 The check policy is ``OFF`` to turn off corresponding checks, and ``ON``
852 to turn on corresponding checks. The default for a set of checks for which no
853 ``Check_Policy`` is given is ``OFF`` unless the compiler switch
854 *-gnata* is given, which turns on all checks by default.
856 The check policy settings ``CHECK`` and ``IGNORE`` are recognized
857 as synonyms for ``ON`` and ``OFF``. These synonyms are provided for
858 compatibility with the standard ``Assertion_Policy`` pragma. The check
859 policy setting ``DISABLE`` causes the second argument of a corresponding
860 ``Check`` pragma to be completely ignored and not analyzed.
870 pragma Comment (static_string_EXPRESSION);
873 This is almost identical in effect to pragma ``Ident``. It allows the
874 placement of a comment into the object file and hence into the
875 executable file if the operating system permits such usage. The
876 difference is that ``Comment``, unlike ``Ident``, has
877 no limitations on placement of the pragma (it can be placed
878 anywhere in the main source unit), and if more than one pragma
879 is used, all comments are retained.
889 pragma Common_Object (
890 [Internal =>] LOCAL_NAME
891 [, [External =>] EXTERNAL_SYMBOL]
892 [, [Size =>] EXTERNAL_SYMBOL] );
896 | static_string_EXPRESSION
899 This pragma enables the shared use of variables stored in overlaid
900 linker areas corresponding to the use of ``COMMON``
901 in Fortran. The single
902 object ``LOCAL_NAME`` is assigned to the area designated by
903 the ``External`` argument.
904 You may define a record to correspond to a series
905 of fields. The ``Size`` argument
906 is syntax checked in GNAT, but otherwise ignored.
908 ``Common_Object`` is not supported on all platforms. If no
909 support is available, then the code generator will issue a message
910 indicating that the necessary attribute for implementation of this
911 pragma is not available.
913 Pragma Compile_Time_Error
914 =========================
921 pragma Compile_Time_Error
922 (boolean_EXPRESSION, static_string_EXPRESSION);
925 This pragma can be used to generate additional compile time
927 is particularly useful in generics, where errors can be issued for
928 specific problematic instantiations. The first parameter is a boolean
929 expression. The pragma is effective only if the value of this expression
930 is known at compile time, and has the value True. The set of expressions
931 whose values are known at compile time includes all static boolean
932 expressions, and also other values which the compiler can determine
933 at compile time (e.g., the size of a record type set by an explicit
934 size representation clause, or the value of a variable which was
935 initialized to a constant and is known not to have been modified).
936 If these conditions are met, an error message is generated using
937 the value given as the second argument. This string value may contain
938 embedded ASCII.LF characters to break the message into multiple lines.
940 Pragma Compile_Time_Warning
941 ===========================
948 pragma Compile_Time_Warning
949 (boolean_EXPRESSION, static_string_EXPRESSION);
952 Same as pragma Compile_Time_Error, except a warning is issued instead
953 of an error message. Note that if this pragma is used in a package that
954 is with'ed by a client, the client will get the warning even though it
955 is issued by a with'ed package (normally warnings in with'ed units are
956 suppressed, but this is a special exception to that rule).
958 One typical use is within a generic where compile time known characteristics
959 of formal parameters are tested, and warnings given appropriately. Another use
960 with a first parameter of True is to warn a client about use of a package,
961 for example that it is not fully implemented.
971 pragma Compiler_Unit;
974 This pragma is obsolete. It is equivalent to Compiler_Unit_Warning. It is
975 retained so that old versions of the GNAT run-time that use this pragma can
976 be compiled with newer versions of the compiler.
978 Pragma Compiler_Unit_Warning
979 ============================
986 pragma Compiler_Unit_Warning;
989 This pragma is intended only for internal use in the GNAT run-time library.
990 It indicates that the unit is used as part of the compiler build. The effect
991 is to generate warnings for the use of constructs (for example, conditional
992 expressions) that would cause trouble when bootstrapping using an older
993 version of GNAT. For the exact list of restrictions, see the compiler sources
994 and references to Check_Compiler_Unit.
996 Pragma Complete_Representation
997 ==============================
1004 pragma Complete_Representation;
1007 This pragma must appear immediately within a record representation
1008 clause. Typical placements are before the first component clause
1009 or after the last component clause. The effect is to give an error
1010 message if any component is missing a component clause. This pragma
1011 may be used to ensure that a record representation clause is
1012 complete, and that this invariant is maintained if fields are
1013 added to the record in the future.
1015 Pragma Complex_Representation
1016 =============================
1023 pragma Complex_Representation
1024 ([Entity =>] LOCAL_NAME);
1027 The ``Entity`` argument must be the name of a record type which has
1028 two fields of the same floating-point type. The effect of this pragma is
1029 to force gcc to use the special internal complex representation form for
1030 this record, which may be more efficient. Note that this may result in
1031 the code for this type not conforming to standard ABI (application
1032 binary interface) requirements for the handling of record types. For
1033 example, in some environments, there is a requirement for passing
1034 records by pointer, and the use of this pragma may result in passing
1035 this type in floating-point registers.
1037 Pragma Component_Alignment
1038 ==========================
1039 .. index:: Alignments of components
1040 .. index:: Pragma Component_Alignment
1047 pragma Component_Alignment (
1048 [Form =>] ALIGNMENT_CHOICE
1049 [, [Name =>] type_LOCAL_NAME]);
1051 ALIGNMENT_CHOICE ::=
1058 Specifies the alignment of components in array or record types.
1059 The meaning of the ``Form`` argument is as follows:
1062 .. index:: Component_Size (in pragma Component_Alignment)
1065 Aligns scalar components and subcomponents of the array or record type
1066 on boundaries appropriate to their inherent size (naturally
1067 aligned). For example, 1-byte components are aligned on byte boundaries,
1068 2-byte integer components are aligned on 2-byte boundaries, 4-byte
1069 integer components are aligned on 4-byte boundaries and so on. These
1070 alignment rules correspond to the normal rules for C compilers on all
1071 machines except the VAX.
1073 .. index:: Component_Size_4 (in pragma Component_Alignment)
1076 Naturally aligns components with a size of four or fewer
1077 bytes. Components that are larger than 4 bytes are placed on the next
1080 .. index:: Storage_Unit (in pragma Component_Alignment)
1083 Specifies that array or record components are byte aligned, i.e.,
1084 aligned on boundaries determined by the value of the constant
1085 ``System.Storage_Unit``.
1087 .. index:: Default (in pragma Component_Alignment)
1090 Specifies that array or record components are aligned on default
1091 boundaries, appropriate to the underlying hardware or operating system or
1092 both. The ``Default`` choice is the same as ``Component_Size`` (natural
1095 If the ``Name`` parameter is present, ``type_LOCAL_NAME`` must
1096 refer to a local record or array type, and the specified alignment
1097 choice applies to the specified type. The use of
1098 ``Component_Alignment`` together with a pragma ``Pack`` causes the
1099 ``Component_Alignment`` pragma to be ignored. The use of
1100 ``Component_Alignment`` together with a record representation clause
1101 is only effective for fields not specified by the representation clause.
1103 If the ``Name`` parameter is absent, the pragma can be used as either
1104 a configuration pragma, in which case it applies to one or more units in
1105 accordance with the normal rules for configuration pragmas, or it can be
1106 used within a declarative part, in which case it applies to types that
1107 are declared within this declarative part, or within any nested scope
1108 within this declarative part. In either case it specifies the alignment
1109 to be applied to any record or array type which has otherwise standard
1112 If the alignment for a record or array type is not specified (using
1113 pragma ``Pack``, pragma ``Component_Alignment``, or a record rep
1114 clause), the GNAT uses the default alignment as described previously.
1116 .. _Pragma-Constant_After_Elaboration:
1118 Pragma Constant_After_Elaboration
1119 =================================
1125 pragma Constant_After_Elaboration [ (boolean_EXPRESSION) ];
1127 For the semantics of this pragma, see the entry for aspect
1128 ``Constant_After_Elaboration`` in the SPARK 2014 Reference Manual, section 3.3.1.
1130 .. _Pragma-Contract_Cases:
1132 Pragma Contract_Cases
1133 =====================
1134 .. index:: Contract cases
1140 pragma Contract_Cases ((CONTRACT_CASE {, CONTRACT_CASE));
1142 CONTRACT_CASE ::= CASE_GUARD => CONSEQUENCE
1144 CASE_GUARD ::= boolean_EXPRESSION | others
1146 CONSEQUENCE ::= boolean_EXPRESSION
1148 The ``Contract_Cases`` pragma allows defining fine-grain specifications
1149 that can complement or replace the contract given by a precondition and a
1150 postcondition. Additionally, the ``Contract_Cases`` pragma can be used
1151 by testing and formal verification tools. The compiler checks its validity and,
1152 depending on the assertion policy at the point of declaration of the pragma,
1153 it may insert a check in the executable. For code generation, the contract
1159 pragma Contract_Cases (
1169 C1 : constant Boolean := Cond1; -- evaluated at subprogram entry
1170 C2 : constant Boolean := Cond2; -- evaluated at subprogram entry
1171 pragma Precondition ((C1 and not C2) or (C2 and not C1));
1172 pragma Postcondition (if C1 then Pred1);
1173 pragma Postcondition (if C2 then Pred2);
1176 The precondition ensures that one and only one of the case guards is
1177 satisfied on entry to the subprogram.
1178 The postcondition ensures that for the case guard that was True on entry,
1179 the corrresponding consequence is True on exit. Other consequence expressions
1182 A precondition ``P`` and postcondition ``Q`` can also be
1183 expressed as contract cases:
1187 pragma Contract_Cases (P => Q);
1190 The placement and visibility rules for ``Contract_Cases`` pragmas are
1191 identical to those described for preconditions and postconditions.
1193 The compiler checks that boolean expressions given in case guards and
1194 consequences are valid, where the rules for case guards are the same as
1195 the rule for an expression in ``Precondition`` and the rules for
1196 consequences are the same as the rule for an expression in
1197 ``Postcondition``. In particular, attributes ``'Old`` and
1198 ``'Result`` can only be used within consequence expressions.
1199 The case guard for the last contract case may be ``others``, to denote
1200 any case not captured by the previous cases. The
1201 following is an example of use within a package spec:
1206 package Math_Functions is
1208 function Sqrt (Arg : Float) return Float;
1209 pragma Contract_Cases (((Arg in 0.0 .. 99.0) => Sqrt'Result < 10.0,
1210 Arg >= 100.0 => Sqrt'Result >= 10.0,
1211 others => Sqrt'Result = 0.0));
1216 The meaning of contract cases is that only one case should apply at each
1217 call, as determined by the corresponding case guard evaluating to True,
1218 and that the consequence for this case should hold when the subprogram
1221 Pragma Convention_Identifier
1222 ============================
1223 .. index:: Conventions, synonyms
1230 pragma Convention_Identifier (
1231 [Name =>] IDENTIFIER,
1232 [Convention =>] convention_IDENTIFIER);
1235 This pragma provides a mechanism for supplying synonyms for existing
1236 convention identifiers. The ``Name`` identifier can subsequently
1237 be used as a synonym for the given convention in other pragmas (including
1238 for example pragma ``Import`` or another ``Convention_Identifier``
1239 pragma). As an example of the use of this, suppose you had legacy code
1240 which used Fortran77 as the identifier for Fortran. Then the pragma:
1245 pragma Convention_Identifier (Fortran77, Fortran);
1248 would allow the use of the convention identifier ``Fortran77`` in
1249 subsequent code, avoiding the need to modify the sources. As another
1250 example, you could use this to parameterize convention requirements
1251 according to systems. Suppose you needed to use ``Stdcall`` on
1252 windows systems, and ``C`` on some other system, then you could
1253 define a convention identifier ``Library`` and use a single
1254 ``Convention_Identifier`` pragma to specify which convention
1255 would be used system-wide.
1259 .. index:: Interfacing with C++
1266 pragma CPP_Class ([Entity =>] LOCAL_NAME);
1269 The argument denotes an entity in the current declarative region that is
1270 declared as a record type. It indicates that the type corresponds to an
1271 externally declared C++ class type, and is to be laid out the same way
1272 that C++ would lay out the type. If the C++ class has virtual primitives
1273 then the record must be declared as a tagged record type.
1275 Types for which ``CPP_Class`` is specified do not have assignment or
1276 equality operators defined (such operations can be imported or declared
1277 as subprograms as required). Initialization is allowed only by constructor
1278 functions (see pragma ``CPP_Constructor``). Such types are implicitly
1279 limited if not explicitly declared as limited or derived from a limited
1280 type, and an error is issued in that case.
1282 See :ref:`Interfacing_to_C++` for related information.
1284 Note: Pragma ``CPP_Class`` is currently obsolete. It is supported
1285 for backward compatibility but its functionality is available
1286 using pragma ``Import`` with ``Convention`` = ``CPP``.
1288 Pragma CPP_Constructor
1289 ======================
1290 .. index:: Interfacing with C++
1298 pragma CPP_Constructor ([Entity =>] LOCAL_NAME
1299 [, [External_Name =>] static_string_EXPRESSION ]
1300 [, [Link_Name =>] static_string_EXPRESSION ]);
1303 This pragma identifies an imported function (imported in the usual way
1304 with pragma ``Import``) as corresponding to a C++ constructor. If
1305 ``External_Name`` and ``Link_Name`` are not specified then the
1306 ``Entity`` argument is a name that must have been previously mentioned
1307 in a pragma ``Import`` with ``Convention`` = ``CPP``. Such name
1308 must be of one of the following forms:
1311 **function** ``Fname`` **return** T`
1314 **function** ``Fname`` **return** T'Class
1317 **function** ``Fname`` (...) **return** T`
1320 **function** ``Fname`` (...) **return** T'Class
1322 where ``T`` is a limited record type imported from C++ with pragma
1323 ``Import`` and ``Convention`` = ``CPP``.
1325 The first two forms import the default constructor, used when an object
1326 of type ``T`` is created on the Ada side with no explicit constructor.
1327 The latter two forms cover all the non-default constructors of the type.
1328 See the GNAT User's Guide for details.
1330 If no constructors are imported, it is impossible to create any objects
1331 on the Ada side and the type is implicitly declared abstract.
1333 Pragma ``CPP_Constructor`` is intended primarily for automatic generation
1334 using an automatic binding generator tool (such as the :switch:`-fdump-ada-spec`
1336 See :ref:`Interfacing_to_C++` for more related information.
1338 Note: The use of functions returning class-wide types for constructors is
1339 currently obsolete. They are supported for backward compatibility. The
1340 use of functions returning the type T leave the Ada sources more clear
1341 because the imported C++ constructors always return an object of type T;
1342 that is, they never return an object whose type is a descendant of type T.
1346 .. index:: Interfacing to C++
1349 This pragma is now obsolete and, other than generating a warning if warnings
1350 on obsolescent features are enabled, is completely ignored.
1351 It is retained for compatibility
1352 purposes. It used to be required to ensure compoatibility with C++, but
1353 is no longer required for that purpose because GNAT generates
1354 the same object layout as the G++ compiler by default.
1356 See :ref:`Interfacing_to_C++` for related information.
1360 .. index:: Interfacing with C++
1363 This pragma is now obsolete and, other than generating a warning if warnings
1364 on obsolescent features are enabled, is completely ignored.
1365 It used to be required to ensure compatibility with C++, but
1366 is no longer required for that purpose because GNAT generates
1367 the same object layout as the G++ compiler by default.
1369 See :ref:`Interfacing_to_C++` for related information.
1379 pragma CPU (EXPRESSION);
1382 This pragma is standard in Ada 2012, but is available in all earlier
1383 versions of Ada as an implementation-defined pragma.
1384 See Ada 2012 Reference Manual for details.
1386 Pragma Deadline_Floor
1387 =====================
1394 pragma Deadline_Floor (time_span_EXPRESSION);
1397 This pragma applies only to protected types and specifies the floor
1398 deadline inherited by a task when the task enters a protected object.
1399 It is effective only when the EDF scheduling policy is used.
1401 .. _Pragma-Default_Initial_Condition:
1403 Pragma Default_Initial_Condition
1404 ================================
1410 pragma Default_Initial_Condition [ (null | boolean_EXPRESSION) ];
1412 For the semantics of this pragma, see the entry for aspect
1413 ``Default_Initial_Condition`` in the SPARK 2014 Reference Manual, section 7.3.3.
1423 pragma Debug ([CONDITION, ]PROCEDURE_CALL_WITHOUT_SEMICOLON);
1425 PROCEDURE_CALL_WITHOUT_SEMICOLON ::=
1427 | PROCEDURE_PREFIX ACTUAL_PARAMETER_PART
1430 The procedure call argument has the syntactic form of an expression, meeting
1431 the syntactic requirements for pragmas.
1433 If debug pragmas are not enabled or if the condition is present and evaluates
1434 to False, this pragma has no effect. If debug pragmas are enabled, the
1435 semantics of the pragma is exactly equivalent to the procedure call statement
1436 corresponding to the argument with a terminating semicolon. Pragmas are
1437 permitted in sequences of declarations, so you can use pragma ``Debug`` to
1438 intersperse calls to debug procedures in the middle of declarations. Debug
1439 pragmas can be enabled either by use of the command line switch *-gnata*
1440 or by use of the pragma ``Check_Policy`` with a first argument of
1451 pragma Debug_Policy (CHECK | DISABLE | IGNORE | ON | OFF);
1454 This pragma is equivalent to a corresponding ``Check_Policy`` pragma
1455 with a first argument of ``Debug``. It is retained for historical
1456 compatibility reasons.
1458 Pragma Default_Scalar_Storage_Order
1459 ===================================
1460 .. index:: Default_Scalar_Storage_Order
1462 .. index:: Scalar_Storage_Order
1470 pragma Default_Scalar_Storage_Order (High_Order_First | Low_Order_First);
1473 Normally if no explicit ``Scalar_Storage_Order`` is given for a record
1474 type or array type, then the scalar storage order defaults to the ordinary
1475 default for the target. But this default may be overridden using this pragma.
1476 The pragma may appear as a configuration pragma, or locally within a package
1477 spec or declarative part. In the latter case, it applies to all subsequent
1478 types declared within that package spec or declarative part.
1480 The following example shows the use of this pragma:
1485 pragma Default_Scalar_Storage_Order (High_Order_First);
1486 with System; use System;
1495 for L2'Scalar_Storage_Order use Low_Order_First;
1504 pragma Default_Scalar_Storage_Order (Low_Order_First);
1511 type H4a is new Inner.L4;
1519 In this example record types with names starting with *L* have `Low_Order_First` scalar
1520 storage order, and record types with names starting with *H* have ``High_Order_First``.
1521 Note that in the case of ``H4a``, the order is not inherited
1522 from the parent type. Only an explicitly set ``Scalar_Storage_Order``
1523 gets inherited on type derivation.
1525 If this pragma is used as a configuration pragma which appears within a
1526 configuration pragma file (as opposed to appearing explicitly at the start
1527 of a single unit), then the binder will require that all units in a partition
1528 be compiled in a similar manner, other than run-time units, which are not
1529 affected by this pragma. Note that the use of this form is discouraged because
1530 it may significantly degrade the run-time performance of the software, instead
1531 the default scalar storage order ought to be changed only on a local basis.
1533 Pragma Default_Storage_Pool
1534 ===========================
1535 .. index:: Default_Storage_Pool
1543 pragma Default_Storage_Pool (storage_pool_NAME | null);
1546 This pragma is standard in Ada 2012, but is available in all earlier
1547 versions of Ada as an implementation-defined pragma.
1548 See Ada 2012 Reference Manual for details.
1559 pragma Depends (DEPENDENCY_RELATION);
1561 DEPENDENCY_RELATION ::=
1563 | (DEPENDENCY_CLAUSE {, DEPENDENCY_CLAUSE})
1565 DEPENDENCY_CLAUSE ::=
1566 OUTPUT_LIST =>[+] INPUT_LIST
1567 | NULL_DEPENDENCY_CLAUSE
1569 NULL_DEPENDENCY_CLAUSE ::= null => INPUT_LIST
1571 OUTPUT_LIST ::= OUTPUT | (OUTPUT {, OUTPUT})
1573 INPUT_LIST ::= null | INPUT | (INPUT {, INPUT})
1575 OUTPUT ::= NAME | FUNCTION_RESULT
1578 where FUNCTION_RESULT is a function Result attribute_reference
1580 For the semantics of this pragma, see the entry for aspect ``Depends`` in the
1581 SPARK 2014 Reference Manual, section 6.1.5.
1583 Pragma Detect_Blocking
1584 ======================
1590 pragma Detect_Blocking;
1593 This is a standard pragma in Ada 2005, that is available in all earlier
1594 versions of Ada as an implementation-defined pragma.
1596 This is a configuration pragma that forces the detection of potentially
1597 blocking operations within a protected operation, and to raise Program_Error
1600 Pragma Disable_Atomic_Synchronization
1601 =====================================
1603 .. index:: Atomic Synchronization
1609 pragma Disable_Atomic_Synchronization [(Entity)];
1612 Ada requires that accesses (reads or writes) of an atomic variable be
1613 regarded as synchronization points in the case of multiple tasks.
1614 Particularly in the case of multi-processors this may require special
1615 handling, e.g. the generation of memory barriers. This capability may
1616 be turned off using this pragma in cases where it is known not to be
1619 The placement and scope rules for this pragma are the same as those
1620 for ``pragma Suppress``. In particular it can be used as a
1621 configuration pragma, or in a declaration sequence where it applies
1622 till the end of the scope. If an ``Entity`` argument is present,
1623 the action applies only to that entity.
1625 Pragma Dispatching_Domain
1626 =========================
1633 pragma Dispatching_Domain (EXPRESSION);
1636 This pragma is standard in Ada 2012, but is available in all earlier
1637 versions of Ada as an implementation-defined pragma.
1638 See Ada 2012 Reference Manual for details.
1640 .. _Pragma-Effective_Reads:
1642 Pragma Effective_Reads
1643 ======================
1649 pragma Effective_Reads [ (boolean_EXPRESSION) ];
1651 For the semantics of this pragma, see the entry for aspect ``Effective_Reads`` in
1652 the SPARK 2014 Reference Manual, section 7.1.2.
1654 .. _Pragma-Effective_Writes:
1656 Pragma Effective_Writes
1657 =======================
1663 pragma Effective_Writes [ (boolean_EXPRESSION) ];
1665 For the semantics of this pragma, see the entry for aspect ``Effective_Writes``
1666 in the SPARK 2014 Reference Manual, section 7.1.2.
1668 Pragma Elaboration_Checks
1669 =========================
1670 .. index:: Elaboration control
1678 pragma Elaboration_Checks (Dynamic | Static);
1681 This is a configuration pragma which specifies the elaboration model to be
1682 used during compilation. For more information on the elaboration models of
1683 GNAT, consult the chapter on elaboration order handling in the *GNAT User's
1686 The pragma may appear in the following contexts:
1688 * Configuration pragmas file
1690 * Prior to the context clauses of a compilation unit's initial declaration
1692 Any other placement of the pragma will result in a warning and the effects of
1693 the offending pragma will be ignored.
1695 If the pragma argument is ``Dynamic``, then the dynamic elaboration model is in
1696 effect. If the pragma argument is ``Static``, then the static elaboration model
1701 .. index:: Elimination of unused subprograms
1710 [ Unit_Name => ] IDENTIFIER | SELECTED_COMPONENT ,
1711 [ Entity => ] IDENTIFIER |
1712 SELECTED_COMPONENT |
1714 [, Source_Location => SOURCE_TRACE ] );
1716 SOURCE_TRACE ::= STRING_LITERAL
1719 This pragma indicates that the given entity is not used in the program to be
1720 compiled and built, thus allowing the compiler to
1721 eliminate the code or data associated with the named entity. Any reference to
1722 an eliminated entity causes a compile-time or link-time error.
1724 The pragma has the following semantics, where ``U`` is the unit specified by
1725 the ``Unit_Name`` argument and ``E`` is the entity specified by the ``Entity``
1728 * ``E`` must be a subprogram that is explicitly declared either:
1732 o Within a generic package that is instantiated in ``U``, or
1734 o As an instance of generic subprogram instantiated in ``U``.
1736 Otherwise the pragma is ignored.
1738 * If ``E`` is overloaded within ``U`` then, in the absence of a
1739 ``Source_Location`` argument, all overloadings are eliminated.
1741 * If ``E`` is overloaded within ``U`` and only some overloadings
1742 are to be eliminated, then each overloading to be eliminated
1743 must be specified in a corresponding pragma ``Eliminate``
1744 with a ``Source_Location`` argument identifying the line where the
1745 declaration appears, as described below.
1747 * If ``E`` is declared as the result of a generic instantiation, then
1748 a ``Source_Location`` argument is needed, as described below
1750 Pragma ``Eliminate`` allows a program to be compiled in a system-independent
1751 manner, so that unused entities are eliminated but without
1752 needing to modify the source text. Normally the required set of
1753 ``Eliminate`` pragmas is constructed automatically using the ``gnatelim`` tool.
1755 Any source file change that removes, splits, or
1756 adds lines may make the set of ``Eliminate`` pragmas invalid because their
1757 ``Source_Location`` argument values may get out of date.
1759 Pragma ``Eliminate`` may be used where the referenced entity is a dispatching
1760 operation. In this case all the subprograms to which the given operation can
1761 dispatch are considered to be unused (are never called as a result of a direct
1762 or a dispatching call).
1764 The string literal given for the source location specifies the line number
1765 of the declaration of the entity, using the following syntax for ``SOURCE_TRACE``:
1769 SOURCE_TRACE ::= SOURCE_REFERENCE [ LBRACKET SOURCE_TRACE RBRACKET ]
1774 SOURCE_REFERENCE ::= FILE_NAME : LINE_NUMBER
1776 LINE_NUMBER ::= DIGIT {DIGIT}
1779 Spaces around the colon in a ``SOURCE_REFERENCE`` are optional.
1781 The source trace that is given as the ``Source_Location`` must obey the
1782 following rules (or else the pragma is ignored), where ``U`` is
1783 the unit ``U`` specified by the ``Unit_Name`` argument and ``E`` is the
1784 subprogram specified by the ``Entity`` argument:
1786 * ``FILE_NAME`` is the short name (with no directory
1787 information) of the Ada source file for ``U``, using the required syntax
1788 for the underlying file system (e.g. case is significant if the underlying
1789 operating system is case sensitive).
1790 If ``U`` is a package and ``E`` is a subprogram declared in the package
1791 specification and its full declaration appears in the package body,
1792 then the relevant source file is the one for the package specification;
1793 analogously if ``U`` is a generic package.
1795 * If ``E`` is not declared in a generic instantiation (this includes
1796 generic subprogram instances), the source trace includes only one source
1797 line reference. ``LINE_NUMBER`` gives the line number of the occurrence
1798 of the declaration of ``E`` within the source file (as a decimal literal
1799 without an exponent or point).
1801 * If ``E`` is declared by a generic instantiation, its source trace
1802 (from left to right) starts with the source location of the
1803 declaration of ``E`` in the generic unit and ends with the source
1804 location of the instantiation, given in square brackets. This approach is
1805 applied recursively with nested instantiations: the rightmost (nested
1806 most deeply in square brackets) element of the source trace is the location
1807 of the outermost instantiation, and the leftmost element (that is, outside
1808 of any square brackets) is the location of the declaration of ``E`` in
1815 pragma Eliminate (Pkg0, Proc);
1816 -- Eliminate (all overloadings of) Proc in Pkg0
1818 pragma Eliminate (Pkg1, Proc,
1819 Source_Location => "pkg1.ads:8");
1820 -- Eliminate overloading of Proc at line 8 in pkg1.ads
1822 -- Assume the following file contents:
1825 -- 2: type T is private;
1826 -- 3: package Gen_Pkg is
1827 -- 4: procedure Proc(N : T);
1833 -- 2: procedure Q is
1834 -- 3: package Inst_Pkg is new Gen_Pkg(Integer);
1835 -- ... -- No calls on Inst_Pkg.Proc
1838 -- The following pragma eliminates Inst_Pkg.Proc from Q
1839 pragma Eliminate (Q, Proc,
1840 Source_Location => "gen_pkg.ads:4[q.adb:3]");
1844 Pragma Enable_Atomic_Synchronization
1845 ====================================
1846 .. index:: Atomic Synchronization
1854 pragma Enable_Atomic_Synchronization [(Entity)];
1857 Ada requires that accesses (reads or writes) of an atomic variable be
1858 regarded as synchronization points in the case of multiple tasks.
1859 Particularly in the case of multi-processors this may require special
1860 handling, e.g. the generation of memory barriers. This synchronization
1861 is performed by default, but can be turned off using
1862 ``pragma Disable_Atomic_Synchronization``. The
1863 ``Enable_Atomic_Synchronization`` pragma can be used to turn
1866 The placement and scope rules for this pragma are the same as those
1867 for ``pragma Unsuppress``. In particular it can be used as a
1868 configuration pragma, or in a declaration sequence where it applies
1869 till the end of the scope. If an ``Entity`` argument is present,
1870 the action applies only to that entity.
1872 Pragma Export_Function
1873 ======================
1874 .. index:: Argument passing mechanisms
1882 pragma Export_Function (
1883 [Internal =>] LOCAL_NAME
1884 [, [External =>] EXTERNAL_SYMBOL]
1885 [, [Parameter_Types =>] PARAMETER_TYPES]
1886 [, [Result_Type =>] result_SUBTYPE_MARK]
1887 [, [Mechanism =>] MECHANISM]
1888 [, [Result_Mechanism =>] MECHANISM_NAME]);
1892 | static_string_EXPRESSION
1897 | TYPE_DESIGNATOR {, TYPE_DESIGNATOR}
1901 | subtype_Name ' Access
1905 | (MECHANISM_ASSOCIATION {, MECHANISM_ASSOCIATION})
1907 MECHANISM_ASSOCIATION ::=
1908 [formal_parameter_NAME =>] MECHANISM_NAME
1910 MECHANISM_NAME ::= Value | Reference
1913 Use this pragma to make a function externally callable and optionally
1914 provide information on mechanisms to be used for passing parameter and
1915 result values. We recommend, for the purposes of improving portability,
1916 this pragma always be used in conjunction with a separate pragma
1917 ``Export``, which must precede the pragma ``Export_Function``.
1918 GNAT does not require a separate pragma ``Export``, but if none is
1919 present, ``Convention Ada`` is assumed, which is usually
1920 not what is wanted, so it is usually appropriate to use this
1921 pragma in conjunction with a ``Export`` or ``Convention``
1922 pragma that specifies the desired foreign convention.
1923 Pragma ``Export_Function``
1924 (and ``Export``, if present) must appear in the same declarative
1925 region as the function to which they apply.
1927 The ``internal_name`` must uniquely designate the function to which the
1928 pragma applies. If more than one function name exists of this name in
1929 the declarative part you must use the ``Parameter_Types`` and
1930 ``Result_Type`` parameters to achieve the required
1931 unique designation. The `subtype_mark`\ s in these parameters must
1932 exactly match the subtypes in the corresponding function specification,
1933 using positional notation to match parameters with subtype marks.
1934 The form with an ``'Access`` attribute can be used to match an
1935 anonymous access parameter.
1937 .. index:: Suppressing external name
1939 Special treatment is given if the EXTERNAL is an explicit null
1940 string or a static string expressions that evaluates to the null
1941 string. In this case, no external name is generated. This form
1942 still allows the specification of parameter mechanisms.
1944 Pragma Export_Object
1945 ====================
1952 pragma Export_Object
1953 [Internal =>] LOCAL_NAME
1954 [, [External =>] EXTERNAL_SYMBOL]
1955 [, [Size =>] EXTERNAL_SYMBOL]
1959 | static_string_EXPRESSION
1962 This pragma designates an object as exported, and apart from the
1963 extended rules for external symbols, is identical in effect to the use of
1964 the normal ``Export`` pragma applied to an object. You may use a
1965 separate Export pragma (and you probably should from the point of view
1966 of portability), but it is not required. ``Size`` is syntax checked,
1967 but otherwise ignored by GNAT.
1969 Pragma Export_Procedure
1970 =======================
1977 pragma Export_Procedure (
1978 [Internal =>] LOCAL_NAME
1979 [, [External =>] EXTERNAL_SYMBOL]
1980 [, [Parameter_Types =>] PARAMETER_TYPES]
1981 [, [Mechanism =>] MECHANISM]);
1985 | static_string_EXPRESSION
1990 | TYPE_DESIGNATOR {, TYPE_DESIGNATOR}
1994 | subtype_Name ' Access
1998 | (MECHANISM_ASSOCIATION {, MECHANISM_ASSOCIATION})
2000 MECHANISM_ASSOCIATION ::=
2001 [formal_parameter_NAME =>] MECHANISM_NAME
2003 MECHANISM_NAME ::= Value | Reference
2006 This pragma is identical to ``Export_Function`` except that it
2007 applies to a procedure rather than a function and the parameters
2008 ``Result_Type`` and ``Result_Mechanism`` are not permitted.
2009 GNAT does not require a separate pragma ``Export``, but if none is
2010 present, ``Convention Ada`` is assumed, which is usually
2011 not what is wanted, so it is usually appropriate to use this
2012 pragma in conjunction with a ``Export`` or ``Convention``
2013 pragma that specifies the desired foreign convention.
2015 .. index:: Suppressing external name
2017 Special treatment is given if the EXTERNAL is an explicit null
2018 string or a static string expressions that evaluates to the null
2019 string. In this case, no external name is generated. This form
2020 still allows the specification of parameter mechanisms.
2030 pragma Export_Value (
2031 [Value =>] static_integer_EXPRESSION,
2032 [Link_Name =>] static_string_EXPRESSION);
2035 This pragma serves to export a static integer value for external use.
2036 The first argument specifies the value to be exported. The Link_Name
2037 argument specifies the symbolic name to be associated with the integer
2038 value. This pragma is useful for defining a named static value in Ada
2039 that can be referenced in assembly language units to be linked with
2040 the application. This pragma is currently supported only for the
2041 AAMP target and is ignored for other targets.
2043 Pragma Export_Valued_Procedure
2044 ==============================
2051 pragma Export_Valued_Procedure (
2052 [Internal =>] LOCAL_NAME
2053 [, [External =>] EXTERNAL_SYMBOL]
2054 [, [Parameter_Types =>] PARAMETER_TYPES]
2055 [, [Mechanism =>] MECHANISM]);
2059 | static_string_EXPRESSION
2064 | TYPE_DESIGNATOR {, TYPE_DESIGNATOR}
2068 | subtype_Name ' Access
2072 | (MECHANISM_ASSOCIATION {, MECHANISM_ASSOCIATION})
2074 MECHANISM_ASSOCIATION ::=
2075 [formal_parameter_NAME =>] MECHANISM_NAME
2077 MECHANISM_NAME ::= Value | Reference
2080 This pragma is identical to ``Export_Procedure`` except that the
2081 first parameter of ``LOCAL_NAME``, which must be present, must be of
2082 mode ``out``, and externally the subprogram is treated as a function
2083 with this parameter as the result of the function. GNAT provides for
2084 this capability to allow the use of ``out`` and ``in out``
2085 parameters in interfacing to external functions (which are not permitted
2087 GNAT does not require a separate pragma ``Export``, but if none is
2088 present, ``Convention Ada`` is assumed, which is almost certainly
2089 not what is wanted since the whole point of this pragma is to interface
2090 with foreign language functions, so it is usually appropriate to use this
2091 pragma in conjunction with a ``Export`` or ``Convention``
2092 pragma that specifies the desired foreign convention.
2094 .. index:: Suppressing external name
2096 Special treatment is given if the EXTERNAL is an explicit null
2097 string or a static string expressions that evaluates to the null
2098 string. In this case, no external name is generated. This form
2099 still allows the specification of parameter mechanisms.
2101 Pragma Extend_System
2102 ====================
2103 .. index:: System, extending
2105 .. index:: DEC Ada 83
2113 pragma Extend_System ([Name =>] IDENTIFIER);
2116 This pragma is used to provide backwards compatibility with other
2117 implementations that extend the facilities of package ``System``. In
2118 GNAT, ``System`` contains only the definitions that are present in
2119 the Ada RM. However, other implementations, notably the DEC Ada 83
2120 implementation, provide many extensions to package ``System``.
2122 For each such implementation accommodated by this pragma, GNAT provides a
2123 package :samp:`Aux_{xxx}`, e.g., ``Aux_DEC`` for the DEC Ada 83
2124 implementation, which provides the required additional definitions. You
2125 can use this package in two ways. You can ``with`` it in the normal
2126 way and access entities either by selection or using a ``use``
2127 clause. In this case no special processing is required.
2129 However, if existing code contains references such as
2130 :samp:`System.{xxx}` where *xxx* is an entity in the extended
2131 definitions provided in package ``System``, you may use this pragma
2132 to extend visibility in ``System`` in a non-standard way that
2133 provides greater compatibility with the existing code. Pragma
2134 ``Extend_System`` is a configuration pragma whose single argument is
2135 the name of the package containing the extended definition
2136 (e.g., ``Aux_DEC`` for the DEC Ada case). A unit compiled under
2137 control of this pragma will be processed using special visibility
2138 processing that looks in package :samp:`System.Aux_{xxx}` where
2139 :samp:`Aux_{xxx}` is the pragma argument for any entity referenced in
2140 package ``System``, but not found in package ``System``.
2142 You can use this pragma either to access a predefined ``System``
2143 extension supplied with the compiler, for example ``Aux_DEC`` or
2144 you can construct your own extension unit following the above
2145 definition. Note that such a package is a child of ``System``
2146 and thus is considered part of the implementation.
2147 To compile it you will have to use the *-gnatg* switch
2148 for compiling System units, as explained in the
2151 Pragma Extensions_Allowed
2152 =========================
2153 .. index:: Ada Extensions
2155 .. index:: GNAT Extensions
2162 pragma Extensions_Allowed (On | Off);
2165 This configuration pragma enables or disables the implementation
2166 extension mode (the use of Off as a parameter cancels the effect
2167 of the *-gnatX* command switch).
2169 In extension mode, the latest version of the Ada language is
2170 implemented (currently Ada 2012), and in addition a small number
2171 of GNAT specific extensions are recognized as follows:
2175 *Constrained attribute for generic objects*
2176 The ``Constrained`` attribute is permitted for objects of
2177 generic types. The result indicates if the corresponding actual
2180 .. _Pragma-Extensions_Visible:
2182 Pragma Extensions_Visible
2183 =========================
2189 pragma Extensions_Visible [ (boolean_EXPRESSION) ];
2191 For the semantics of this pragma, see the entry for aspect ``Extensions_Visible``
2192 in the SPARK 2014 Reference Manual, section 6.1.7.
2203 [ Convention =>] convention_IDENTIFIER,
2204 [ Entity =>] LOCAL_NAME
2205 [, [External_Name =>] static_string_EXPRESSION ]
2206 [, [Link_Name =>] static_string_EXPRESSION ]);
2209 This pragma is identical in syntax and semantics to pragma
2210 ``Export`` as defined in the Ada Reference Manual. It is
2211 provided for compatibility with some Ada 83 compilers that
2212 used this pragma for exactly the same purposes as pragma
2213 ``Export`` before the latter was standardized.
2215 Pragma External_Name_Casing
2216 ===========================
2217 .. index:: Dec Ada 83 casing compatibility
2219 .. index:: External Names, casing
2221 .. index:: Casing of External names
2229 pragma External_Name_Casing (
2230 Uppercase | Lowercase
2231 [, Uppercase | Lowercase | As_Is]);
2234 This pragma provides control over the casing of external names associated
2235 with Import and Export pragmas. There are two cases to consider:
2239 * Implicit external names
2241 Implicit external names are derived from identifiers. The most common case
2242 arises when a standard Ada Import or Export pragma is used with only two
2247 pragma Import (C, C_Routine);
2249 Since Ada is a case-insensitive language, the spelling of the identifier in
2250 the Ada source program does not provide any information on the desired
2251 casing of the external name, and so a convention is needed. In GNAT the
2252 default treatment is that such names are converted to all lower case
2253 letters. This corresponds to the normal C style in many environments.
2254 The first argument of pragma ``External_Name_Casing`` can be used to
2255 control this treatment. If ``Uppercase`` is specified, then the name
2256 will be forced to all uppercase letters. If ``Lowercase`` is specified,
2257 then the normal default of all lower case letters will be used.
2259 This same implicit treatment is also used in the case of extended DEC Ada 83
2260 compatible Import and Export pragmas where an external name is explicitly
2261 specified using an identifier rather than a string.
2264 * Explicit external names
2266 Explicit external names are given as string literals. The most common case
2267 arises when a standard Ada Import or Export pragma is used with three
2272 pragma Import (C, C_Routine, "C_routine");
2274 In this case, the string literal normally provides the exact casing required
2275 for the external name. The second argument of pragma
2276 ``External_Name_Casing`` may be used to modify this behavior.
2277 If ``Uppercase`` is specified, then the name
2278 will be forced to all uppercase letters. If ``Lowercase`` is specified,
2279 then the name will be forced to all lowercase letters. A specification of
2280 ``As_Is`` provides the normal default behavior in which the casing is
2281 taken from the string provided.
2283 This pragma may appear anywhere that a pragma is valid. In particular, it
2284 can be used as a configuration pragma in the :file:`gnat.adc` file, in which
2285 case it applies to all subsequent compilations, or it can be used as a program
2286 unit pragma, in which case it only applies to the current unit, or it can
2287 be used more locally to control individual Import/Export pragmas.
2289 It was primarily intended for use with OpenVMS systems, where many
2290 compilers convert all symbols to upper case by default. For interfacing to
2291 such compilers (e.g., the DEC C compiler), it may be convenient to use
2296 pragma External_Name_Casing (Uppercase, Uppercase);
2299 to enforce the upper casing of all external symbols.
2312 This is a configuration pragma which activates a mode in which speed is
2313 considered more important for floating-point operations than absolutely
2314 accurate adherence to the requirements of the standard. Currently the
2315 following operations are affected:
2319 *Complex Multiplication*
2320 The normal simple formula for complex multiplication can result in intermediate
2321 overflows for numbers near the end of the range. The Ada standard requires that
2322 this situation be detected and corrected by scaling, but in Fast_Math mode such
2323 cases will simply result in overflow. Note that to take advantage of this you
2324 must instantiate your own version of ``Ada.Numerics.Generic_Complex_Types``
2325 under control of the pragma, rather than use the preinstantiated versions.
2327 .. _Pragma-Favor_Top_Level:
2329 Pragma Favor_Top_Level
2330 ======================
2337 pragma Favor_Top_Level (type_NAME);
2340 The argument of pragma ``Favor_Top_Level`` must be a named access-to-subprogram
2341 type. This pragma is an efficiency hint to the compiler, regarding the use of
2342 ``'Access`` or ``'Unrestricted_Access`` on nested (non-library-level) subprograms.
2343 The pragma means that nested subprograms are not used with this type, or are
2344 rare, so that the generated code should be efficient in the top-level case.
2345 When this pragma is used, dynamically generated trampolines may be used on some
2346 targets for nested subprograms. See restriction ``No_Implicit_Dynamic_Code``.
2348 Pragma Finalize_Storage_Only
2349 ============================
2356 pragma Finalize_Storage_Only (first_subtype_LOCAL_NAME);
2359 The argument of pragma ``Finalize_Storage_Only`` must denote a local type which
2360 is derived from ``Ada.Finalization.Controlled`` or ``Limited_Controlled``. The
2361 pragma suppresses the call to ``Finalize`` for declared library-level objects
2362 of the argument type. This is mostly useful for types where finalization is
2363 only used to deal with storage reclamation since in most environments it is
2364 not necessary to reclaim memory just before terminating execution, hence the
2365 name. Note that this pragma does not suppress Finalize calls for library-level
2366 heap-allocated objects (see pragma ``No_Heap_Finalization``).
2368 Pragma Float_Representation
2369 ===========================
2373 pragma Float_Representation (FLOAT_REP[, float_type_LOCAL_NAME]);
2375 FLOAT_REP ::= VAX_Float | IEEE_Float
2378 In the one argument form, this pragma is a configuration pragma which
2379 allows control over the internal representation chosen for the predefined
2380 floating point types declared in the packages ``Standard`` and
2381 ``System``. This pragma is only provided for compatibility and has no effect.
2383 The two argument form specifies the representation to be used for
2384 the specified floating-point type. The argument must
2385 be ``IEEE_Float`` to specify the use of IEEE format, as follows:
2388 For a digits value of 6, 32-bit IEEE short format will be used.
2390 For a digits value of 15, 64-bit IEEE long format will be used.
2392 No other value of digits is permitted.
2403 pragma Ghost [ (boolean_EXPRESSION) ];
2405 For the semantics of this pragma, see the entry for aspect ``Ghost`` in the SPARK
2406 2014 Reference Manual, section 6.9.
2417 pragma Global (GLOBAL_SPECIFICATION);
2419 GLOBAL_SPECIFICATION ::=
2422 | (MODED_GLOBAL_LIST {, MODED_GLOBAL_LIST})
2424 MODED_GLOBAL_LIST ::= MODE_SELECTOR => GLOBAL_LIST
2426 MODE_SELECTOR ::= In_Out | Input | Output | Proof_In
2427 GLOBAL_LIST ::= GLOBAL_ITEM | (GLOBAL_ITEM {, GLOBAL_ITEM})
2428 GLOBAL_ITEM ::= NAME
2430 For the semantics of this pragma, see the entry for aspect ``Global`` in the
2431 SPARK 2014 Reference Manual, section 6.1.4.
2441 pragma Ident (static_string_EXPRESSION);
2444 This pragma is identical in effect to pragma ``Comment``. It is provided
2445 for compatibility with other Ada compilers providing this pragma.
2447 Pragma Ignore_Pragma
2448 ====================
2455 pragma Ignore_Pragma (pragma_IDENTIFIER);
2457 This is a configuration pragma
2458 that takes a single argument that is a simple identifier. Any subsequent
2459 use of a pragma whose pragma identifier matches this argument will be
2460 silently ignored. This may be useful when legacy code or code intended
2461 for compilation with some other compiler contains pragmas that match the
2462 name, but not the exact implementation, of a GNAT pragma. The use of this
2463 pragma allows such pragmas to be ignored, which may be useful in CodePeer
2464 mode, or during porting of legacy code.
2466 Pragma Implementation_Defined
2467 =============================
2474 pragma Implementation_Defined (local_NAME);
2477 This pragma marks a previously declared entity as implementation-defined.
2478 For an overloaded entity, applies to the most recent homonym.
2483 pragma Implementation_Defined;
2486 The form with no arguments appears anywhere within a scope, most
2487 typically a package spec, and indicates that all entities that are
2488 defined within the package spec are Implementation_Defined.
2490 This pragma is used within the GNAT runtime library to identify
2491 implementation-defined entities introduced in language-defined units,
2492 for the purpose of implementing the No_Implementation_Identifiers
2503 pragma Implemented (procedure_LOCAL_NAME, implementation_kind);
2505 implementation_kind ::= By_Entry | By_Protected_Procedure | By_Any
2508 This is an Ada 2012 representation pragma which applies to protected, task
2509 and synchronized interface primitives. The use of pragma Implemented provides
2510 a way to impose a static requirement on the overriding operation by adhering
2511 to one of the three implementation kinds: entry, protected procedure or any of
2512 the above. This pragma is available in all earlier versions of Ada as an
2513 implementation-defined pragma.
2518 type Synch_Iface is synchronized interface;
2519 procedure Prim_Op (Obj : in out Iface) is abstract;
2520 pragma Implemented (Prim_Op, By_Protected_Procedure);
2522 protected type Prot_1 is new Synch_Iface with
2523 procedure Prim_Op; -- Legal
2526 protected type Prot_2 is new Synch_Iface with
2527 entry Prim_Op; -- Illegal
2530 task type Task_Typ is new Synch_Iface with
2531 entry Prim_Op; -- Illegal
2535 When applied to the procedure_or_entry_NAME of a requeue statement, pragma
2536 Implemented determines the runtime behavior of the requeue. Implementation kind
2537 By_Entry guarantees that the action of requeueing will proceed from an entry to
2538 another entry. Implementation kind By_Protected_Procedure transforms the
2539 requeue into a dispatching call, thus eliminating the chance of blocking. Kind
2540 By_Any shares the behavior of By_Entry and By_Protected_Procedure depending on
2541 the target's overriding subprogram kind.
2543 Pragma Implicit_Packing
2544 =======================
2545 .. index:: Rational Profile
2552 pragma Implicit_Packing;
2555 This is a configuration pragma that requests implicit packing for packed
2556 arrays for which a size clause is given but no explicit pragma Pack or
2557 specification of Component_Size is present. It also applies to records
2558 where no record representation clause is present. Consider this example:
2563 type R is array (0 .. 7) of Boolean;
2567 In accordance with the recommendation in the RM (RM 13.3(53)), a Size clause
2568 does not change the layout of a composite object. So the Size clause in the
2569 above example is normally rejected, since the default layout of the array uses
2570 8-bit components, and thus the array requires a minimum of 64 bits.
2572 If this declaration is compiled in a region of code covered by an occurrence
2573 of the configuration pragma Implicit_Packing, then the Size clause in this
2574 and similar examples will cause implicit packing and thus be accepted. For
2575 this implicit packing to occur, the type in question must be an array of small
2576 components whose size is known at compile time, and the Size clause must
2577 specify the exact size that corresponds to the number of elements in the array
2578 multiplied by the size in bits of the component type (both single and
2579 multi-dimensioned arrays can be controlled with this pragma).
2581 .. index:: Array packing
2583 Similarly, the following example shows the use in the record case
2589 a, b, c, d, e, f, g, h : boolean;
2595 Without a pragma Pack, each Boolean field requires 8 bits, so the
2596 minimum size is 72 bits, but with a pragma Pack, 16 bits would be
2597 sufficient. The use of pragma Implicit_Packing allows this record
2598 declaration to compile without an explicit pragma Pack.
2600 Pragma Import_Function
2601 ======================
2608 pragma Import_Function (
2609 [Internal =>] LOCAL_NAME,
2610 [, [External =>] EXTERNAL_SYMBOL]
2611 [, [Parameter_Types =>] PARAMETER_TYPES]
2612 [, [Result_Type =>] SUBTYPE_MARK]
2613 [, [Mechanism =>] MECHANISM]
2614 [, [Result_Mechanism =>] MECHANISM_NAME]);
2618 | static_string_EXPRESSION
2622 | TYPE_DESIGNATOR {, TYPE_DESIGNATOR}
2626 | subtype_Name ' Access
2630 | (MECHANISM_ASSOCIATION {, MECHANISM_ASSOCIATION})
2632 MECHANISM_ASSOCIATION ::=
2633 [formal_parameter_NAME =>] MECHANISM_NAME
2640 This pragma is used in conjunction with a pragma ``Import`` to
2641 specify additional information for an imported function. The pragma
2642 ``Import`` (or equivalent pragma ``Interface``) must precede the
2643 ``Import_Function`` pragma and both must appear in the same
2644 declarative part as the function specification.
2646 The ``Internal`` argument must uniquely designate
2647 the function to which the
2648 pragma applies. If more than one function name exists of this name in
2649 the declarative part you must use the ``Parameter_Types`` and
2650 ``Result_Type`` parameters to achieve the required unique
2651 designation. Subtype marks in these parameters must exactly match the
2652 subtypes in the corresponding function specification, using positional
2653 notation to match parameters with subtype marks.
2654 The form with an ``'Access`` attribute can be used to match an
2655 anonymous access parameter.
2657 You may optionally use the ``Mechanism`` and ``Result_Mechanism``
2658 parameters to specify passing mechanisms for the
2659 parameters and result. If you specify a single mechanism name, it
2660 applies to all parameters. Otherwise you may specify a mechanism on a
2661 parameter by parameter basis using either positional or named
2662 notation. If the mechanism is not specified, the default mechanism
2665 Pragma Import_Object
2666 ====================
2673 pragma Import_Object
2674 [Internal =>] LOCAL_NAME
2675 [, [External =>] EXTERNAL_SYMBOL]
2676 [, [Size =>] EXTERNAL_SYMBOL]);
2680 | static_string_EXPRESSION
2683 This pragma designates an object as imported, and apart from the
2684 extended rules for external symbols, is identical in effect to the use of
2685 the normal ``Import`` pragma applied to an object. Unlike the
2686 subprogram case, you need not use a separate ``Import`` pragma,
2687 although you may do so (and probably should do so from a portability
2688 point of view). ``size`` is syntax checked, but otherwise ignored by
2691 Pragma Import_Procedure
2692 =======================
2699 pragma Import_Procedure (
2700 [Internal =>] LOCAL_NAME
2701 [, [External =>] EXTERNAL_SYMBOL]
2702 [, [Parameter_Types =>] PARAMETER_TYPES]
2703 [, [Mechanism =>] MECHANISM]);
2707 | static_string_EXPRESSION
2711 | TYPE_DESIGNATOR {, TYPE_DESIGNATOR}
2715 | subtype_Name ' Access
2719 | (MECHANISM_ASSOCIATION {, MECHANISM_ASSOCIATION})
2721 MECHANISM_ASSOCIATION ::=
2722 [formal_parameter_NAME =>] MECHANISM_NAME
2724 MECHANISM_NAME ::= Value | Reference
2727 This pragma is identical to ``Import_Function`` except that it
2728 applies to a procedure rather than a function and the parameters
2729 ``Result_Type`` and ``Result_Mechanism`` are not permitted.
2731 Pragma Import_Valued_Procedure
2732 ==============================
2739 pragma Import_Valued_Procedure (
2740 [Internal =>] LOCAL_NAME
2741 [, [External =>] EXTERNAL_SYMBOL]
2742 [, [Parameter_Types =>] PARAMETER_TYPES]
2743 [, [Mechanism =>] MECHANISM]);
2747 | static_string_EXPRESSION
2751 | TYPE_DESIGNATOR {, TYPE_DESIGNATOR}
2755 | subtype_Name ' Access
2759 | (MECHANISM_ASSOCIATION {, MECHANISM_ASSOCIATION})
2761 MECHANISM_ASSOCIATION ::=
2762 [formal_parameter_NAME =>] MECHANISM_NAME
2764 MECHANISM_NAME ::= Value | Reference
2767 This pragma is identical to ``Import_Procedure`` except that the
2768 first parameter of ``LOCAL_NAME``, which must be present, must be of
2769 mode ``out``, and externally the subprogram is treated as a function
2770 with this parameter as the result of the function. The purpose of this
2771 capability is to allow the use of ``out`` and ``in out``
2772 parameters in interfacing to external functions (which are not permitted
2773 in Ada functions). You may optionally use the ``Mechanism``
2774 parameters to specify passing mechanisms for the parameters.
2775 If you specify a single mechanism name, it applies to all parameters.
2776 Otherwise you may specify a mechanism on a parameter by parameter
2777 basis using either positional or named notation. If the mechanism is not
2778 specified, the default mechanism is used.
2780 Note that it is important to use this pragma in conjunction with a separate
2781 pragma Import that specifies the desired convention, since otherwise the
2782 default convention is Ada, which is almost certainly not what is required.
2792 pragma Independent (Local_NAME);
2795 This pragma is standard in Ada 2012 mode (which also provides an aspect
2796 of the same name). It is also available as an implementation-defined
2797 pragma in all earlier versions. It specifies that the
2798 designated object or all objects of the designated type must be
2799 independently addressable. This means that separate tasks can safely
2800 manipulate such objects. For example, if two components of a record are
2801 independent, then two separate tasks may access these two components.
2803 constraints on the representation of the object (for instance prohibiting
2806 Pragma Independent_Components
2807 =============================
2814 pragma Independent_Components (Local_NAME);
2817 This pragma is standard in Ada 2012 mode (which also provides an aspect
2818 of the same name). It is also available as an implementation-defined
2819 pragma in all earlier versions. It specifies that the components of the
2820 designated object, or the components of each object of the designated
2822 independently addressable. This means that separate tasks can safely
2823 manipulate separate components in the composite object. This may place
2824 constraints on the representation of the object (for instance prohibiting
2827 .. _Pragma-Initial_Condition:
2829 Pragma Initial_Condition
2830 ========================
2836 pragma Initial_Condition (boolean_EXPRESSION);
2838 For the semantics of this pragma, see the entry for aspect ``Initial_Condition``
2839 in the SPARK 2014 Reference Manual, section 7.1.6.
2841 Pragma Initialize_Scalars
2842 =========================
2843 .. index:: debugging with Initialize_Scalars
2850 pragma Initialize_Scalars;
2853 This pragma is similar to ``Normalize_Scalars`` conceptually but has
2854 two important differences. First, there is no requirement for the pragma
2855 to be used uniformly in all units of a partition, in particular, it is fine
2856 to use this just for some or all of the application units of a partition,
2857 without needing to recompile the run-time library.
2859 In the case where some units are compiled with the pragma, and some without,
2860 then a declaration of a variable where the type is defined in package
2861 Standard or is locally declared will always be subject to initialization,
2862 as will any declaration of a scalar variable. For composite variables,
2863 whether the variable is initialized may also depend on whether the package
2864 in which the type of the variable is declared is compiled with the pragma.
2866 The other important difference is that you can control the value used
2867 for initializing scalar objects. At bind time, you can select several
2868 options for initialization. You can
2869 initialize with invalid values (similar to Normalize_Scalars, though for
2870 Initialize_Scalars it is not always possible to determine the invalid
2871 values in complex cases like signed component fields with non-standard
2872 sizes). You can also initialize with high or
2873 low values, or with a specified bit pattern. See the GNAT
2874 User's Guide for binder options for specifying these cases.
2876 This means that you can compile a program, and then without having to
2877 recompile the program, you can run it with different values being used
2878 for initializing otherwise uninitialized values, to test if your program
2879 behavior depends on the choice. Of course the behavior should not change,
2880 and if it does, then most likely you have an incorrect reference to an
2881 uninitialized value.
2883 It is even possible to change the value at execution time eliminating even
2884 the need to rebind with a different switch using an environment variable.
2885 See the GNAT User's Guide for details.
2887 Note that pragma ``Initialize_Scalars`` is particularly useful in
2888 conjunction with the enhanced validity checking that is now provided
2889 in GNAT, which checks for invalid values under more conditions.
2890 Using this feature (see description of the *-gnatV* flag in the
2891 GNAT User's Guide) in conjunction with
2892 pragma ``Initialize_Scalars``
2893 provides a powerful new tool to assist in the detection of problems
2894 caused by uninitialized variables.
2896 Note: the use of ``Initialize_Scalars`` has a fairly extensive
2897 effect on the generated code. This may cause your code to be
2898 substantially larger. It may also cause an increase in the amount
2899 of stack required, so it is probably a good idea to turn on stack
2900 checking (see description of stack checking in the GNAT
2901 User's Guide) when using this pragma.
2903 .. _Pragma-Initializes:
2912 pragma Initializes (INITIALIZATION_LIST);
2914 INITIALIZATION_LIST ::=
2916 | (INITIALIZATION_ITEM {, INITIALIZATION_ITEM})
2918 INITIALIZATION_ITEM ::= name [=> INPUT_LIST]
2927 For the semantics of this pragma, see the entry for aspect ``Initializes`` in the
2928 SPARK 2014 Reference Manual, section 7.1.5.
2930 .. _Pragma-Inline_Always:
2932 Pragma Inline_Always
2933 ====================
2940 pragma Inline_Always (NAME [, NAME]);
2943 Similar to pragma ``Inline`` except that inlining is unconditional.
2944 Inline_Always instructs the compiler to inline every direct call to the
2945 subprogram or else to emit a compilation error, independently of any
2946 option, in particular *-gnatn* or *-gnatN* or the optimization level.
2947 It is an error to take the address or access of ``NAME``. It is also an error to
2948 apply this pragma to a primitive operation of a tagged type. Thanks to such
2949 restrictions, the compiler is allowed to remove the out-of-line body of ``NAME``.
2951 Pragma Inline_Generic
2952 =====================
2959 pragma Inline_Generic (GNAME {, GNAME});
2961 GNAME ::= generic_unit_NAME | generic_instance_NAME
2964 This pragma is provided for compatibility with Dec Ada 83. It has
2965 no effect in GNAT (which always inlines generics), other
2966 than to check that the given names are all names of generic units or
2978 [Convention =>] convention_identifier,
2979 [Entity =>] local_NAME
2980 [, [External_Name =>] static_string_expression]
2981 [, [Link_Name =>] static_string_expression]);
2984 This pragma is identical in syntax and semantics to
2985 the standard Ada pragma ``Import``. It is provided for compatibility
2986 with Ada 83. The definition is upwards compatible both with pragma
2987 ``Interface`` as defined in the Ada 83 Reference Manual, and also
2988 with some extended implementations of this pragma in certain Ada 83
2989 implementations. The only difference between pragma ``Interface``
2990 and pragma ``Import`` is that there is special circuitry to allow
2991 both pragmas to appear for the same subprogram entity (normally it
2992 is illegal to have multiple ``Import`` pragmas. This is useful in
2993 maintaining Ada 83/Ada 95 compatibility and is compatible with other
2996 Pragma Interface_Name
2997 =====================
3004 pragma Interface_Name (
3005 [Entity =>] LOCAL_NAME
3006 [, [External_Name =>] static_string_EXPRESSION]
3007 [, [Link_Name =>] static_string_EXPRESSION]);
3010 This pragma provides an alternative way of specifying the interface name
3011 for an interfaced subprogram, and is provided for compatibility with Ada
3012 83 compilers that use the pragma for this purpose. You must provide at
3013 least one of ``External_Name`` or ``Link_Name``.
3015 Pragma Interrupt_Handler
3016 ========================
3023 pragma Interrupt_Handler (procedure_LOCAL_NAME);
3026 This program unit pragma is supported for parameterless protected procedures
3027 as described in Annex C of the Ada Reference Manual. On the AAMP target
3028 the pragma can also be specified for nonprotected parameterless procedures
3029 that are declared at the library level (which includes procedures
3030 declared at the top level of a library package). In the case of AAMP,
3031 when this pragma is applied to a nonprotected procedure, the instruction
3032 ``IERET`` is generated for returns from the procedure, enabling
3033 maskable interrupts, in place of the normal return instruction.
3035 Pragma Interrupt_State
3036 ======================
3043 pragma Interrupt_State
3045 [State =>] SYSTEM | RUNTIME | USER);
3048 Normally certain interrupts are reserved to the implementation. Any attempt
3049 to attach an interrupt causes Program_Error to be raised, as described in
3050 RM C.3.2(22). A typical example is the ``SIGINT`` interrupt used in
3051 many systems for an :kbd:`Ctrl-C` interrupt. Normally this interrupt is
3052 reserved to the implementation, so that :kbd:`Ctrl-C` can be used to
3053 interrupt execution. Additionally, signals such as ``SIGSEGV``,
3054 ``SIGABRT``, ``SIGFPE`` and ``SIGILL`` are often mapped to specific
3055 Ada exceptions, or used to implement run-time functions such as the
3056 ``abort`` statement and stack overflow checking.
3058 Pragma ``Interrupt_State`` provides a general mechanism for overriding
3059 such uses of interrupts. It subsumes the functionality of pragma
3060 ``Unreserve_All_Interrupts``. Pragma ``Interrupt_State`` is not
3061 available on Windows or VMS. On all other platforms than VxWorks,
3062 it applies to signals; on VxWorks, it applies to vectored hardware interrupts
3063 and may be used to mark interrupts required by the board support package
3066 Interrupts can be in one of three states:
3070 The interrupt is reserved (no Ada handler can be installed), and the
3071 Ada run-time may not install a handler. As a result you are guaranteed
3072 standard system default action if this interrupt is raised. This also allows
3073 installing a low level handler via C APIs such as sigaction(), outside
3078 The interrupt is reserved (no Ada handler can be installed). The run time
3079 is allowed to install a handler for internal control purposes, but is
3080 not required to do so.
3084 The interrupt is unreserved. The user may install an Ada handler via
3085 Ada.Interrupts and pragma Interrupt_Handler or Attach_Handler to provide
3088 These states are the allowed values of the ``State`` parameter of the
3089 pragma. The ``Name`` parameter is a value of the type
3090 ``Ada.Interrupts.Interrupt_ID``. Typically, it is a name declared in
3091 ``Ada.Interrupts.Names``.
3093 This is a configuration pragma, and the binder will check that there
3094 are no inconsistencies between different units in a partition in how a
3095 given interrupt is specified. It may appear anywhere a pragma is legal.
3097 The effect is to move the interrupt to the specified state.
3099 By declaring interrupts to be SYSTEM, you guarantee the standard system
3100 action, such as a core dump.
3102 By declaring interrupts to be USER, you guarantee that you can install
3105 Note that certain signals on many operating systems cannot be caught and
3106 handled by applications. In such cases, the pragma is ignored. See the
3107 operating system documentation, or the value of the array ``Reserved``
3108 declared in the spec of package ``System.OS_Interface``.
3110 Overriding the default state of signals used by the Ada runtime may interfere
3111 with an application's runtime behavior in the cases of the synchronous signals,
3112 and in the case of the signal used to implement the ``abort`` statement.
3114 .. _Pragma-Invariant:
3125 ([Entity =>] private_type_LOCAL_NAME,
3126 [Check =>] EXPRESSION
3127 [,[Message =>] String_Expression]);
3130 This pragma provides exactly the same capabilities as the Type_Invariant aspect
3131 defined in AI05-0146-1, and in the Ada 2012 Reference Manual. The
3132 Type_Invariant aspect is fully implemented in Ada 2012 mode, but since it
3133 requires the use of the aspect syntax, which is not available except in 2012
3134 mode, it is not possible to use the Type_Invariant aspect in earlier versions
3135 of Ada. However the Invariant pragma may be used in any version of Ada. Also
3136 note that the aspect Invariant is a synonym in GNAT for the aspect
3137 Type_Invariant, but there is no pragma Type_Invariant.
3139 The pragma must appear within the visible part of the package specification,
3140 after the type to which its Entity argument appears. As with the Invariant
3141 aspect, the Check expression is not analyzed until the end of the visible
3142 part of the package, so it may contain forward references. The Message
3143 argument, if present, provides the exception message used if the invariant
3144 is violated. If no Message parameter is provided, a default message that
3145 identifies the line on which the pragma appears is used.
3147 It is permissible to have multiple Invariants for the same type entity, in
3148 which case they are and'ed together. It is permissible to use this pragma
3149 in Ada 2012 mode, but you cannot have both an invariant aspect and an
3150 invariant pragma for the same entity.
3152 For further details on the use of this pragma, see the Ada 2012 documentation
3153 of the Type_Invariant aspect.
3163 pragma Keep_Names ([On =>] enumeration_first_subtype_LOCAL_NAME);
3166 The ``LOCAL_NAME`` argument
3167 must refer to an enumeration first subtype
3168 in the current declarative part. The effect is to retain the enumeration
3169 literal names for use by ``Image`` and ``Value`` even if a global
3170 ``Discard_Names`` pragma applies. This is useful when you want to
3171 generally suppress enumeration literal names and for example you therefore
3172 use a ``Discard_Names`` pragma in the :file:`gnat.adc` file, but you
3173 want to retain the names for specific enumeration types.
3177 .. index:: License checking
3184 pragma License (Unrestricted | GPL | Modified_GPL | Restricted);
3187 This pragma is provided to allow automated checking for appropriate license
3188 conditions with respect to the standard and modified GPL. A pragma
3189 ``License``, which is a configuration pragma that typically appears at
3190 the start of a source file or in a separate :file:`gnat.adc` file, specifies
3191 the licensing conditions of a unit as follows:
3194 This is used for a unit that can be freely used with no license restrictions.
3195 Examples of such units are public domain units, and units from the Ada
3199 This is used for a unit that is licensed under the unmodified GPL, and which
3200 therefore cannot be ``with``\ ed by a restricted unit.
3203 This is used for a unit licensed under the GNAT modified GPL that includes
3204 a special exception paragraph that specifically permits the inclusion of
3205 the unit in programs without requiring the entire program to be released
3209 This is used for a unit that is restricted in that it is not permitted to
3210 depend on units that are licensed under the GPL. Typical examples are
3211 proprietary code that is to be released under more restrictive license
3212 conditions. Note that restricted units are permitted to ``with`` units
3213 which are licensed under the modified GPL (this is the whole point of the
3217 Normally a unit with no ``License`` pragma is considered to have an
3218 unknown license, and no checking is done. However, standard GNAT headers
3219 are recognized, and license information is derived from them as follows.
3221 A GNAT license header starts with a line containing 78 hyphens. The following
3222 comment text is searched for the appearance of any of the following strings.
3224 If the string 'GNU General Public License' is found, then the unit is assumed
3225 to have GPL license, unless the string 'As a special exception' follows, in
3226 which case the license is assumed to be modified GPL.
3228 If one of the strings
3229 'This specification is adapted from the Ada Semantic Interface' or
3230 'This specification is derived from the Ada Reference Manual' is found
3231 then the unit is assumed to be unrestricted.
3233 These default actions means that a program with a restricted license pragma
3234 will automatically get warnings if a GPL unit is inappropriately
3235 ``with``\ ed. For example, the program:
3241 procedure Secret_Stuff is
3246 if compiled with pragma ``License`` (``Restricted``) in a
3247 :file:`gnat.adc` file will generate the warning::
3251 >>> license of withed unit "Sem_Ch3" is incompatible
3253 2. with GNAT.Sockets;
3254 3. procedure Secret_Stuff is
3257 Here we get a warning on ``Sem_Ch3`` since it is part of the GNAT
3258 compiler and is licensed under the
3259 GPL, but no warning for ``GNAT.Sockets`` which is part of the GNAT
3260 run time, and is therefore licensed under the modified GPL.
3270 pragma Link_With (static_string_EXPRESSION {,static_string_EXPRESSION});
3273 This pragma is provided for compatibility with certain Ada 83 compilers.
3274 It has exactly the same effect as pragma ``Linker_Options`` except
3275 that spaces occurring within one of the string expressions are treated
3276 as separators. For example, in the following case:
3280 pragma Link_With ("-labc -ldef");
3283 results in passing the strings ``-labc`` and ``-ldef`` as two
3284 separate arguments to the linker. In addition pragma Link_With allows
3285 multiple arguments, with the same effect as successive pragmas.
3295 pragma Linker_Alias (
3296 [Entity =>] LOCAL_NAME,
3297 [Target =>] static_string_EXPRESSION);
3300 ``LOCAL_NAME`` must refer to an object that is declared at the library
3301 level. This pragma establishes the given entity as a linker alias for the
3302 given target. It is equivalent to ``__attribute__((alias))`` in GNU C
3303 and causes ``LOCAL_NAME`` to be emitted as an alias for the symbol
3304 ``static_string_EXPRESSION`` in the object file, that is to say no space
3305 is reserved for ``LOCAL_NAME`` by the assembler and it will be resolved
3306 to the same address as ``static_string_EXPRESSION`` by the linker.
3308 The actual linker name for the target must be used (e.g., the fully
3309 encoded name with qualification in Ada, or the mangled name in C++),
3310 or it must be declared using the C convention with ``pragma Import``
3311 or ``pragma Export``.
3313 Not all target machines support this pragma. On some of them it is accepted
3314 only if ``pragma Weak_External`` has been applied to ``LOCAL_NAME``.
3319 -- Example of the use of pragma Linker_Alias
3323 pragma Export (C, i);
3325 new_name_for_i : Integer;
3326 pragma Linker_Alias (new_name_for_i, "i");
3330 Pragma Linker_Constructor
3331 =========================
3338 pragma Linker_Constructor (procedure_LOCAL_NAME);
3341 ``procedure_LOCAL_NAME`` must refer to a parameterless procedure that
3342 is declared at the library level. A procedure to which this pragma is
3343 applied will be treated as an initialization routine by the linker.
3344 It is equivalent to ``__attribute__((constructor))`` in GNU C and
3345 causes ``procedure_LOCAL_NAME`` to be invoked before the entry point
3346 of the executable is called (or immediately after the shared library is
3347 loaded if the procedure is linked in a shared library), in particular
3348 before the Ada run-time environment is set up.
3350 Because of these specific contexts, the set of operations such a procedure
3351 can perform is very limited and the type of objects it can manipulate is
3352 essentially restricted to the elementary types. In particular, it must only
3353 contain code to which pragma Restrictions (No_Elaboration_Code) applies.
3355 This pragma is used by GNAT to implement auto-initialization of shared Stand
3356 Alone Libraries, which provides a related capability without the restrictions
3357 listed above. Where possible, the use of Stand Alone Libraries is preferable
3358 to the use of this pragma.
3360 Pragma Linker_Destructor
3361 ========================
3368 pragma Linker_Destructor (procedure_LOCAL_NAME);
3371 ``procedure_LOCAL_NAME`` must refer to a parameterless procedure that
3372 is declared at the library level. A procedure to which this pragma is
3373 applied will be treated as a finalization routine by the linker.
3374 It is equivalent to ``__attribute__((destructor))`` in GNU C and
3375 causes ``procedure_LOCAL_NAME`` to be invoked after the entry point
3376 of the executable has exited (or immediately before the shared library
3377 is unloaded if the procedure is linked in a shared library), in particular
3378 after the Ada run-time environment is shut down.
3380 See ``pragma Linker_Constructor`` for the set of restrictions that apply
3381 because of these specific contexts.
3383 .. _Pragma-Linker_Section:
3385 Pragma Linker_Section
3386 =====================
3393 pragma Linker_Section (
3394 [Entity =>] LOCAL_NAME,
3395 [Section =>] static_string_EXPRESSION);
3398 ``LOCAL_NAME`` must refer to an object, type, or subprogram that is
3399 declared at the library level. This pragma specifies the name of the
3400 linker section for the given entity. It is equivalent to
3401 ``__attribute__((section))`` in GNU C and causes ``LOCAL_NAME`` to
3402 be placed in the ``static_string_EXPRESSION`` section of the
3403 executable (assuming the linker doesn't rename the section).
3404 GNAT also provides an implementation defined aspect of the same name.
3406 In the case of specifying this aspect for a type, the effect is to
3407 specify the corresponding section for all library-level objects of
3408 the type that do not have an explicit linker section set. Note that
3409 this only applies to whole objects, not to components of composite objects.
3411 In the case of a subprogram, the linker section applies to all previously
3412 declared matching overloaded subprograms in the current declarative part
3413 which do not already have a linker section assigned. The linker section
3414 aspect is useful in this case for specifying different linker sections
3415 for different elements of such an overloaded set.
3417 Note that an empty string specifies that no linker section is specified.
3418 This is not quite the same as omitting the pragma or aspect, since it
3419 can be used to specify that one element of an overloaded set of subprograms
3420 has the default linker section, or that one object of a type for which a
3421 linker section is specified should has the default linker section.
3423 The compiler normally places library-level entities in standard sections
3424 depending on the class: procedures and functions generally go in the
3425 ``.text`` section, initialized variables in the ``.data`` section
3426 and uninitialized variables in the ``.bss`` section.
3428 Other, special sections may exist on given target machines to map special
3429 hardware, for example I/O ports or flash memory. This pragma is a means to
3430 defer the final layout of the executable to the linker, thus fully working
3431 at the symbolic level with the compiler.
3433 Some file formats do not support arbitrary sections so not all target
3434 machines support this pragma. The use of this pragma may cause a program
3435 execution to be erroneous if it is used to place an entity into an
3436 inappropriate section (e.g., a modified variable into the ``.text``
3437 section). See also ``pragma Persistent_BSS``.
3442 -- Example of the use of pragma Linker_Section
3446 pragma Volatile (Port_A);
3447 pragma Linker_Section (Port_A, ".bss.port_a");
3450 pragma Volatile (Port_B);
3451 pragma Linker_Section (Port_B, ".bss.port_b");
3453 type Port_Type is new Integer with Linker_Section => ".bss";
3454 PA : Port_Type with Linker_Section => ".bss.PA";
3455 PB : Port_Type; -- ends up in linker section ".bss"
3457 procedure Q with Linker_Section => "Qsection";
3460 .. _Pragma-Lock_Free:
3466 This pragma may be specified for protected types or objects. It specifies that
3467 the implementation of protected operations must be implemented without locks.
3468 Compilation fails if the compiler cannot generate lock-free code for the
3471 Pragma Loop_Invariant
3472 =====================
3479 pragma Loop_Invariant ( boolean_EXPRESSION );
3482 The effect of this pragma is similar to that of pragma ``Assert``,
3483 except that in an ``Assertion_Policy`` pragma, the identifier
3484 ``Loop_Invariant`` is used to control whether it is ignored or checked
3487 ``Loop_Invariant`` can only appear as one of the items in the sequence
3488 of statements of a loop body, or nested inside block statements that
3489 appear in the sequence of statements of a loop body.
3490 The intention is that it be used to
3491 represent a "loop invariant" assertion, i.e. something that is true each
3492 time through the loop, and which can be used to show that the loop is
3493 achieving its purpose.
3495 Multiple ``Loop_Invariant`` and ``Loop_Variant`` pragmas that
3496 apply to the same loop should be grouped in the same sequence of
3499 To aid in writing such invariants, the special attribute ``Loop_Entry``
3500 may be used to refer to the value of an expression on entry to the loop. This
3501 attribute can only be used within the expression of a ``Loop_Invariant``
3502 pragma. For full details, see documentation of attribute ``Loop_Entry``.
3504 Pragma Loop_Optimize
3505 ====================
3512 pragma Loop_Optimize (OPTIMIZATION_HINT {, OPTIMIZATION_HINT});
3514 OPTIMIZATION_HINT ::= Ivdep | No_Unroll | Unroll | No_Vector | Vector
3517 This pragma must appear immediately within a loop statement. It allows the
3518 programmer to specify optimization hints for the enclosing loop. The hints
3519 are not mutually exclusive and can be freely mixed, but not all combinations
3520 will yield a sensible outcome.
3522 There are five supported optimization hints for a loop:
3526 The programmer asserts that there are no loop-carried dependencies
3527 which would prevent consecutive iterations of the loop from being
3528 executed simultaneously.
3532 The loop must not be unrolled. This is a strong hint: the compiler will not
3533 unroll a loop marked with this hint.
3537 The loop should be unrolled. This is a weak hint: the compiler will try to
3538 apply unrolling to this loop preferably to other optimizations, notably
3539 vectorization, but there is no guarantee that the loop will be unrolled.
3543 The loop must not be vectorized. This is a strong hint: the compiler will not
3544 vectorize a loop marked with this hint.
3548 The loop should be vectorized. This is a weak hint: the compiler will try to
3549 apply vectorization to this loop preferably to other optimizations, notably
3550 unrolling, but there is no guarantee that the loop will be vectorized.
3553 These hints do not remove the need to pass the appropriate switches to the
3554 compiler in order to enable the relevant optimizations, that is to say
3555 *-funroll-loops* for unrolling and *-ftree-vectorize* for
3566 pragma Loop_Variant ( LOOP_VARIANT_ITEM {, LOOP_VARIANT_ITEM } );
3567 LOOP_VARIANT_ITEM ::= CHANGE_DIRECTION => discrete_EXPRESSION
3568 CHANGE_DIRECTION ::= Increases | Decreases
3571 ``Loop_Variant`` can only appear as one of the items in the sequence
3572 of statements of a loop body, or nested inside block statements that
3573 appear in the sequence of statements of a loop body.
3574 It allows the specification of quantities which must always
3575 decrease or increase in successive iterations of the loop. In its simplest
3576 form, just one expression is specified, whose value must increase or decrease
3577 on each iteration of the loop.
3579 In a more complex form, multiple arguments can be given which are intepreted
3580 in a nesting lexicographic manner. For example:
3584 pragma Loop_Variant (Increases => X, Decreases => Y);
3587 specifies that each time through the loop either X increases, or X stays
3588 the same and Y decreases. A ``Loop_Variant`` pragma ensures that the
3589 loop is making progress. It can be useful in helping to show informally
3590 or prove formally that the loop always terminates.
3592 ``Loop_Variant`` is an assertion whose effect can be controlled using
3593 an ``Assertion_Policy`` with a check name of ``Loop_Variant``. The
3594 policy can be ``Check`` to enable the loop variant check, ``Ignore``
3595 to ignore the check (in which case the pragma has no effect on the program),
3596 or ``Disable`` in which case the pragma is not even checked for correct
3599 Multiple ``Loop_Invariant`` and ``Loop_Variant`` pragmas that
3600 apply to the same loop should be grouped in the same sequence of
3603 The ``Loop_Entry`` attribute may be used within the expressions of the
3604 ``Loop_Variant`` pragma to refer to values on entry to the loop.
3606 Pragma Machine_Attribute
3607 ========================
3614 pragma Machine_Attribute (
3615 [Entity =>] LOCAL_NAME,
3616 [Attribute_Name =>] static_string_EXPRESSION
3617 [, [Info =>] static_EXPRESSION] );
3620 Machine-dependent attributes can be specified for types and/or
3621 declarations. This pragma is semantically equivalent to
3622 :samp:`__attribute__(({attribute_name}))` (if ``info`` is not
3623 specified) or :samp:`__attribute__(({attribute_name(info})))`
3624 in GNU C, where *attribute_name* is recognized by the
3625 compiler middle-end or the ``TARGET_ATTRIBUTE_TABLE`` machine
3626 specific macro. A string literal for the optional parameter ``info``
3627 is transformed into an identifier, which may make this pragma unusable
3628 for some attributes.
3629 For further information see :title:`GNU Compiler Collection (GCC) Internals`.
3637 (MAIN_OPTION [, MAIN_OPTION]);
3640 [Stack_Size =>] static_integer_EXPRESSION
3641 | [Task_Stack_Size_Default =>] static_integer_EXPRESSION
3642 | [Time_Slicing_Enabled =>] static_boolean_EXPRESSION
3645 This pragma is provided for compatibility with OpenVMS VAX Systems. It has
3646 no effect in GNAT, other than being syntax checked.
3654 (MAIN_STORAGE_OPTION [, MAIN_STORAGE_OPTION]);
3656 MAIN_STORAGE_OPTION ::=
3657 [WORKING_STORAGE =>] static_SIMPLE_EXPRESSION
3658 | [TOP_GUARD =>] static_SIMPLE_EXPRESSION
3661 This pragma is provided for compatibility with OpenVMS VAX Systems. It has
3662 no effect in GNAT, other than being syntax checked.
3664 .. _Pragma-Max_Queue_Length:
3666 Pragma Max_Queue_Length
3667 =======================
3671 pragma Max_Entry_Queue (static_integer_EXPRESSION);
3674 This pragma is used to specify the maximum callers per entry queue for
3675 individual protected entries and entry families. It accepts a single
3676 positive integer as a parameter and must appear after the declaration
3690 There are a number of cases in which a package spec does not require a body,
3691 and in fact a body is not permitted. GNAT will not permit the spec to be
3692 compiled if there is a body around. The pragma No_Body allows you to provide
3693 a body file, even in a case where no body is allowed. The body file must
3694 contain only comments and a single No_Body pragma. This is recognized by
3695 the compiler as indicating that no body is logically present.
3697 This is particularly useful during maintenance when a package is modified in
3698 such a way that a body needed before is no longer needed. The provision of a
3699 dummy body with a No_Body pragma ensures that there is no interference from
3700 earlier versions of the package body.
3702 Pragma No_Component_Reordering
3703 ==============================
3710 pragma No_Component_Reordering [([Entity =>] type_LOCAL_NAME)];
3713 ``type_LOCAL_NAME`` must refer to a record type declaration in the current
3714 declarative part. The effect is to preclude any reordering of components
3715 for the layout of the record, i.e. the record is laid out by the compiler
3716 in the order in which the components are declared textually. The form with
3717 no argument is a configuration pragma which applies to all record types
3718 declared in units to which the pragma applies and there is a requirement
3719 that this pragma be used consistently within a partition.
3721 .. _Pragma-No_Elaboration_Code_All:
3723 Pragma No_Elaboration_Code_All
3724 ==============================
3731 pragma No_Elaboration_Code_All [(program_unit_NAME)];
3734 This is a program unit pragma (there is also an equivalent aspect of the
3735 same name) that establishes the restriction ``No_Elaboration_Code`` for
3736 the current unit and any extended main source units (body and subunits).
3737 It also has the effect of enforcing a transitive application of this
3738 aspect, so that if any unit is implicitly or explicitly with'ed by the
3739 current unit, it must also have the No_Elaboration_Code_All aspect set.
3740 It may be applied to package or subprogram specs or their generic versions.
3742 Pragma No_Heap_Finalization
3743 ===========================
3750 pragma No_Heap_Finalization [ (first_subtype_LOCAL_NAME) ];
3753 Pragma ``No_Heap_Finalization`` may be used as a configuration pragma or as a
3754 type-specific pragma.
3756 In its configuration form, the pragma must appear within a configuration file
3757 such as gnat.adc, without an argument. The pragma suppresses the call to
3758 ``Finalize`` for heap-allocated objects created through library-level named
3759 access-to-object types in cases where the designated type requires finalization
3762 In its type-specific form, the argument of the pragma must denote a
3763 library-level named access-to-object type. The pragma suppresses the call to
3764 ``Finalize`` for heap-allocated objects created through the specific access type
3765 in cases where the designated type requires finalization actions.
3767 It is still possible to finalize such heap-allocated objects by explicitly
3770 A library-level named access-to-object type declared within a generic unit will
3771 lose its ``No_Heap_Finalization`` pragma when the corresponding instance does not
3772 appear at the library level.
3774 .. _Pragma-No_Inline:
3784 pragma No_Inline (NAME {, NAME});
3787 This pragma suppresses inlining for the callable entity or the instances of
3788 the generic subprogram designated by ``NAME``, including inlining that
3789 results from the use of pragma ``Inline``. This pragma is always active,
3790 in particular it is not subject to the use of option *-gnatn* or
3791 *-gnatN*. It is illegal to specify both pragma ``No_Inline`` and
3792 pragma ``Inline_Always`` for the same ``NAME``.
3802 pragma No_Return (procedure_LOCAL_NAME {, procedure_LOCAL_NAME});
3805 Each ``procedure_LOCAL_NAME`` argument must refer to one or more procedure
3806 declarations in the current declarative part. A procedure to which this
3807 pragma is applied may not contain any explicit ``return`` statements.
3808 In addition, if the procedure contains any implicit returns from falling
3809 off the end of a statement sequence, then execution of that implicit
3810 return will cause Program_Error to be raised.
3812 One use of this pragma is to identify procedures whose only purpose is to raise
3813 an exception. Another use of this pragma is to suppress incorrect warnings
3814 about missing returns in functions, where the last statement of a function
3815 statement sequence is a call to such a procedure.
3817 Note that in Ada 2005 mode, this pragma is part of the language. It is
3818 available in all earlier versions of Ada as an implementation-defined
3832 This is an obsolete configuration pragma that historically was used to
3833 set up a runtime library with no object code. It is now used only for
3834 internal testing. The pragma has been superseded by the reconfigurable
3835 runtime capability of GNAT.
3837 Pragma No_Strict_Aliasing
3838 =========================
3845 pragma No_Strict_Aliasing [([Entity =>] type_LOCAL_NAME)];
3848 ``type_LOCAL_NAME`` must refer to an access type
3849 declaration in the current declarative part. The effect is to inhibit
3850 strict aliasing optimization for the given type. The form with no
3851 arguments is a configuration pragma which applies to all access types
3852 declared in units to which the pragma applies. For a detailed
3853 description of the strict aliasing optimization, and the situations
3854 in which it must be suppressed, see the section on Optimization and Strict Aliasing
3855 in the :title:`GNAT User's Guide`.
3857 This pragma currently has no effects on access to unconstrained array types.
3859 .. _Pragma-No_Tagged_Streams:
3861 Pragma No_Tagged_Streams
3862 ========================
3869 pragma No_Tagged_Streams [([Entity =>] tagged_type_LOCAL_NAME)];
3872 Normally when a tagged type is introduced using a full type declaration,
3873 part of the processing includes generating stream access routines to be
3874 used by stream attributes referencing the type (or one of its subtypes
3875 or derived types). This can involve the generation of significant amounts
3876 of code which is wasted space if stream routines are not needed for the
3879 The ``No_Tagged_Streams`` pragma causes the generation of these stream
3880 routines to be skipped, and any attempt to use stream operations on
3881 types subject to this pragma will be statically rejected as illegal.
3883 There are two forms of the pragma. The form with no arguments must appear
3884 in a declarative sequence or in the declarations of a package spec. This
3885 pragma affects all subsequent root tagged types declared in the declaration
3886 sequence, and specifies that no stream routines be generated. The form with
3887 an argument (for which there is also a corresponding aspect) specifies a
3888 single root tagged type for which stream routines are not to be generated.
3890 Once the pragma has been given for a particular root tagged type, all subtypes
3891 and derived types of this type inherit the pragma automatically, so the effect
3892 applies to a complete hierarchy (this is necessary to deal with the class-wide
3893 dispatching versions of the stream routines).
3895 When pragmas ``Discard_Names`` and ``No_Tagged_Streams`` are simultaneously
3896 applied to a tagged type its Expanded_Name and External_Tag are initialized
3897 with empty strings. This is useful to avoid exposing entity names at binary
3898 level but has a negative impact on the debuggability of tagged types.
3900 Pragma Normalize_Scalars
3901 ========================
3908 pragma Normalize_Scalars;
3911 This is a language defined pragma which is fully implemented in GNAT. The
3912 effect is to cause all scalar objects that are not otherwise initialized
3913 to be initialized. The initial values are implementation dependent and
3918 *Standard.Character*
3919 Objects whose root type is Standard.Character are initialized to
3920 Character'Last unless the subtype range excludes NUL (in which case
3921 NUL is used). This choice will always generate an invalid value if
3925 *Standard.Wide_Character*
3926 Objects whose root type is Standard.Wide_Character are initialized to
3927 Wide_Character'Last unless the subtype range excludes NUL (in which case
3928 NUL is used). This choice will always generate an invalid value if
3932 *Standard.Wide_Wide_Character*
3933 Objects whose root type is Standard.Wide_Wide_Character are initialized to
3934 the invalid value 16#FFFF_FFFF# unless the subtype range excludes NUL (in
3935 which case NUL is used). This choice will always generate an invalid value if
3940 Objects of an integer type are treated differently depending on whether
3941 negative values are present in the subtype. If no negative values are
3942 present, then all one bits is used as the initial value except in the
3943 special case where zero is excluded from the subtype, in which case
3944 all zero bits are used. This choice will always generate an invalid
3945 value if one exists.
3947 For subtypes with negative values present, the largest negative number
3948 is used, except in the unusual case where this largest negative number
3949 is in the subtype, and the largest positive number is not, in which case
3950 the largest positive value is used. This choice will always generate
3951 an invalid value if one exists.
3954 *Floating-Point Types*
3955 Objects of all floating-point types are initialized to all 1-bits. For
3956 standard IEEE format, this corresponds to a NaN (not a number) which is
3957 indeed an invalid value.
3961 Objects of all fixed-point types are treated as described above for integers,
3962 with the rules applying to the underlying integer value used to represent
3963 the fixed-point value.
3967 Objects of a modular type are initialized to all one bits, except in
3968 the special case where zero is excluded from the subtype, in which
3969 case all zero bits are used. This choice will always generate an
3970 invalid value if one exists.
3974 Objects of an enumeration type are initialized to all one-bits, i.e., to
3975 the value ``2 ** typ'Size - 1`` unless the subtype excludes the literal
3976 whose Pos value is zero, in which case a code of zero is used. This choice
3977 will always generate an invalid value if one exists.
3979 .. _Pragma_Obsolescent:
3991 pragma Obsolescent (
3992 [Message =>] static_string_EXPRESSION
3993 [,[Version =>] Ada_05]]);
3995 pragma Obsolescent (
3997 [,[Message =>] static_string_EXPRESSION
3998 [,[Version =>] Ada_05]] );
4001 This pragma can occur immediately following a declaration of an entity,
4002 including the case of a record component. If no Entity argument is present,
4003 then this declaration is the one to which the pragma applies. If an Entity
4004 parameter is present, it must either match the name of the entity in this
4005 declaration, or alternatively, the pragma can immediately follow an enumeration
4006 type declaration, where the Entity argument names one of the enumeration
4009 This pragma is used to indicate that the named entity
4010 is considered obsolescent and should not be used. Typically this is
4011 used when an API must be modified by eventually removing or modifying
4012 existing subprograms or other entities. The pragma can be used at an
4013 intermediate stage when the entity is still present, but will be
4016 The effect of this pragma is to output a warning message on a reference to
4017 an entity thus marked that the subprogram is obsolescent if the appropriate
4018 warning option in the compiler is activated. If the ``Message`` parameter is
4019 present, then a second warning message is given containing this text. In
4020 addition, a reference to the entity is considered to be a violation of pragma
4021 ``Restrictions (No_Obsolescent_Features)``.
4023 This pragma can also be used as a program unit pragma for a package,
4024 in which case the entity name is the name of the package, and the
4025 pragma indicates that the entire package is considered
4026 obsolescent. In this case a client ``with``\ ing such a package
4027 violates the restriction, and the ``with`` clause is
4028 flagged with warnings if the warning option is set.
4030 If the ``Version`` parameter is present (which must be exactly
4031 the identifier ``Ada_05``, no other argument is allowed), then the
4032 indication of obsolescence applies only when compiling in Ada 2005
4033 mode. This is primarily intended for dealing with the situations
4034 in the predefined library where subprograms or packages
4035 have become defined as obsolescent in Ada 2005
4036 (e.g., in ``Ada.Characters.Handling``), but may be used anywhere.
4038 The following examples show typical uses of this pragma:
4044 pragma Obsolescent (p, Message => "use pp instead of p");
4049 pragma Obsolescent ("use q2new instead");
4051 type R is new integer;
4054 Message => "use RR in Ada 2005",
4064 type E is (a, bc, 'd', quack);
4065 pragma Obsolescent (Entity => bc)
4066 pragma Obsolescent (Entity => 'd')
4069 (a, b : character) return character;
4070 pragma Obsolescent (Entity => "+");
4074 Note that, as for all pragmas, if you use a pragma argument identifier,
4075 then all subsequent parameters must also use a pragma argument identifier.
4076 So if you specify ``Entity =>`` for the ``Entity`` argument, and a ``Message``
4077 argument is present, it must be preceded by ``Message =>``.
4079 Pragma Optimize_Alignment
4080 =========================
4081 .. index:: Alignment, default settings
4088 pragma Optimize_Alignment (TIME | SPACE | OFF);
4091 This is a configuration pragma which affects the choice of default alignments
4092 for types and objects where no alignment is explicitly specified. There is a
4093 time/space trade-off in the selection of these values. Large alignments result
4094 in more efficient code, at the expense of larger data space, since sizes have
4095 to be increased to match these alignments. Smaller alignments save space, but
4096 the access code is slower. The normal choice of default alignments for types
4097 and individual alignment promotions for objects (which is what you get if you
4098 do not use this pragma, or if you use an argument of OFF), tries to balance
4099 these two requirements.
4101 Specifying SPACE causes smaller default alignments to be chosen in two cases.
4102 First any packed record is given an alignment of 1. Second, if a size is given
4103 for the type, then the alignment is chosen to avoid increasing this size. For
4117 In the default mode, this type gets an alignment of 4, so that access to the
4118 Integer field X are efficient. But this means that objects of the type end up
4119 with a size of 8 bytes. This is a valid choice, since sizes of objects are
4120 allowed to be bigger than the size of the type, but it can waste space if for
4121 example fields of type R appear in an enclosing record. If the above type is
4122 compiled in ``Optimize_Alignment (Space)`` mode, the alignment is set to 1.
4124 However, there is one case in which SPACE is ignored. If a variable length
4125 record (that is a discriminated record with a component which is an array
4126 whose length depends on a discriminant), has a pragma Pack, then it is not
4127 in general possible to set the alignment of such a record to one, so the
4128 pragma is ignored in this case (with a warning).
4130 Specifying SPACE also disables alignment promotions for standalone objects,
4131 which occur when the compiler increases the alignment of a specific object
4132 without changing the alignment of its type.
4134 Specifying SPACE also disables component reordering in unpacked record types,
4135 which can result in larger sizes in order to meet alignment requirements.
4137 Specifying TIME causes larger default alignments to be chosen in the case of
4138 small types with sizes that are not a power of 2. For example, consider:
4153 The default alignment for this record is normally 1, but if this type is
4154 compiled in ``Optimize_Alignment (Time)`` mode, then the alignment is set
4155 to 4, which wastes space for objects of the type, since they are now 4 bytes
4156 long, but results in more efficient access when the whole record is referenced.
4158 As noted above, this is a configuration pragma, and there is a requirement
4159 that all units in a partition be compiled with a consistent setting of the
4160 optimization setting. This would normally be achieved by use of a configuration
4161 pragma file containing the appropriate setting. The exception to this rule is
4162 that units with an explicit configuration pragma in the same file as the source
4163 unit are excluded from the consistency check, as are all predefined units. The
4164 latter are compiled by default in pragma Optimize_Alignment (Off) mode if no
4165 pragma appears at the start of the file.
4175 pragma Ordered (enumeration_first_subtype_LOCAL_NAME);
4178 Most enumeration types are from a conceptual point of view unordered.
4179 For example, consider:
4184 type Color is (Red, Blue, Green, Yellow);
4187 By Ada semantics ``Blue > Red`` and ``Green > Blue``,
4188 but really these relations make no sense; the enumeration type merely
4189 specifies a set of possible colors, and the order is unimportant.
4191 For unordered enumeration types, it is generally a good idea if
4192 clients avoid comparisons (other than equality or inequality) and
4193 explicit ranges. (A *client* is a unit where the type is referenced,
4194 other than the unit where the type is declared, its body, and its subunits.)
4195 For example, if code buried in some client says:
4200 if Current_Color < Yellow then ...
4201 if Current_Color in Blue .. Green then ...
4204 then the client code is relying on the order, which is undesirable.
4205 It makes the code hard to read and creates maintenance difficulties if
4206 entries have to be added to the enumeration type. Instead,
4207 the code in the client should list the possibilities, or an
4208 appropriate subtype should be declared in the unit that declares
4209 the original enumeration type. E.g., the following subtype could
4210 be declared along with the type ``Color``:
4215 subtype RBG is Color range Red .. Green;
4218 and then the client could write:
4223 if Current_Color in RBG then ...
4224 if Current_Color = Blue or Current_Color = Green then ...
4227 However, some enumeration types are legitimately ordered from a conceptual
4228 point of view. For example, if you declare:
4233 type Day is (Mon, Tue, Wed, Thu, Fri, Sat, Sun);
4236 then the ordering imposed by the language is reasonable, and
4237 clients can depend on it, writing for example:
4242 if D in Mon .. Fri then ...
4246 The pragma *Ordered* is provided to mark enumeration types that
4247 are conceptually ordered, alerting the reader that clients may depend
4248 on the ordering. GNAT provides a pragma to mark enumerations as ordered
4249 rather than one to mark them as unordered, since in our experience,
4250 the great majority of enumeration types are conceptually unordered.
4252 The types ``Boolean``, ``Character``, ``Wide_Character``,
4253 and ``Wide_Wide_Character``
4254 are considered to be ordered types, so each is declared with a
4255 pragma ``Ordered`` in package ``Standard``.
4257 Normally pragma ``Ordered`` serves only as documentation and a guide for
4258 coding standards, but GNAT provides a warning switch *-gnatw.u* that
4259 requests warnings for inappropriate uses (comparisons and explicit
4260 subranges) for unordered types. If this switch is used, then any
4261 enumeration type not marked with pragma ``Ordered`` will be considered
4262 as unordered, and will generate warnings for inappropriate uses.
4264 Note that generic types are not considered ordered or unordered (since the
4265 template can be instantiated for both cases), so we never generate warnings
4266 for the case of generic enumerated types.
4268 For additional information please refer to the description of the
4269 *-gnatw.u* switch in the GNAT User's Guide.
4271 Pragma Overflow_Mode
4272 ====================
4279 pragma Overflow_Mode
4281 [,[Assertions =>] MODE]);
4283 MODE ::= STRICT | MINIMIZED | ELIMINATED
4286 This pragma sets the current overflow mode to the given setting. For details
4287 of the meaning of these modes, please refer to the
4288 'Overflow Check Handling in GNAT' appendix in the
4289 GNAT User's Guide. If only the ``General`` parameter is present,
4290 the given mode applies to all expressions. If both parameters are present,
4291 the ``General`` mode applies to expressions outside assertions, and
4292 the ``Eliminated`` mode applies to expressions within assertions.
4294 The case of the ``MODE`` parameter is ignored,
4295 so ``MINIMIZED``, ``Minimized`` and
4296 ``minimized`` all have the same effect.
4298 The ``Overflow_Mode`` pragma has the same scoping and placement
4299 rules as pragma ``Suppress``, so it can occur either as a
4300 configuration pragma, specifying a default for the whole
4301 program, or in a declarative scope, where it applies to the
4302 remaining declarations and statements in that scope.
4304 The pragma ``Suppress (Overflow_Check)`` suppresses
4305 overflow checking, but does not affect the overflow mode.
4307 The pragma ``Unsuppress (Overflow_Check)`` unsuppresses (enables)
4308 overflow checking, but does not affect the overflow mode.
4310 Pragma Overriding_Renamings
4311 ===========================
4312 .. index:: Rational profile
4314 .. index:: Rational compatibility
4321 pragma Overriding_Renamings;
4324 This is a GNAT configuration pragma to simplify porting
4325 legacy code accepted by the Rational
4326 Ada compiler. In the presence of this pragma, a renaming declaration that
4327 renames an inherited operation declared in the same scope is legal if selected
4328 notation is used as in:
4333 pragma Overriding_Renamings;
4338 function F (..) renames R.F;
4343 RM 8.3 (15) stipulates that an overridden operation is not visible within the
4344 declaration of the overriding operation.
4346 Pragma Partition_Elaboration_Policy
4347 ===================================
4354 pragma Partition_Elaboration_Policy (POLICY_IDENTIFIER);
4356 POLICY_IDENTIFIER ::= Concurrent | Sequential
4359 This pragma is standard in Ada 2005, but is available in all earlier
4360 versions of Ada as an implementation-defined pragma.
4361 See Ada 2012 Reference Manual for details.
4372 pragma Part_Of (ABSTRACT_STATE);
4374 ABSTRACT_STATE ::= NAME
4376 For the semantics of this pragma, see the entry for aspect ``Part_Of`` in the
4377 SPARK 2014 Reference Manual, section 7.2.6.
4387 pragma Passive [(Semaphore | No)];
4390 Syntax checked, but otherwise ignored by GNAT. This is recognized for
4391 compatibility with DEC Ada 83 implementations, where it is used within a
4392 task definition to request that a task be made passive. If the argument
4393 ``Semaphore`` is present, or the argument is omitted, then DEC Ada 83
4394 treats the pragma as an assertion that the containing task is passive
4395 and that optimization of context switch with this task is permitted and
4396 desired. If the argument ``No`` is present, the task must not be
4397 optimized. GNAT does not attempt to optimize any tasks in this manner
4398 (since protected objects are available in place of passive tasks).
4400 For more information on the subject of passive tasks, see the section
4401 'Passive Task Optimization' in the GNAT Users Guide.
4403 .. _Pragma-Persistent_BSS:
4405 Pragma Persistent_BSS
4406 =====================
4413 pragma Persistent_BSS [(LOCAL_NAME)]
4416 This pragma allows selected objects to be placed in the ``.persistent_bss``
4417 section. On some targets the linker and loader provide for special
4418 treatment of this section, allowing a program to be reloaded without
4419 affecting the contents of this data (hence the name persistent).
4421 There are two forms of usage. If an argument is given, it must be the
4422 local name of a library-level object, with no explicit initialization
4423 and whose type is potentially persistent. If no argument is given, then
4424 the pragma is a configuration pragma, and applies to all library-level
4425 objects with no explicit initialization of potentially persistent types.
4427 A potentially persistent type is a scalar type, or an untagged,
4428 non-discriminated record, all of whose components have no explicit
4429 initialization and are themselves of a potentially persistent type,
4430 or an array, all of whose constraints are static, and whose component
4431 type is potentially persistent.
4433 If this pragma is used on a target where this feature is not supported,
4434 then the pragma will be ignored. See also ``pragma Linker_Section``.
4444 pragma Polling (ON | OFF);
4447 This pragma controls the generation of polling code. This is normally off.
4448 If ``pragma Polling (ON)`` is used then periodic calls are generated to
4449 the routine ``Ada.Exceptions.Poll``. This routine is a separate unit in the
4450 runtime library, and can be found in file :file:`a-excpol.adb`.
4452 Pragma ``Polling`` can appear as a configuration pragma (for example it
4453 can be placed in the :file:`gnat.adc` file) to enable polling globally, or it
4454 can be used in the statement or declaration sequence to control polling
4457 A call to the polling routine is generated at the start of every loop and
4458 at the start of every subprogram call. This guarantees that the ``Poll``
4459 routine is called frequently, and places an upper bound (determined by
4460 the complexity of the code) on the period between two ``Poll`` calls.
4462 The primary purpose of the polling interface is to enable asynchronous
4463 aborts on targets that cannot otherwise support it (for example Windows
4464 NT), but it may be used for any other purpose requiring periodic polling.
4465 The standard version is null, and can be replaced by a user program. This
4466 will require re-compilation of the ``Ada.Exceptions`` package that can
4467 be found in files :file:`a-except.ads` and :file:`a-except.adb`.
4469 A standard alternative unit (in file :file:`4wexcpol.adb` in the standard GNAT
4470 distribution) is used to enable the asynchronous abort capability on
4471 targets that do not normally support the capability. The version of
4472 ``Poll`` in this file makes a call to the appropriate runtime routine
4473 to test for an abort condition.
4475 Note that polling can also be enabled by use of the *-gnatP* switch.
4476 See the section on switches for gcc in the :title:`GNAT User's Guide`.
4482 .. index:: Checks, postconditions
4490 pragma Post (Boolean_Expression);
4493 The ``Post`` pragma is intended to be an exact replacement for
4494 the language-defined
4495 ``Post`` aspect, and shares its restrictions and semantics.
4496 It must appear either immediately following the corresponding
4497 subprogram declaration (only other pragmas may intervene), or
4498 if there is no separate subprogram declaration, then it can
4499 appear at the start of the declarations in a subprogram body
4500 (preceded only by other pragmas).
4502 Pragma Postcondition
4503 ====================
4504 .. index:: Postcondition
4506 .. index:: Checks, postconditions
4514 pragma Postcondition (
4515 [Check =>] Boolean_Expression
4516 [,[Message =>] String_Expression]);
4519 The ``Postcondition`` pragma allows specification of automatic
4520 postcondition checks for subprograms. These checks are similar to
4521 assertions, but are automatically inserted just prior to the return
4522 statements of the subprogram with which they are associated (including
4523 implicit returns at the end of procedure bodies and associated
4524 exception handlers).
4526 In addition, the boolean expression which is the condition which
4527 must be true may contain references to function'Result in the case
4528 of a function to refer to the returned value.
4530 ``Postcondition`` pragmas may appear either immediately following the
4531 (separate) declaration of a subprogram, or at the start of the
4532 declarations of a subprogram body. Only other pragmas may intervene
4533 (that is appear between the subprogram declaration and its
4534 postconditions, or appear before the postcondition in the
4535 declaration sequence in a subprogram body). In the case of a
4536 postcondition appearing after a subprogram declaration, the
4537 formal arguments of the subprogram are visible, and can be
4538 referenced in the postcondition expressions.
4540 The postconditions are collected and automatically tested just
4541 before any return (implicit or explicit) in the subprogram body.
4542 A postcondition is only recognized if postconditions are active
4543 at the time the pragma is encountered. The compiler switch *gnata*
4544 turns on all postconditions by default, and pragma ``Check_Policy``
4545 with an identifier of ``Postcondition`` can also be used to
4546 control whether postconditions are active.
4548 The general approach is that postconditions are placed in the spec
4549 if they represent functional aspects which make sense to the client.
4550 For example we might have:
4555 function Direction return Integer;
4556 pragma Postcondition
4557 (Direction'Result = +1
4559 Direction'Result = -1);
4562 which serves to document that the result must be +1 or -1, and
4563 will test that this is the case at run time if postcondition
4566 Postconditions within the subprogram body can be used to
4567 check that some internal aspect of the implementation,
4568 not visible to the client, is operating as expected.
4569 For instance if a square root routine keeps an internal
4570 counter of the number of times it is called, then we
4571 might have the following postcondition:
4576 Sqrt_Calls : Natural := 0;
4578 function Sqrt (Arg : Float) return Float is
4579 pragma Postcondition
4580 (Sqrt_Calls = Sqrt_Calls'Old + 1);
4585 As this example, shows, the use of the ``Old`` attribute
4586 is often useful in postconditions to refer to the state on
4587 entry to the subprogram.
4589 Note that postconditions are only checked on normal returns
4590 from the subprogram. If an abnormal return results from
4591 raising an exception, then the postconditions are not checked.
4593 If a postcondition fails, then the exception
4594 ``System.Assertions.Assert_Failure`` is raised. If
4595 a message argument was supplied, then the given string
4596 will be used as the exception message. If no message
4597 argument was supplied, then the default message has
4598 the form "Postcondition failed at file_name:line". The
4599 exception is raised in the context of the subprogram
4600 body, so it is possible to catch postcondition failures
4601 within the subprogram body itself.
4603 Within a package spec, normal visibility rules
4604 in Ada would prevent forward references within a
4605 postcondition pragma to functions defined later in
4606 the same package. This would introduce undesirable
4607 ordering constraints. To avoid this problem, all
4608 postcondition pragmas are analyzed at the end of
4609 the package spec, allowing forward references.
4611 The following example shows that this even allows
4612 mutually recursive postconditions as in:
4617 package Parity_Functions is
4618 function Odd (X : Natural) return Boolean;
4619 pragma Postcondition
4623 (x /= 0 and then Even (X - 1))));
4625 function Even (X : Natural) return Boolean;
4626 pragma Postcondition
4630 (x /= 1 and then Odd (X - 1))));
4632 end Parity_Functions;
4635 There are no restrictions on the complexity or form of
4636 conditions used within ``Postcondition`` pragmas.
4637 The following example shows that it is even possible
4638 to verify performance behavior.
4645 Performance : constant Float;
4646 -- Performance constant set by implementation
4647 -- to match target architecture behavior.
4649 procedure Treesort (Arg : String);
4650 -- Sorts characters of argument using N*logN sort
4651 pragma Postcondition
4652 (Float (Clock - Clock'Old) <=
4653 Float (Arg'Length) *
4654 log (Float (Arg'Length)) *
4659 Note: postcondition pragmas associated with subprograms that are
4660 marked as Inline_Always, or those marked as Inline with front-end
4661 inlining (-gnatN option set) are accepted and legality-checked
4662 by the compiler, but are ignored at run-time even if postcondition
4663 checking is enabled.
4665 Note that pragma ``Postcondition`` differs from the language-defined
4666 ``Post`` aspect (and corresponding ``Post`` pragma) in allowing
4667 multiple occurrences, allowing occurences in the body even if there
4668 is a separate spec, and allowing a second string parameter, and the
4669 use of the pragma identifier ``Check``. Historically, pragma
4670 ``Postcondition`` was implemented prior to the development of
4671 Ada 2012, and has been retained in its original form for
4672 compatibility purposes.
4678 .. index:: Checks, postconditions
4686 pragma Post_Class (Boolean_Expression);
4689 The ``Post_Class`` pragma is intended to be an exact replacement for
4690 the language-defined
4691 ``Post'Class`` aspect, and shares its restrictions and semantics.
4692 It must appear either immediately following the corresponding
4693 subprogram declaration (only other pragmas may intervene), or
4694 if there is no separate subprogram declaration, then it can
4695 appear at the start of the declarations in a subprogram body
4696 (preceded only by other pragmas).
4698 Note: This pragma is called ``Post_Class`` rather than
4699 ``Post'Class`` because the latter would not be strictly
4700 conforming to the allowed syntax for pragmas. The motivation
4701 for provinding pragmas equivalent to the aspects is to allow a program
4702 to be written using the pragmas, and then compiled if necessary
4703 using an Ada compiler that does not recognize the pragmas or
4704 aspects, but is prepared to ignore the pragmas. The assertion
4705 policy that controls this pragma is ``Post'Class``, not
4708 Pragma Rename_Pragma
4709 ============================
4710 .. index:: Pragmas, synonyms
4717 pragma Rename_Pragma (
4718 [New_Name =>] IDENTIFIER,
4719 [Renamed =>] pragma_IDENTIFIER);
4721 This pragma provides a mechanism for supplying new names for existing
4722 pragmas. The ``New_Name`` identifier can subsequently be used as a synonym for
4723 the Renamed pragma. For example, suppose you have code that was originally
4724 developed on a compiler that supports Inline_Only as an implementation defined
4725 pragma. And suppose the semantics of pragma Inline_Only are identical to (or at
4726 least very similar to) the GNAT implementation defined pragma
4727 Inline_Always. You could globally replace Inline_Only with Inline_Always.
4729 However, to avoid that source modification, you could instead add a
4730 configuration pragma:
4734 pragma Rename_Pragma (
4735 New_Name => Inline_Only,
4736 Renamed => Inline_Always);
4739 Then GNAT will treat "pragma Inline_Only ..." as if you had written
4740 "pragma Inline_Always ...".
4742 Pragma Inline_Only will not necessarily mean the same thing as the other Ada
4743 compiler; it's up to you to make sure the semantics are close enough.
4749 .. index:: Checks, preconditions
4757 pragma Pre (Boolean_Expression);
4760 The ``Pre`` pragma is intended to be an exact replacement for
4761 the language-defined
4762 ``Pre`` aspect, and shares its restrictions and semantics.
4763 It must appear either immediately following the corresponding
4764 subprogram declaration (only other pragmas may intervene), or
4765 if there is no separate subprogram declaration, then it can
4766 appear at the start of the declarations in a subprogram body
4767 (preceded only by other pragmas).
4771 .. index:: Preconditions
4773 .. index:: Checks, preconditions
4781 pragma Precondition (
4782 [Check =>] Boolean_Expression
4783 [,[Message =>] String_Expression]);
4786 The ``Precondition`` pragma is similar to ``Postcondition``
4787 except that the corresponding checks take place immediately upon
4788 entry to the subprogram, and if a precondition fails, the exception
4789 is raised in the context of the caller, and the attribute 'Result
4790 cannot be used within the precondition expression.
4792 Otherwise, the placement and visibility rules are identical to those
4793 described for postconditions. The following is an example of use
4794 within a package spec:
4799 package Math_Functions is
4801 function Sqrt (Arg : Float) return Float;
4802 pragma Precondition (Arg >= 0.0)
4807 ``Precondition`` pragmas may appear either immediately following the
4808 (separate) declaration of a subprogram, or at the start of the
4809 declarations of a subprogram body. Only other pragmas may intervene
4810 (that is appear between the subprogram declaration and its
4811 postconditions, or appear before the postcondition in the
4812 declaration sequence in a subprogram body).
4814 Note: precondition pragmas associated with subprograms that are
4815 marked as Inline_Always, or those marked as Inline with front-end
4816 inlining (-gnatN option set) are accepted and legality-checked
4817 by the compiler, but are ignored at run-time even if precondition
4818 checking is enabled.
4820 Note that pragma ``Precondition`` differs from the language-defined
4821 ``Pre`` aspect (and corresponding ``Pre`` pragma) in allowing
4822 multiple occurrences, allowing occurences in the body even if there
4823 is a separate spec, and allowing a second string parameter, and the
4824 use of the pragma identifier ``Check``. Historically, pragma
4825 ``Precondition`` was implemented prior to the development of
4826 Ada 2012, and has been retained in its original form for
4827 compatibility purposes.
4829 .. _Pragma-Predicate:
4840 ([Entity =>] type_LOCAL_NAME,
4841 [Check =>] EXPRESSION);
4844 This pragma (available in all versions of Ada in GNAT) encompasses both
4845 the ``Static_Predicate`` and ``Dynamic_Predicate`` aspects in
4846 Ada 2012. A predicate is regarded as static if it has an allowed form
4847 for ``Static_Predicate`` and is otherwise treated as a
4848 ``Dynamic_Predicate``. Otherwise, predicates specified by this
4849 pragma behave exactly as described in the Ada 2012 reference manual.
4850 For example, if we have
4855 type R is range 1 .. 10;
4857 pragma Predicate (Entity => S, Check => S not in 4 .. 6);
4859 pragma Predicate (Entity => Q, Check => F(Q) or G(Q));
4862 the effect is identical to the following Ada 2012 code:
4867 type R is range 1 .. 10;
4869 Static_Predicate => S not in 4 .. 6;
4871 Dynamic_Predicate => F(Q) or G(Q);
4874 Note that there are no pragmas ``Dynamic_Predicate``
4875 or ``Static_Predicate``. That is
4876 because these pragmas would affect legality and semantics of
4877 the program and thus do not have a neutral effect if ignored.
4878 The motivation behind providing pragmas equivalent to
4879 corresponding aspects is to allow a program to be written
4880 using the pragmas, and then compiled with a compiler that
4881 will ignore the pragmas. That doesn't work in the case of
4882 static and dynamic predicates, since if the corresponding
4883 pragmas are ignored, then the behavior of the program is
4884 fundamentally changed (for example a membership test
4885 ``A in B`` would not take into account a predicate
4886 defined for subtype B). When following this approach, the
4887 use of predicates should be avoided.
4889 Pragma Predicate_Failure
4890 ========================
4897 pragma Predicate_Failure
4898 ([Entity =>] type_LOCAL_NAME,
4899 [Message =>] String_Expression);
4902 The ``Predicate_Failure`` pragma is intended to be an exact replacement for
4903 the language-defined
4904 ``Predicate_Failure`` aspect, and shares its restrictions and semantics.
4906 Pragma Preelaborable_Initialization
4907 ===================================
4914 pragma Preelaborable_Initialization (DIRECT_NAME);
4917 This pragma is standard in Ada 2005, but is available in all earlier
4918 versions of Ada as an implementation-defined pragma.
4919 See Ada 2012 Reference Manual for details.
4921 Pragma Prefix_Exception_Messages
4922 ================================
4923 .. index:: Prefix_Exception_Messages
4925 .. index:: exception
4927 .. index:: Exception_Message
4935 pragma Prefix_Exception_Messages;
4938 This is an implementation-defined configuration pragma that affects the
4939 behavior of raise statements with a message given as a static string
4940 constant (typically a string literal). In such cases, the string will
4941 be automatically prefixed by the name of the enclosing entity (giving
4942 the package and subprogram containing the raise statement). This helps
4943 to identify where messages are coming from, and this mode is automatic
4944 for the run-time library.
4946 The pragma has no effect if the message is computed with an expression other
4947 than a static string constant, since the assumption in this case is that
4948 the program computes exactly the string it wants. If you still want the
4949 prefixing in this case, you can always call
4950 ``GNAT.Source_Info.Enclosing_Entity`` and prepend the string manually.
4954 .. index:: Pre_Class
4956 .. index:: Checks, preconditions
4964 pragma Pre_Class (Boolean_Expression);
4967 The ``Pre_Class`` pragma is intended to be an exact replacement for
4968 the language-defined
4969 ``Pre'Class`` aspect, and shares its restrictions and semantics.
4970 It must appear either immediately following the corresponding
4971 subprogram declaration (only other pragmas may intervene), or
4972 if there is no separate subprogram declaration, then it can
4973 appear at the start of the declarations in a subprogram body
4974 (preceded only by other pragmas).
4976 Note: This pragma is called ``Pre_Class`` rather than
4977 ``Pre'Class`` because the latter would not be strictly
4978 conforming to the allowed syntax for pragmas. The motivation
4979 for providing pragmas equivalent to the aspects is to allow a program
4980 to be written using the pragmas, and then compiled if necessary
4981 using an Ada compiler that does not recognize the pragmas or
4982 aspects, but is prepared to ignore the pragmas. The assertion
4983 policy that controls this pragma is ``Pre'Class``, not
4986 Pragma Priority_Specific_Dispatching
4987 ====================================
4994 pragma Priority_Specific_Dispatching (
4996 first_priority_EXPRESSION,
4997 last_priority_EXPRESSION)
4999 POLICY_IDENTIFIER ::=
5000 EDF_Across_Priorities |
5001 FIFO_Within_Priorities |
5002 Non_Preemptive_Within_Priorities |
5003 Round_Robin_Within_Priorities
5006 This pragma is standard in Ada 2005, but is available in all earlier
5007 versions of Ada as an implementation-defined pragma.
5008 See Ada 2012 Reference Manual for details.
5018 pragma Profile (Ravenscar | Restricted | Rational |
5019 GNAT_Extended_Ravenscar | GNAT_Ravenscar_EDF );
5022 This pragma is standard in Ada 2005, but is available in all earlier
5023 versions of Ada as an implementation-defined pragma. This is a
5024 configuration pragma that establishes a set of configuration pragmas
5025 that depend on the argument. ``Ravenscar`` is standard in Ada 2005.
5026 The other possibilities (``Restricted``, ``Rational``,
5027 ``GNAT_Extended_Ravenscar``, ``GNAT_Ravenscar_EDF``)
5028 are implementation-defined. The set of configuration pragmas
5029 is defined in the following sections.
5032 * Pragma Profile (Ravenscar)
5034 The ``Ravenscar`` profile is standard in Ada 2005,
5035 but is available in all earlier
5036 versions of Ada as an implementation-defined pragma. This profile
5037 establishes the following set of configuration pragmas:
5039 * ``Task_Dispatching_Policy (FIFO_Within_Priorities)``
5041 [RM D.2.2] Tasks are dispatched following a preemptive
5042 priority-ordered scheduling policy.
5045 * ``Locking_Policy (Ceiling_Locking)``
5047 [RM D.3] While tasks and interrupts execute a protected action, they inherit
5048 the ceiling priority of the corresponding protected object.
5051 * ``Detect_Blocking``
5053 This pragma forces the detection of potentially blocking operations within a
5054 protected operation, and to raise Program_Error if that happens.
5056 plus the following set of restrictions:
5058 * ``Max_Entry_Queue_Length => 1``
5060 No task can be queued on a protected entry.
5062 * ``Max_Protected_Entries => 1``
5064 * ``Max_Task_Entries => 0``
5066 No rendezvous statements are allowed.
5068 * ``No_Abort_Statements``
5070 * ``No_Dynamic_Attachment``
5072 * ``No_Dynamic_Priorities``
5074 * ``No_Implicit_Heap_Allocations``
5076 * ``No_Local_Protected_Objects``
5078 * ``No_Local_Timing_Events``
5080 * ``No_Protected_Type_Allocators``
5082 * ``No_Relative_Delay``
5084 * ``No_Requeue_Statements``
5086 * ``No_Select_Statements``
5088 * ``No_Specific_Termination_Handlers``
5090 * ``No_Task_Allocators``
5092 * ``No_Task_Hierarchy``
5094 * ``No_Task_Termination``
5096 * ``Simple_Barriers``
5098 The Ravenscar profile also includes the following restrictions that specify
5099 that there are no semantic dependences on the corresponding predefined
5102 * ``No_Dependence => Ada.Asynchronous_Task_Control``
5104 * ``No_Dependence => Ada.Calendar``
5106 * ``No_Dependence => Ada.Execution_Time.Group_Budget``
5108 * ``No_Dependence => Ada.Execution_Time.Timers``
5110 * ``No_Dependence => Ada.Task_Attributes``
5112 * ``No_Dependence => System.Multiprocessors.Dispatching_Domains``
5114 This set of configuration pragmas and restrictions correspond to the
5115 definition of the 'Ravenscar Profile' for limited tasking, devised and
5116 published by the :title:`International Real-Time Ada Workshop, 1997`.
5117 A description is also available at
5118 `http://www-users.cs.york.ac.uk/~burns/ravenscar.ps <http://www-users.cs.york.ac.uk/~burns/ravenscar.ps>`_.
5120 The original definition of the profile was revised at subsequent IRTAW
5121 meetings. It has been included in the ISO
5122 :title:`Guide for the Use of the Ada Programming Language in High Integrity Systems`,
5123 and was made part of the Ada 2005 standard.
5124 The formal definition given by
5125 the Ada Rapporteur Group (ARG) can be found in two Ada Issues (AI-249 and
5126 AI-305) available at
5127 `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
5128 `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>`_.
5130 The above set is a superset of the restrictions provided by pragma
5131 ``Profile (Restricted)``, it includes six additional restrictions
5132 (``Simple_Barriers``, ``No_Select_Statements``,
5133 ``No_Calendar``, ``No_Implicit_Heap_Allocations``,
5134 ``No_Relative_Delay`` and ``No_Task_Termination``). This means
5135 that pragma ``Profile (Ravenscar)``, like the pragma
5136 ``Profile (Restricted)``,
5137 automatically causes the use of a simplified,
5138 more efficient version of the tasking run-time library.
5140 * Pragma Profile (GNAT_Extended_Ravenscar)
5142 This profile corresponds to a GNAT specific extension of the
5143 Ravenscar profile. The profile may change in the future although
5144 only in a compatible way: some restrictions may be removed or
5145 relaxed. It is defined as a variation of the Ravenscar profile.
5147 The ``No_Implicit_Heap_Allocations`` restriction has been replaced
5148 by ``No_Implicit_Task_Allocations`` and
5149 ``No_Implicit_Protected_Object_Allocations``.
5151 The ``Simple_Barriers`` restriction has been replaced by
5154 The ``Max_Protected_Entries``, ``Max_Entry_Queue_Length``, and
5155 ``No_Relative_Delay`` restrictions have been removed.
5157 * Pragma Profile (GNAT_Ravenscar_EDF)
5159 This profile corresponds to the Ravenscar profile but using
5160 EDF_Across_Priority as the Task_Scheduling_Policy.
5162 * Pragma Profile (Restricted)
5164 This profile corresponds to the GNAT restricted run time. It
5165 establishes the following set of restrictions:
5167 * ``No_Abort_Statements``
5168 * ``No_Entry_Queue``
5169 * ``No_Task_Hierarchy``
5170 * ``No_Task_Allocators``
5171 * ``No_Dynamic_Priorities``
5172 * ``No_Terminate_Alternatives``
5173 * ``No_Dynamic_Attachment``
5174 * ``No_Protected_Type_Allocators``
5175 * ``No_Local_Protected_Objects``
5176 * ``No_Requeue_Statements``
5177 * ``No_Task_Attributes_Package``
5178 * ``Max_Asynchronous_Select_Nesting = 0``
5179 * ``Max_Task_Entries = 0``
5180 * ``Max_Protected_Entries = 1``
5181 * ``Max_Select_Alternatives = 0``
5183 This set of restrictions causes the automatic selection of a simplified
5184 version of the run time that provides improved performance for the
5185 limited set of tasking functionality permitted by this set of restrictions.
5187 * Pragma Profile (Rational)
5189 The Rational profile is intended to facilitate porting legacy code that
5190 compiles with the Rational APEX compiler, even when the code includes non-
5191 conforming Ada constructs. The profile enables the following three pragmas:
5193 * ``pragma Implicit_Packing``
5194 * ``pragma Overriding_Renamings``
5195 * ``pragma Use_VADS_Size``
5198 Pragma Profile_Warnings
5199 =======================
5206 pragma Profile_Warnings (Ravenscar | Restricted | Rational);
5209 This is an implementation-defined pragma that is similar in
5210 effect to ``pragma Profile`` except that instead of
5211 generating ``Restrictions`` pragmas, it generates
5212 ``Restriction_Warnings`` pragmas. The result is that
5213 violations of the profile generate warning messages instead
5216 Pragma Propagate_Exceptions
5217 ===========================
5218 .. index:: Interfacing to C++
5226 pragma Propagate_Exceptions;
5229 This pragma is now obsolete and, other than generating a warning if warnings
5230 on obsolescent features are enabled, is ignored.
5231 It is retained for compatibility
5232 purposes. It used to be used in connection with optimization of
5233 a now-obsolete mechanism for implementation of exceptions.
5235 Pragma Provide_Shift_Operators
5236 ==============================
5237 .. index:: Shift operators
5245 pragma Provide_Shift_Operators (integer_first_subtype_LOCAL_NAME);
5248 This pragma can be applied to a first subtype local name that specifies
5249 either an unsigned or signed type. It has the effect of providing the
5250 five shift operators (Shift_Left, Shift_Right, Shift_Right_Arithmetic,
5251 Rotate_Left and Rotate_Right) for the given type. It is similar to
5252 including the function declarations for these five operators, together
5253 with the pragma Import (Intrinsic, ...) statements.
5263 pragma Psect_Object (
5264 [Internal =>] LOCAL_NAME,
5265 [, [External =>] EXTERNAL_SYMBOL]
5266 [, [Size =>] EXTERNAL_SYMBOL]);
5270 | static_string_EXPRESSION
5273 This pragma is identical in effect to pragma ``Common_Object``.
5275 .. _Pragma-Pure_Function:
5277 Pragma Pure_Function
5278 ====================
5285 pragma Pure_Function ([Entity =>] function_LOCAL_NAME);
5288 This pragma appears in the same declarative part as a function
5289 declaration (or a set of function declarations if more than one
5290 overloaded declaration exists, in which case the pragma applies
5291 to all entities). It specifies that the function ``Entity`` is
5292 to be considered pure for the purposes of code generation. This means
5293 that the compiler can assume that there are no side effects, and
5294 in particular that two calls with identical arguments produce the
5295 same result. It also means that the function can be used in an
5298 Note that, quite deliberately, there are no static checks to try
5299 to ensure that this promise is met, so ``Pure_Function`` can be used
5300 with functions that are conceptually pure, even if they do modify
5301 global variables. For example, a square root function that is
5302 instrumented to count the number of times it is called is still
5303 conceptually pure, and can still be optimized, even though it
5304 modifies a global variable (the count). Memo functions are another
5305 example (where a table of previous calls is kept and consulted to
5306 avoid re-computation).
5308 Note also that the normal rules excluding optimization of subprograms
5309 in pure units (when parameter types are descended from System.Address,
5310 or when the full view of a parameter type is limited), do not apply
5311 for the Pure_Function case. If you explicitly specify Pure_Function,
5312 the compiler may optimize away calls with identical arguments, and
5313 if that results in unexpected behavior, the proper action is not to
5314 use the pragma for subprograms that are not (conceptually) pure.
5316 Note: Most functions in a ``Pure`` package are automatically pure, and
5317 there is no need to use pragma ``Pure_Function`` for such functions. One
5318 exception is any function that has at least one formal of type
5319 ``System.Address`` or a type derived from it. Such functions are not
5320 considered pure by default, since the compiler assumes that the
5321 ``Address`` parameter may be functioning as a pointer and that the
5322 referenced data may change even if the address value does not.
5323 Similarly, imported functions are not considered to be pure by default,
5324 since there is no way of checking that they are in fact pure. The use
5325 of pragma ``Pure_Function`` for such a function will override these default
5326 assumption, and cause the compiler to treat a designated subprogram as pure
5329 Note: If pragma ``Pure_Function`` is applied to a renamed function, it
5330 applies to the underlying renamed function. This can be used to
5331 disambiguate cases of overloading where some but not all functions
5332 in a set of overloaded functions are to be designated as pure.
5334 If pragma ``Pure_Function`` is applied to a library-level function, the
5335 function is also considered pure from an optimization point of view, but the
5336 unit is not a Pure unit in the categorization sense. So for example, a function
5337 thus marked is free to ``with`` non-pure units.
5350 This pragma is considered obsolescent, but is retained for
5351 compatibility purposes. It is equivalent to:
5356 pragma Profile (Rational);
5370 This pragma is considered obsolescent, but is retained for
5371 compatibility purposes. It is equivalent to:
5376 pragma Profile (Ravenscar);
5379 which is the preferred method of setting the ``Ravenscar`` profile.
5381 .. _Pragma-Refined_Depends:
5383 Pragma Refined_Depends
5384 ======================
5390 pragma Refined_Depends (DEPENDENCY_RELATION);
5392 DEPENDENCY_RELATION ::=
5394 | (DEPENDENCY_CLAUSE {, DEPENDENCY_CLAUSE})
5396 DEPENDENCY_CLAUSE ::=
5397 OUTPUT_LIST =>[+] INPUT_LIST
5398 | NULL_DEPENDENCY_CLAUSE
5400 NULL_DEPENDENCY_CLAUSE ::= null => INPUT_LIST
5402 OUTPUT_LIST ::= OUTPUT | (OUTPUT {, OUTPUT})
5404 INPUT_LIST ::= null | INPUT | (INPUT {, INPUT})
5406 OUTPUT ::= NAME | FUNCTION_RESULT
5409 where FUNCTION_RESULT is a function Result attribute_reference
5411 For the semantics of this pragma, see the entry for aspect ``Refined_Depends`` in
5412 the SPARK 2014 Reference Manual, section 6.1.5.
5414 .. _Pragma-Refined_Global:
5416 Pragma Refined_Global
5417 =====================
5423 pragma Refined_Global (GLOBAL_SPECIFICATION);
5425 GLOBAL_SPECIFICATION ::=
5428 | (MODED_GLOBAL_LIST {, MODED_GLOBAL_LIST})
5430 MODED_GLOBAL_LIST ::= MODE_SELECTOR => GLOBAL_LIST
5432 MODE_SELECTOR ::= In_Out | Input | Output | Proof_In
5433 GLOBAL_LIST ::= GLOBAL_ITEM | (GLOBAL_ITEM {, GLOBAL_ITEM})
5434 GLOBAL_ITEM ::= NAME
5436 For the semantics of this pragma, see the entry for aspect ``Refined_Global`` in
5437 the SPARK 2014 Reference Manual, section 6.1.4.
5439 .. _Pragma-Refined_Post:
5448 pragma Refined_Post (boolean_EXPRESSION);
5450 For the semantics of this pragma, see the entry for aspect ``Refined_Post`` in
5451 the SPARK 2014 Reference Manual, section 7.2.7.
5453 .. _Pragma-Refined_State:
5455 Pragma Refined_State
5456 ====================
5462 pragma Refined_State (REFINEMENT_LIST);
5465 (REFINEMENT_CLAUSE {, REFINEMENT_CLAUSE})
5467 REFINEMENT_CLAUSE ::= state_NAME => CONSTITUENT_LIST
5469 CONSTITUENT_LIST ::=
5472 | (CONSTITUENT {, CONSTITUENT})
5474 CONSTITUENT ::= object_NAME | state_NAME
5476 For the semantics of this pragma, see the entry for aspect ``Refined_State`` in
5477 the SPARK 2014 Reference Manual, section 7.2.2.
5479 Pragma Relative_Deadline
5480 ========================
5487 pragma Relative_Deadline (time_span_EXPRESSION);
5490 This pragma is standard in Ada 2005, but is available in all earlier
5491 versions of Ada as an implementation-defined pragma.
5492 See Ada 2012 Reference Manual for details.
5494 .. _Pragma-Remote_Access_Type:
5496 Pragma Remote_Access_Type
5497 =========================
5504 pragma Remote_Access_Type ([Entity =>] formal_access_type_LOCAL_NAME);
5507 This pragma appears in the formal part of a generic declaration.
5508 It specifies an exception to the RM rule from E.2.2(17/2), which forbids
5509 the use of a remote access to class-wide type as actual for a formal
5512 When this pragma applies to a formal access type ``Entity``, that
5513 type is treated as a remote access to class-wide type in the generic.
5514 It must be a formal general access type, and its designated type must
5515 be the class-wide type of a formal tagged limited private type from the
5516 same generic declaration.
5518 In the generic unit, the formal type is subject to all restrictions
5519 pertaining to remote access to class-wide types. At instantiation, the
5520 actual type must be a remote access to class-wide type.
5522 Pragma Restricted_Run_Time
5523 ==========================
5530 pragma Restricted_Run_Time;
5533 This pragma is considered obsolescent, but is retained for
5534 compatibility purposes. It is equivalent to:
5539 pragma Profile (Restricted);
5542 which is the preferred method of setting the restricted run time
5545 Pragma Restriction_Warnings
5546 ===========================
5553 pragma Restriction_Warnings
5554 (restriction_IDENTIFIER {, restriction_IDENTIFIER});
5557 This pragma allows a series of restriction identifiers to be
5558 specified (the list of allowed identifiers is the same as for
5559 pragma ``Restrictions``). For each of these identifiers
5560 the compiler checks for violations of the restriction, but
5561 generates a warning message rather than an error message
5562 if the restriction is violated.
5564 One use of this is in situations where you want to know
5565 about violations of a restriction, but you want to ignore some of
5566 these violations. Consider this example, where you want to set
5567 Ada_95 mode and enable style checks, but you want to know about
5568 any other use of implementation pragmas:
5573 pragma Restriction_Warnings (No_Implementation_Pragmas);
5574 pragma Warnings (Off, "violation of No_Implementation_Pragmas");
5576 pragma Style_Checks ("2bfhkM160");
5577 pragma Warnings (On, "violation of No_Implementation_Pragmas");
5580 By including the above lines in a configuration pragmas file,
5581 the Ada_95 and Style_Checks pragmas are accepted without
5582 generating a warning, but any other use of implementation
5583 defined pragmas will cause a warning to be generated.
5596 This pragma is an RM-defined standard pragma, but has no effect on the
5597 program being compiled, or on the code generated for the program.
5599 To obtain the required output specified in RM H.3.1, the compiler must be
5600 run with various special switches as follows:
5602 * *Where compiler-generated run-time checks remain*
5604 The switch *-gnatGL*
5605 may be used to list the expanded code in pseudo-Ada form.
5606 Runtime checks show up in the listing either as explicit
5607 checks or operators marked with {} to indicate a check is present.
5610 * *An identification of known exceptions at compile time*
5612 If the program is compiled with *-gnatwa*,
5613 the compiler warning messages will indicate all cases where the compiler
5614 detects that an exception is certain to occur at run time.
5617 * *Possible reads of uninitialized variables*
5619 The compiler warns of many such cases, but its output is incomplete.
5621 .. only:: PRO or GPL
5623 The CodePeer analysis tool
5624 may be used to obtain a comprehensive list of all
5625 possible points at which uninitialized data may be read.
5629 A supplemental static analysis tool
5630 may be used to obtain a comprehensive list of all
5631 possible points at which uninitialized data may be read.
5634 * *Where run-time support routines are implicitly invoked*
5636 In the output from *-gnatGL*,
5637 run-time calls are explicitly listed as calls to the relevant
5641 * *Object code listing*
5643 This may be obtained either by using the *-S* switch,
5644 or the objdump utility.
5647 * *Constructs known to be erroneous at compile time*
5649 These are identified by warnings issued by the compiler (use *-gnatwa*).
5652 * *Stack usage information*
5654 Static stack usage data (maximum per-subprogram) can be obtained via the
5655 *-fstack-usage* switch to the compiler.
5656 Dynamic stack usage data (per task) can be obtained via the *-u* switch
5659 .. only:: PRO or GPL
5661 The gnatstack utility
5662 can be used to provide additional information on stack usage.
5665 * *Object code listing of entire partition*
5667 This can be obtained by compiling the partition with *-S*,
5668 or by applying objdump
5669 to all the object files that are part of the partition.
5672 * *A description of the run-time model*
5674 The full sources of the run-time are available, and the documentation of
5675 these routines describes how these run-time routines interface to the
5676 underlying operating system facilities.
5679 * *Control and data-flow information*
5681 .. only:: PRO or GPL
5684 may be used to obtain complete control and data-flow information, as well as
5685 comprehensive messages identifying possible problems based on this
5690 A supplemental static analysis tool
5691 may be used to obtain complete control and data-flow information, as well as
5692 comprehensive messages identifying possible problems based on this
5695 .. _Pragma-Secondary_Stack_Size:
5697 Pragma Secondary_Stack_Size
5698 ===========================
5704 pragma Secondary_Stack_Size (integer_EXPRESSION);
5706 This pragma appears within the task definition of a single task declaration
5707 or a task type declaration (like pragma ``Storage_Size``) and applies to all
5708 task objects of that type. The argument specifies the size of the secondary
5709 stack to be used by these task objects, and must be of an integer type. The
5710 secondary stack is used to handle functions that return a variable-sized
5711 result, for example a function returning an unconstrained String.
5713 Note this pragma only applies to targets using fixed secondary stacks, like
5714 VxWorks 653 and bare board targets, where a fixed block for the
5715 secondary stack is allocated from the primary stack of the task. By default,
5716 these targets assign a percentage of the primary stack for the secondary stack,
5717 as defined by ``System.Parameter.Sec_Stack_Percentage``. With this pragma,
5718 an ``integer_EXPRESSION`` of bytes is assigned from the primary stack instead.
5720 For most targets, the pragma does not apply as the secondary stack grows on
5721 demand: allocated as a chain of blocks in the heap. The default size of these
5722 blocks can be modified via the :switch:`-D` binder option as described in
5723 :title:`GNAT User's Guide`.
5725 Note that no check is made to see if the secondary stack can fit inside the
5728 Note the pragma cannot appear when the restriction ``No_Secondary_Stack``
5731 Pragma Share_Generic
5732 ====================
5739 pragma Share_Generic (GNAME {, GNAME});
5741 GNAME ::= generic_unit_NAME | generic_instance_NAME
5744 This pragma is provided for compatibility with Dec Ada 83. It has
5745 no effect in GNAT (which does not implement shared generics), other
5746 than to check that the given names are all names of generic units or
5754 This pragma is provided for compatibility with Ada 83. The syntax and
5755 semantics are identical to pragma Atomic.
5757 Pragma Short_Circuit_And_Or
5758 ===========================
5765 pragma Short_Circuit_And_Or;
5768 This configuration pragma causes any occurrence of the AND operator applied to
5769 operands of type Standard.Boolean to be short-circuited (i.e. the AND operator
5770 is treated as if it were AND THEN). Or is similarly treated as OR ELSE. This
5771 may be useful in the context of certification protocols requiring the use of
5772 short-circuited logical operators. If this configuration pragma occurs locally
5773 within the file being compiled, it applies only to the file being compiled.
5774 There is no requirement that all units in a partition use this option.
5776 Pragma Short_Descriptors
5777 ========================
5784 pragma Short_Descriptors
5787 This pragma is provided for compatibility with other Ada implementations. It
5788 is recognized but ignored by all current versions of GNAT.
5790 .. _Pragma-Simple_Storage_Pool_Type:
5792 Pragma Simple_Storage_Pool_Type
5793 ===============================
5794 .. index:: Storage pool, simple
5796 .. index:: Simple storage pool
5803 pragma Simple_Storage_Pool_Type (type_LOCAL_NAME);
5806 A type can be established as a 'simple storage pool type' by applying
5807 the representation pragma ``Simple_Storage_Pool_Type`` to the type.
5808 A type named in the pragma must be a library-level immutably limited record
5809 type or limited tagged type declared immediately within a package declaration.
5810 The type can also be a limited private type whose full type is allowed as
5811 a simple storage pool type.
5813 For a simple storage pool type ``SSP``, nonabstract primitive subprograms
5814 ``Allocate``, ``Deallocate``, and ``Storage_Size`` can be declared that
5815 are subtype conformant with the following subprogram declarations:
5822 Storage_Address : out System.Address;
5823 Size_In_Storage_Elements : System.Storage_Elements.Storage_Count;
5824 Alignment : System.Storage_Elements.Storage_Count);
5826 procedure Deallocate
5828 Storage_Address : System.Address;
5829 Size_In_Storage_Elements : System.Storage_Elements.Storage_Count;
5830 Alignment : System.Storage_Elements.Storage_Count);
5832 function Storage_Size (Pool : SSP)
5833 return System.Storage_Elements.Storage_Count;
5836 Procedure ``Allocate`` must be declared, whereas ``Deallocate`` and
5837 ``Storage_Size`` are optional. If ``Deallocate`` is not declared, then
5838 applying an unchecked deallocation has no effect other than to set its actual
5839 parameter to null. If ``Storage_Size`` is not declared, then the
5840 ``Storage_Size`` attribute applied to an access type associated with
5841 a pool object of type SSP returns zero. Additional operations can be declared
5842 for a simple storage pool type (such as for supporting a mark/release
5843 storage-management discipline).
5845 An object of a simple storage pool type can be associated with an access
5846 type by specifying the attribute
5847 :ref:`Simple_Storage_Pool <Attribute_Simple_Storage_Pool>`. For example:
5852 My_Pool : My_Simple_Storage_Pool_Type;
5854 type Acc is access My_Data_Type;
5856 for Acc'Simple_Storage_Pool use My_Pool;
5860 See attribute :ref:`Simple_Storage_Pool <Attribute_Simple_Storage_Pool>`
5861 for further details.
5863 .. _Pragma_Source_File_Name:
5865 Pragma Source_File_Name
5866 =======================
5873 pragma Source_File_Name (
5874 [Unit_Name =>] unit_NAME,
5875 Spec_File_Name => STRING_LITERAL,
5876 [Index => INTEGER_LITERAL]);
5878 pragma Source_File_Name (
5879 [Unit_Name =>] unit_NAME,
5880 Body_File_Name => STRING_LITERAL,
5881 [Index => INTEGER_LITERAL]);
5884 Use this to override the normal naming convention. It is a configuration
5885 pragma, and so has the usual applicability of configuration pragmas
5886 (i.e., it applies to either an entire partition, or to all units in a
5887 compilation, or to a single unit, depending on how it is used.
5888 ``unit_name`` is mapped to ``file_name_literal``. The identifier for
5889 the second argument is required, and indicates whether this is the file
5890 name for the spec or for the body.
5892 The optional Index argument should be used when a file contains multiple
5893 units, and when you do not want to use ``gnatchop`` to separate then
5894 into multiple files (which is the recommended procedure to limit the
5895 number of recompilations that are needed when some sources change).
5896 For instance, if the source file :file:`source.ada` contains
5912 you could use the following configuration pragmas:
5917 pragma Source_File_Name
5918 (B, Spec_File_Name => "source.ada", Index => 1);
5919 pragma Source_File_Name
5920 (A, Body_File_Name => "source.ada", Index => 2);
5923 Note that the ``gnatname`` utility can also be used to generate those
5924 configuration pragmas.
5926 Another form of the ``Source_File_Name`` pragma allows
5927 the specification of patterns defining alternative file naming schemes
5928 to apply to all files.
5933 pragma Source_File_Name
5934 ( [Spec_File_Name =>] STRING_LITERAL
5935 [,[Casing =>] CASING_SPEC]
5936 [,[Dot_Replacement =>] STRING_LITERAL]);
5938 pragma Source_File_Name
5939 ( [Body_File_Name =>] STRING_LITERAL
5940 [,[Casing =>] CASING_SPEC]
5941 [,[Dot_Replacement =>] STRING_LITERAL]);
5943 pragma Source_File_Name
5944 ( [Subunit_File_Name =>] STRING_LITERAL
5945 [,[Casing =>] CASING_SPEC]
5946 [,[Dot_Replacement =>] STRING_LITERAL]);
5948 CASING_SPEC ::= Lowercase | Uppercase | Mixedcase
5951 The first argument is a pattern that contains a single asterisk indicating
5952 the point at which the unit name is to be inserted in the pattern string
5953 to form the file name. The second argument is optional. If present it
5954 specifies the casing of the unit name in the resulting file name string.
5955 The default is lower case. Finally the third argument allows for systematic
5956 replacement of any dots in the unit name by the specified string literal.
5958 Note that Source_File_Name pragmas should not be used if you are using
5959 project files. The reason for this rule is that the project manager is not
5960 aware of these pragmas, and so other tools that use the projet file would not
5961 be aware of the intended naming conventions. If you are using project files,
5962 file naming is controlled by Source_File_Name_Project pragmas, which are
5963 usually supplied automatically by the project manager. A pragma
5964 Source_File_Name cannot appear after a :ref:`Pragma_Source_File_Name_Project`.
5966 For more details on the use of the ``Source_File_Name`` pragma, see the
5967 sections on ``Using Other File Names`` and `Alternative File Naming Schemes'
5968 in the :title:`GNAT User's Guide`.
5970 .. _Pragma_Source_File_Name_Project:
5972 Pragma Source_File_Name_Project
5973 ===============================
5975 This pragma has the same syntax and semantics as pragma Source_File_Name.
5976 It is only allowed as a stand-alone configuration pragma.
5977 It cannot appear after a :ref:`Pragma_Source_File_Name`, and
5978 most importantly, once pragma Source_File_Name_Project appears,
5979 no further Source_File_Name pragmas are allowed.
5981 The intention is that Source_File_Name_Project pragmas are always
5982 generated by the Project Manager in a manner consistent with the naming
5983 specified in a project file, and when naming is controlled in this manner,
5984 it is not permissible to attempt to modify this naming scheme using
5985 Source_File_Name or Source_File_Name_Project pragmas (which would not be
5986 known to the project manager).
5988 Pragma Source_Reference
5989 =======================
5996 pragma Source_Reference (INTEGER_LITERAL, STRING_LITERAL);
5999 This pragma must appear as the first line of a source file.
6000 ``integer_literal`` is the logical line number of the line following
6001 the pragma line (for use in error messages and debugging
6002 information). ``string_literal`` is a static string constant that
6003 specifies the file name to be used in error messages and debugging
6004 information. This is most notably used for the output of ``gnatchop``
6005 with the *-r* switch, to make sure that the original unchopped
6006 source file is the one referred to.
6008 The second argument must be a string literal, it cannot be a static
6009 string expression other than a string literal. This is because its value
6010 is needed for error messages issued by all phases of the compiler.
6012 .. _Pragma-SPARK_Mode:
6022 pragma SPARK_Mode [(On | Off)] ;
6025 In general a program can have some parts that are in SPARK 2014 (and
6026 follow all the rules in the SPARK Reference Manual), and some parts
6027 that are full Ada 2012.
6029 The SPARK_Mode pragma is used to identify which parts are in SPARK
6030 2014 (by default programs are in full Ada). The SPARK_Mode pragma can
6031 be used in the following places:
6035 As a configuration pragma, in which case it sets the default mode for
6036 all units compiled with this pragma.
6039 Immediately following a library-level subprogram spec
6042 Immediately within a library-level package body
6045 Immediately following the ``private`` keyword of a library-level
6049 Immediately following the ``begin`` keyword of a library-level
6053 Immediately within a library-level subprogram body
6056 Normally a subprogram or package spec/body inherits the current mode
6057 that is active at the point it is declared. But this can be overridden
6058 by pragma within the spec or body as above.
6060 The basic consistency rule is that you can't turn SPARK_Mode back
6061 ``On``, once you have explicitly (with a pragma) turned if
6062 ``Off``. So the following rules apply:
6064 If a subprogram spec has SPARK_Mode ``Off``, then the body must
6065 also have SPARK_Mode ``Off``.
6067 For a package, we have four parts:
6070 the package public declarations
6072 the package private part
6074 the body of the package
6076 the elaboration code after ``begin``
6078 For a package, the rule is that if you explicitly turn SPARK_Mode
6079 ``Off`` for any part, then all the following parts must have
6080 SPARK_Mode ``Off``. Note that this may require repeating a pragma
6081 SPARK_Mode (``Off``) in the body. For example, if we have a
6082 configuration pragma SPARK_Mode (``On``) that turns the mode on by
6083 default everywhere, and one particular package spec has pragma
6084 SPARK_Mode (``Off``), then that pragma will need to be repeated in
6087 Pragma Static_Elaboration_Desired
6088 =================================
6095 pragma Static_Elaboration_Desired;
6098 This pragma is used to indicate that the compiler should attempt to initialize
6099 statically the objects declared in the library unit to which the pragma applies,
6100 when these objects are initialized (explicitly or implicitly) by an aggregate.
6101 In the absence of this pragma, aggregates in object declarations are expanded
6102 into assignments and loops, even when the aggregate components are static
6103 constants. When the aggregate is present the compiler builds a static expression
6104 that requires no run-time code, so that the initialized object can be placed in
6105 read-only data space. If the components are not static, or the aggregate has
6106 more that 100 components, the compiler emits a warning that the pragma cannot
6107 be obeyed. (See also the restriction No_Implicit_Loops, which supports static
6108 construction of larger aggregates with static components that include an others
6111 Pragma Stream_Convert
6112 =====================
6119 pragma Stream_Convert (
6120 [Entity =>] type_LOCAL_NAME,
6121 [Read =>] function_NAME,
6122 [Write =>] function_NAME);
6125 This pragma provides an efficient way of providing user-defined stream
6126 attributes. Not only is it simpler to use than specifying the attributes
6127 directly, but more importantly, it allows the specification to be made in such
6128 a way that the predefined unit Ada.Streams is not loaded unless it is actually
6129 needed (i.e. unless the stream attributes are actually used); the use of
6130 the Stream_Convert pragma adds no overhead at all, unless the stream
6131 attributes are actually used on the designated type.
6133 The first argument specifies the type for which stream functions are
6134 provided. The second parameter provides a function used to read values
6135 of this type. It must name a function whose argument type may be any
6136 subtype, and whose returned type must be the type given as the first
6137 argument to the pragma.
6139 The meaning of the ``Read`` parameter is that if a stream attribute directly
6140 or indirectly specifies reading of the type given as the first parameter,
6141 then a value of the type given as the argument to the Read function is
6142 read from the stream, and then the Read function is used to convert this
6143 to the required target type.
6145 Similarly the ``Write`` parameter specifies how to treat write attributes
6146 that directly or indirectly apply to the type given as the first parameter.
6147 It must have an input parameter of the type specified by the first parameter,
6148 and the return type must be the same as the input type of the Read function.
6149 The effect is to first call the Write function to convert to the given stream
6150 type, and then write the result type to the stream.
6152 The Read and Write functions must not be overloaded subprograms. If necessary
6153 renamings can be supplied to meet this requirement.
6154 The usage of this attribute is best illustrated by a simple example, taken
6155 from the GNAT implementation of package Ada.Strings.Unbounded:
6160 function To_Unbounded (S : String) return Unbounded_String
6161 renames To_Unbounded_String;
6163 pragma Stream_Convert
6164 (Unbounded_String, To_Unbounded, To_String);
6167 The specifications of the referenced functions, as given in the Ada
6168 Reference Manual are:
6173 function To_Unbounded_String (Source : String)
6174 return Unbounded_String;
6176 function To_String (Source : Unbounded_String)
6180 The effect is that if the value of an unbounded string is written to a stream,
6181 then the representation of the item in the stream is in the same format that
6182 would be used for ``Standard.String'Output``, and this same representation
6183 is expected when a value of this type is read from the stream. Note that the
6184 value written always includes the bounds, even for Unbounded_String'Write,
6185 since Unbounded_String is not an array type.
6187 Note that the ``Stream_Convert`` pragma is not effective in the case of
6188 a derived type of a non-limited tagged type. If such a type is specified then
6189 the pragma is silently ignored, and the default implementation of the stream
6190 attributes is used instead.
6200 pragma Style_Checks (string_LITERAL | ALL_CHECKS |
6201 On | Off [, LOCAL_NAME]);
6204 This pragma is used in conjunction with compiler switches to control the
6205 built in style checking provided by GNAT. The compiler switches, if set,
6206 provide an initial setting for the switches, and this pragma may be used
6207 to modify these settings, or the settings may be provided entirely by
6208 the use of the pragma. This pragma can be used anywhere that a pragma
6209 is legal, including use as a configuration pragma (including use in
6210 the :file:`gnat.adc` file).
6212 The form with a string literal specifies which style options are to be
6213 activated. These are additive, so they apply in addition to any previously
6214 set style check options. The codes for the options are the same as those
6215 used in the *-gnaty* switch to *gcc* or *gnatmake*.
6216 For example the following two methods can be used to enable
6223 pragma Style_Checks ("l");
6233 The form ``ALL_CHECKS`` activates all standard checks (its use is equivalent
6234 to the use of the :switch:`gnaty` switch with no options.
6235 See the :title:`GNAT User's Guide` for details.)
6237 Note: the behavior is slightly different in GNAT mode (:switch:`-gnatg` used).
6238 In this case, ``ALL_CHECKS`` implies the standard set of GNAT mode style check
6239 options (i.e. equivalent to :switch:`-gnatyg`).
6241 The forms with ``Off`` and ``On``
6242 can be used to temporarily disable style checks
6243 as shown in the following example:
6248 pragma Style_Checks ("k"); -- requires keywords in lower case
6249 pragma Style_Checks (Off); -- turn off style checks
6250 NULL; -- this will not generate an error message
6251 pragma Style_Checks (On); -- turn style checks back on
6252 NULL; -- this will generate an error message
6255 Finally the two argument form is allowed only if the first argument is
6256 ``On`` or ``Off``. The effect is to turn of semantic style checks
6257 for the specified entity, as shown in the following example:
6262 pragma Style_Checks ("r"); -- require consistency of identifier casing
6264 Rf1 : Integer := ARG; -- incorrect, wrong case
6265 pragma Style_Checks (Off, Arg);
6266 Rf2 : Integer := ARG; -- OK, no error
6277 pragma Subtitle ([Subtitle =>] STRING_LITERAL);
6280 This pragma is recognized for compatibility with other Ada compilers
6281 but is ignored by GNAT.
6291 pragma Suppress (Identifier [, [On =>] Name]);
6294 This is a standard pragma, and supports all the check names required in
6295 the RM. It is included here because GNAT recognizes some additional check
6296 names that are implementation defined (as permitted by the RM):
6300 ``Alignment_Check`` can be used to suppress alignment checks
6301 on addresses used in address clauses. Such checks can also be suppressed
6302 by suppressing range checks, but the specific use of ``Alignment_Check``
6303 allows suppression of alignment checks without suppressing other range checks.
6304 Note that ``Alignment_Check`` is suppressed by default on machines (such as
6305 the x86) with non-strict alignment.
6308 ``Atomic_Synchronization`` can be used to suppress the special memory
6309 synchronization instructions that are normally generated for access to
6310 ``Atomic`` variables to ensure correct synchronization between tasks
6311 that use such variables for synchronization purposes.
6314 ``Duplicated_Tag_Check`` Can be used to suppress the check that is generated
6315 for a duplicated tag value when a tagged type is declared.
6318 ``Container_Checks`` Can be used to suppress all checks within Ada.Containers
6319 and instances of its children, including Tampering_Check.
6322 ``Tampering_Check`` Can be used to suppress tampering check in the containers.
6325 ``Predicate_Check`` can be used to control whether predicate checks are
6326 active. It is applicable only to predicates for which the policy is
6327 ``Check``. Unlike ``Assertion_Policy``, which determines if a given
6328 predicate is ignored or checked for the whole program, the use of
6329 ``Suppress`` and ``Unsuppress`` with this check name allows a given
6330 predicate to be turned on and off at specific points in the program.
6333 ``Validity_Check`` can be used specifically to control validity checks.
6334 If ``Suppress`` is used to suppress validity checks, then no validity
6335 checks are performed, including those specified by the appropriate compiler
6336 switch or the ``Validity_Checks`` pragma.
6339 Additional check names previously introduced by use of the ``Check_Name``
6340 pragma are also allowed.
6343 Note that pragma Suppress gives the compiler permission to omit
6344 checks, but does not require the compiler to omit checks. The compiler
6345 will generate checks if they are essentially free, even when they are
6346 suppressed. In particular, if the compiler can prove that a certain
6347 check will necessarily fail, it will generate code to do an
6348 unconditional 'raise', even if checks are suppressed. The compiler
6351 Of course, run-time checks are omitted whenever the compiler can prove
6352 that they will not fail, whether or not checks are suppressed.
6362 pragma Suppress_All;
6365 This pragma can appear anywhere within a unit.
6366 The effect is to apply ``Suppress (All_Checks)`` to the unit
6367 in which it appears. This pragma is implemented for compatibility with DEC
6368 Ada 83 usage where it appears at the end of a unit, and for compatibility
6369 with Rational Ada, where it appears as a program unit pragma.
6370 The use of the standard Ada pragma ``Suppress (All_Checks)``
6371 as a normal configuration pragma is the preferred usage in GNAT.
6373 .. _Pragma-Suppress_Debug_Info:
6375 Pragma Suppress_Debug_Info
6376 ==========================
6383 pragma Suppress_Debug_Info ([Entity =>] LOCAL_NAME);
6386 This pragma can be used to suppress generation of debug information
6387 for the specified entity. It is intended primarily for use in debugging
6388 the debugger, and navigating around debugger problems.
6390 Pragma Suppress_Exception_Locations
6391 ===================================
6398 pragma Suppress_Exception_Locations;
6401 In normal mode, a raise statement for an exception by default generates
6402 an exception message giving the file name and line number for the location
6403 of the raise. This is useful for debugging and logging purposes, but this
6404 entails extra space for the strings for the messages. The configuration
6405 pragma ``Suppress_Exception_Locations`` can be used to suppress the
6406 generation of these strings, with the result that space is saved, but the
6407 exception message for such raises is null. This configuration pragma may
6408 appear in a global configuration pragma file, or in a specific unit as
6409 usual. It is not required that this pragma be used consistently within
6410 a partition, so it is fine to have some units within a partition compiled
6411 with this pragma and others compiled in normal mode without it.
6413 .. _Pragma-Suppress_Initialization:
6415 Pragma Suppress_Initialization
6416 ==============================
6417 .. index:: Suppressing initialization
6419 .. index:: Initialization, suppression of
6426 pragma Suppress_Initialization ([Entity =>] variable_or_subtype_Name);
6429 Here variable_or_subtype_Name is the name introduced by a type declaration
6430 or subtype declaration or the name of a variable introduced by an
6433 In the case of a type or subtype
6434 this pragma suppresses any implicit or explicit initialization
6435 for all variables of the given type or subtype,
6436 including initialization resulting from the use of pragmas
6437 Normalize_Scalars or Initialize_Scalars.
6439 This is considered a representation item, so it cannot be given after
6440 the type is frozen. It applies to all subsequent object declarations,
6441 and also any allocator that creates objects of the type.
6443 If the pragma is given for the first subtype, then it is considered
6444 to apply to the base type and all its subtypes. If the pragma is given
6445 for other than a first subtype, then it applies only to the given subtype.
6446 The pragma may not be given after the type is frozen.
6448 Note that this includes eliminating initialization of discriminants
6449 for discriminated types, and tags for tagged types. In these cases,
6450 you will have to use some non-portable mechanism (e.g. address
6451 overlays or unchecked conversion) to achieve required initialization
6452 of these fields before accessing any object of the corresponding type.
6454 For the variable case, implicit initialization for the named variable
6455 is suppressed, just as though its subtype had been given in a pragma
6456 Suppress_Initialization, as described above.
6466 pragma Task_Name (string_EXPRESSION);
6469 This pragma appears within a task definition (like pragma
6470 ``Priority``) and applies to the task in which it appears. The
6471 argument must be of type String, and provides a name to be used for
6472 the task instance when the task is created. Note that this expression
6473 is not required to be static, and in particular, it can contain
6474 references to task discriminants. This facility can be used to
6475 provide different names for different tasks as they are created,
6476 as illustrated in the example below.
6478 The task name is recorded internally in the run-time structures
6479 and is accessible to tools like the debugger. In addition the
6480 routine ``Ada.Task_Identification.Image`` will return this
6481 string, with a unique task address appended.
6486 -- Example of the use of pragma Task_Name
6488 with Ada.Task_Identification;
6489 use Ada.Task_Identification;
6490 with Text_IO; use Text_IO;
6493 type Astring is access String;
6495 task type Task_Typ (Name : access String) is
6496 pragma Task_Name (Name.all);
6499 task body Task_Typ is
6500 Nam : constant String := Image (Current_Task);
6502 Put_Line ("-->" & Nam (1 .. 14) & "<--");
6505 type Ptr_Task is access Task_Typ;
6506 Task_Var : Ptr_Task;
6510 new Task_Typ (new String'("This is task 1"));
6512 new Task_Typ (new String'("This is task 2"));
6523 pragma Task_Storage (
6524 [Task_Type =>] LOCAL_NAME,
6525 [Top_Guard =>] static_integer_EXPRESSION);
6528 This pragma specifies the length of the guard area for tasks. The guard
6529 area is an additional storage area allocated to a task. A value of zero
6530 means that either no guard area is created or a minimal guard area is
6531 created, depending on the target. This pragma can appear anywhere a
6532 ``Storage_Size`` attribute definition clause is allowed for a task
6535 .. _Pragma-Test_Case:
6539 .. index:: Test cases
6548 [Name =>] static_string_Expression
6549 ,[Mode =>] (Nominal | Robustness)
6550 [, Requires => Boolean_Expression]
6551 [, Ensures => Boolean_Expression]);
6554 The ``Test_Case`` pragma allows defining fine-grain specifications
6555 for use by testing tools.
6556 The compiler checks the validity of the ``Test_Case`` pragma, but its
6557 presence does not lead to any modification of the code generated by the
6560 ``Test_Case`` pragmas may only appear immediately following the
6561 (separate) declaration of a subprogram in a package declaration, inside
6562 a package spec unit. Only other pragmas may intervene (that is appear
6563 between the subprogram declaration and a test case).
6565 The compiler checks that boolean expressions given in ``Requires`` and
6566 ``Ensures`` are valid, where the rules for ``Requires`` are the
6567 same as the rule for an expression in ``Precondition`` and the rules
6568 for ``Ensures`` are the same as the rule for an expression in
6569 ``Postcondition``. In particular, attributes ``'Old`` and
6570 ``'Result`` can only be used within the ``Ensures``
6571 expression. The following is an example of use within a package spec:
6576 package Math_Functions is
6578 function Sqrt (Arg : Float) return Float;
6579 pragma Test_Case (Name => "Test 1",
6581 Requires => Arg < 10000,
6582 Ensures => Sqrt'Result < 10);
6587 The meaning of a test case is that there is at least one context where
6588 ``Requires`` holds such that, if the associated subprogram is executed in
6589 that context, then ``Ensures`` holds when the subprogram returns.
6590 Mode ``Nominal`` indicates that the input context should also satisfy the
6591 precondition of the subprogram, and the output context should also satisfy its
6592 postcondition. Mode ``Robustness`` indicates that the precondition and
6593 postcondition of the subprogram should be ignored for this test case.
6595 .. _Pragma-Thread_Local_Storage:
6597 Pragma Thread_Local_Storage
6598 ===========================
6599 .. index:: Task specific storage
6601 .. index:: TLS (Thread Local Storage)
6603 .. index:: Task_Attributes
6610 pragma Thread_Local_Storage ([Entity =>] LOCAL_NAME);
6613 This pragma specifies that the specified entity, which must be
6614 a variable declared in a library-level package, is to be marked as
6615 "Thread Local Storage" (``TLS``). On systems supporting this (which
6616 include Windows, Solaris, GNU/Linux and VxWorks 6), this causes each
6617 thread (and hence each Ada task) to see a distinct copy of the variable.
6619 The variable may not have default initialization, and if there is
6620 an explicit initialization, it must be either ``null`` for an
6621 access variable, or a static expression for a scalar variable.
6622 This provides a low level mechanism similar to that provided by
6623 the ``Ada.Task_Attributes`` package, but much more efficient
6624 and is also useful in writing interface code that will interact
6625 with foreign threads.
6627 If this pragma is used on a system where ``TLS`` is not supported,
6628 then an error message will be generated and the program will be rejected.
6638 pragma Time_Slice (static_duration_EXPRESSION);
6641 For implementations of GNAT on operating systems where it is possible
6642 to supply a time slice value, this pragma may be used for this purpose.
6643 It is ignored if it is used in a system that does not allow this control,
6644 or if it appears in other than the main program unit.
6654 pragma Title (TITLING_OPTION [, TITLING OPTION]);
6657 [Title =>] STRING_LITERAL,
6658 | [Subtitle =>] STRING_LITERAL
6661 Syntax checked but otherwise ignored by GNAT. This is a listing control
6662 pragma used in DEC Ada 83 implementations to provide a title and/or
6663 subtitle for the program listing. The program listing generated by GNAT
6664 does not have titles or subtitles.
6666 Unlike other pragmas, the full flexibility of named notation is allowed
6667 for this pragma, i.e., the parameters may be given in any order if named
6668 notation is used, and named and positional notation can be mixed
6669 following the normal rules for procedure calls in Ada.
6671 Pragma Type_Invariant
6672 =====================
6679 pragma Type_Invariant
6680 ([Entity =>] type_LOCAL_NAME,
6681 [Check =>] EXPRESSION);
6684 The ``Type_Invariant`` pragma is intended to be an exact
6685 replacement for the language-defined ``Type_Invariant``
6686 aspect, and shares its restrictions and semantics. It differs
6687 from the language defined ``Invariant`` pragma in that it
6688 does not permit a string parameter, and it is
6689 controlled by the assertion identifier ``Type_Invariant``
6690 rather than ``Invariant``.
6692 .. _Pragma-Type_Invariant_Class:
6694 Pragma Type_Invariant_Class
6695 ===========================
6702 pragma Type_Invariant_Class
6703 ([Entity =>] type_LOCAL_NAME,
6704 [Check =>] EXPRESSION);
6707 The ``Type_Invariant_Class`` pragma is intended to be an exact
6708 replacement for the language-defined ``Type_Invariant'Class``
6709 aspect, and shares its restrictions and semantics.
6711 Note: This pragma is called ``Type_Invariant_Class`` rather than
6712 ``Type_Invariant'Class`` because the latter would not be strictly
6713 conforming to the allowed syntax for pragmas. The motivation
6714 for providing pragmas equivalent to the aspects is to allow a program
6715 to be written using the pragmas, and then compiled if necessary
6716 using an Ada compiler that does not recognize the pragmas or
6717 aspects, but is prepared to ignore the pragmas. The assertion
6718 policy that controls this pragma is ``Type_Invariant'Class``,
6719 not ``Type_Invariant_Class``.
6721 Pragma Unchecked_Union
6722 ======================
6723 .. index:: Unions in C
6731 pragma Unchecked_Union (first_subtype_LOCAL_NAME);
6734 This pragma is used to specify a representation of a record type that is
6735 equivalent to a C union. It was introduced as a GNAT implementation defined
6736 pragma in the GNAT Ada 95 mode. Ada 2005 includes an extended version of this
6737 pragma, making it language defined, and GNAT fully implements this extended
6738 version in all language modes (Ada 83, Ada 95, and Ada 2005). For full
6739 details, consult the Ada 2012 Reference Manual, section B.3.3.
6741 Pragma Unevaluated_Use_Of_Old
6742 =============================
6743 .. index:: Attribute Old
6745 .. index:: Attribute Loop_Entry
6747 .. index:: Unevaluated_Use_Of_Old
6755 pragma Unevaluated_Use_Of_Old (Error | Warn | Allow);
6758 This pragma controls the processing of attributes Old and Loop_Entry.
6759 If either of these attributes is used in a potentially unevaluated
6760 expression (e.g. the then or else parts of an if expression), then
6761 normally this usage is considered illegal if the prefix of the attribute
6762 is other than an entity name. The language requires this
6763 behavior for Old, and GNAT copies the same rule for Loop_Entry.
6765 The reason for this rule is that otherwise, we can have a situation
6766 where we save the Old value, and this results in an exception, even
6767 though we might not evaluate the attribute. Consider this example:
6772 package UnevalOld is
6774 procedure U (A : String; C : Boolean) -- ERROR
6775 with Post => (if C then A(1)'Old = K else True);
6779 If procedure U is called with a string with a lower bound of 2, and
6780 C false, then an exception would be raised trying to evaluate A(1)
6781 on entry even though the value would not be actually used.
6783 Although the rule guarantees against this possibility, it is sometimes
6784 too restrictive. For example if we know that the string has a lower
6785 bound of 1, then we will never raise an exception.
6786 The pragma ``Unevaluated_Use_Of_Old`` can be
6787 used to modify this behavior. If the argument is ``Error`` then an
6788 error is given (this is the default RM behavior). If the argument is
6789 ``Warn`` then the usage is allowed as legal but with a warning
6790 that an exception might be raised. If the argument is ``Allow``
6791 then the usage is allowed as legal without generating a warning.
6793 This pragma may appear as a configuration pragma, or in a declarative
6794 part or package specification. In the latter case it applies to
6795 uses up to the end of the corresponding statement sequence or
6796 sequence of package declarations.
6798 Pragma Unimplemented_Unit
6799 =========================
6806 pragma Unimplemented_Unit;
6809 If this pragma occurs in a unit that is processed by the compiler, GNAT
6810 aborts with the message :samp:`xxx not implemented`, where
6811 ``xxx`` is the name of the current compilation unit. This pragma is
6812 intended to allow the compiler to handle unimplemented library units in
6815 The abort only happens if code is being generated. Thus you can use
6816 specs of unimplemented packages in syntax or semantic checking mode.
6818 .. _Pragma-Universal_Aliasing:
6820 Pragma Universal_Aliasing
6821 =========================
6828 pragma Universal_Aliasing [([Entity =>] type_LOCAL_NAME)];
6831 ``type_LOCAL_NAME`` must refer to a type declaration in the current
6832 declarative part. The effect is to inhibit strict type-based aliasing
6833 optimization for the given type. In other words, the effect is as though
6834 access types designating this type were subject to pragma No_Strict_Aliasing.
6835 For a detailed description of the strict aliasing optimization, and the
6836 situations in which it must be suppressed, see the section on
6837 ``Optimization and Strict Aliasing`` in the :title:`GNAT User's Guide`.
6839 .. _Pragma-Universal_Data:
6841 Pragma Universal_Data
6842 =====================
6849 pragma Universal_Data [(library_unit_Name)];
6852 This pragma is supported only for the AAMP target and is ignored for
6853 other targets. The pragma specifies that all library-level objects
6854 (Counter 0 data) associated with the library unit are to be accessed
6855 and updated using universal addressing (24-bit addresses for AAMP5)
6856 rather than the default of 16-bit Data Environment (DENV) addressing.
6857 Use of this pragma will generally result in less efficient code for
6858 references to global data associated with the library unit, but
6859 allows such data to be located anywhere in memory. This pragma is
6860 a library unit pragma, but can also be used as a configuration pragma
6861 (including use in the :file:`gnat.adc` file). The functionality
6862 of this pragma is also available by applying the -univ switch on the
6863 compilations of units where universal addressing of the data is desired.
6865 .. _Pragma-Unmodified:
6869 .. index:: Warnings, unmodified
6876 pragma Unmodified (LOCAL_NAME {, LOCAL_NAME});
6879 This pragma signals that the assignable entities (variables,
6880 ``out`` parameters, ``in out`` parameters) whose names are listed are
6881 deliberately not assigned in the current source unit. This
6882 suppresses warnings about the
6883 entities being referenced but not assigned, and in addition a warning will be
6884 generated if one of these entities is in fact assigned in the
6885 same unit as the pragma (or in the corresponding body, or one
6888 This is particularly useful for clearly signaling that a particular
6889 parameter is not modified, even though the spec suggests that it might
6892 For the variable case, warnings are never given for unreferenced variables
6893 whose name contains one of the substrings
6894 ``DISCARD, DUMMY, IGNORE, JUNK, UNUSED`` in any casing. Such names
6895 are typically to be used in cases where such warnings are expected.
6896 Thus it is never necessary to use ``pragma Unmodified`` for such
6897 variables, though it is harmless to do so.
6899 .. _Pragma-Unreferenced:
6903 .. index:: Warnings, unreferenced
6910 pragma Unreferenced (LOCAL_NAME {, LOCAL_NAME});
6911 pragma Unreferenced (library_unit_NAME {, library_unit_NAME});
6914 This pragma signals that the entities whose names are listed are
6915 deliberately not referenced in the current source unit after the
6916 occurrence of the pragma. This
6917 suppresses warnings about the
6918 entities being unreferenced, and in addition a warning will be
6919 generated if one of these entities is in fact subsequently referenced in the
6920 same unit as the pragma (or in the corresponding body, or one
6923 This is particularly useful for clearly signaling that a particular
6924 parameter is not referenced in some particular subprogram implementation
6925 and that this is deliberate. It can also be useful in the case of
6926 objects declared only for their initialization or finalization side
6929 If ``LOCAL_NAME`` identifies more than one matching homonym in the
6930 current scope, then the entity most recently declared is the one to which
6931 the pragma applies. Note that in the case of accept formals, the pragma
6932 Unreferenced may appear immediately after the keyword ``do`` which
6933 allows the indication of whether or not accept formals are referenced
6934 or not to be given individually for each accept statement.
6936 The left hand side of an assignment does not count as a reference for the
6937 purpose of this pragma. Thus it is fine to assign to an entity for which
6938 pragma Unreferenced is given.
6940 Note that if a warning is desired for all calls to a given subprogram,
6941 regardless of whether they occur in the same unit as the subprogram
6942 declaration, then this pragma should not be used (calls from another
6943 unit would not be flagged); pragma Obsolescent can be used instead
6944 for this purpose, see :ref:`Pragma_Obsolescent`.
6946 The second form of pragma ``Unreferenced`` is used within a context
6947 clause. In this case the arguments must be unit names of units previously
6948 mentioned in ``with`` clauses (similar to the usage of pragma
6949 ``Elaborate_All``. The effect is to suppress warnings about unreferenced
6950 units and unreferenced entities within these units.
6952 For the variable case, warnings are never given for unreferenced variables
6953 whose name contains one of the substrings
6954 ``DISCARD, DUMMY, IGNORE, JUNK, UNUSED`` in any casing. Such names
6955 are typically to be used in cases where such warnings are expected.
6956 Thus it is never necessary to use ``pragma Unreferenced`` for such
6957 variables, though it is harmless to do so.
6959 .. _Pragma-Unreferenced_Objects:
6961 Pragma Unreferenced_Objects
6962 ===========================
6963 .. index:: Warnings, unreferenced
6970 pragma Unreferenced_Objects (local_subtype_NAME {, local_subtype_NAME});
6973 This pragma signals that for the types or subtypes whose names are
6974 listed, objects which are declared with one of these types or subtypes may
6975 not be referenced, and if no references appear, no warnings are given.
6977 This is particularly useful for objects which are declared solely for their
6978 initialization and finalization effect. Such variables are sometimes referred
6979 to as RAII variables (Resource Acquisition Is Initialization). Using this
6980 pragma on the relevant type (most typically a limited controlled type), the
6981 compiler will automatically suppress unwanted warnings about these variables
6982 not being referenced.
6984 Pragma Unreserve_All_Interrupts
6985 ===============================
6992 pragma Unreserve_All_Interrupts;
6995 Normally certain interrupts are reserved to the implementation. Any attempt
6996 to attach an interrupt causes Program_Error to be raised, as described in
6997 RM C.3.2(22). A typical example is the ``SIGINT`` interrupt used in
6998 many systems for a :kbd:`Ctrl-C` interrupt. Normally this interrupt is
6999 reserved to the implementation, so that :kbd:`Ctrl-C` can be used to
7000 interrupt execution.
7002 If the pragma ``Unreserve_All_Interrupts`` appears anywhere in any unit in
7003 a program, then all such interrupts are unreserved. This allows the
7004 program to handle these interrupts, but disables their standard
7005 functions. For example, if this pragma is used, then pressing
7006 :kbd:`Ctrl-C` will not automatically interrupt execution. However,
7007 a program can then handle the ``SIGINT`` interrupt as it chooses.
7009 For a full list of the interrupts handled in a specific implementation,
7010 see the source code for the spec of ``Ada.Interrupts.Names`` in
7011 file :file:`a-intnam.ads`. This is a target dependent file that contains the
7012 list of interrupts recognized for a given target. The documentation in
7013 this file also specifies what interrupts are affected by the use of
7014 the ``Unreserve_All_Interrupts`` pragma.
7016 For a more general facility for controlling what interrupts can be
7017 handled, see pragma ``Interrupt_State``, which subsumes the functionality
7018 of the ``Unreserve_All_Interrupts`` pragma.
7028 pragma Unsuppress (IDENTIFIER [, [On =>] NAME]);
7031 This pragma undoes the effect of a previous pragma ``Suppress``. If
7032 there is no corresponding pragma ``Suppress`` in effect, it has no
7033 effect. The range of the effect is the same as for pragma
7034 ``Suppress``. The meaning of the arguments is identical to that used
7035 in pragma ``Suppress``.
7037 One important application is to ensure that checks are on in cases where
7038 code depends on the checks for its correct functioning, so that the code
7039 will compile correctly even if the compiler switches are set to suppress
7040 checks. For example, in a program that depends on external names of tagged
7041 types and wants to ensure that the duplicated tag check occurs even if all
7042 run-time checks are suppressed by a compiler switch, the following
7043 configuration pragma will ensure this test is not suppressed:
7048 pragma Unsuppress (Duplicated_Tag_Check);
7051 This pragma is standard in Ada 2005. It is available in all earlier versions
7052 of Ada as an implementation-defined pragma.
7054 Note that in addition to the checks defined in the Ada RM, GNAT recogizes a
7055 number of implementation-defined check names. See the description of pragma
7056 ``Suppress`` for full details.
7058 Pragma Use_VADS_Size
7059 ====================
7060 .. index:: Size, VADS compatibility
7062 .. index:: Rational profile
7070 pragma Use_VADS_Size;
7073 This is a configuration pragma. In a unit to which it applies, any use
7074 of the 'Size attribute is automatically interpreted as a use of the
7075 'VADS_Size attribute. Note that this may result in incorrect semantic
7076 processing of valid Ada 95 or Ada 2005 programs. This is intended to aid in
7077 the handling of existing code which depends on the interpretation of Size
7078 as implemented in the VADS compiler. See description of the VADS_Size
7079 attribute for further details.
7085 .. index:: Warnings, unused
7092 pragma Unused (LOCAL_NAME {, LOCAL_NAME});
7095 This pragma signals that the assignable entities (variables,
7096 ``out`` parameters, and ``in out`` parameters) whose names are listed
7097 deliberately do not get assigned or referenced in the current source unit
7098 after the occurrence of the pragma in the current source unit. This
7099 suppresses warnings about the entities that are unreferenced and/or not
7100 assigned, and, in addition, a warning will be generated if one of these
7101 entities gets assigned or subsequently referenced in the same unit as the
7102 pragma (in the corresponding body or one of its subunits).
7104 This is particularly useful for clearly signaling that a particular
7105 parameter is not modified or referenced, even though the spec suggests
7108 For the variable case, warnings are never given for unreferenced
7109 variables whose name contains one of the substrings
7110 ``DISCARD, DUMMY, IGNORE, JUNK, UNUSED`` in any casing. Such names
7111 are typically to be used in cases where such warnings are expected.
7112 Thus it is never necessary to use ``pragma Unmodified`` for such
7113 variables, though it is harmless to do so.
7115 Pragma Validity_Checks
7116 ======================
7123 pragma Validity_Checks (string_LITERAL | ALL_CHECKS | On | Off);
7126 This pragma is used in conjunction with compiler switches to control the
7127 built-in validity checking provided by GNAT. The compiler switches, if set
7128 provide an initial setting for the switches, and this pragma may be used
7129 to modify these settings, or the settings may be provided entirely by
7130 the use of the pragma. This pragma can be used anywhere that a pragma
7131 is legal, including use as a configuration pragma (including use in
7132 the :file:`gnat.adc` file).
7134 The form with a string literal specifies which validity options are to be
7135 activated. The validity checks are first set to include only the default
7136 reference manual settings, and then a string of letters in the string
7137 specifies the exact set of options required. The form of this string
7138 is exactly as described for the *-gnatVx* compiler switch (see the
7139 GNAT User's Guide for details). For example the following two
7140 methods can be used to enable validity checking for mode ``in`` and
7141 ``in out`` subprogram parameters:
7147 pragma Validity_Checks ("im");
7154 $ gcc -c -gnatVim ...
7157 The form ALL_CHECKS activates all standard checks (its use is equivalent
7158 to the use of the :switch:`gnatva` switch.
7160 The forms with ``Off`` and ``On``
7161 can be used to temporarily disable validity checks
7162 as shown in the following example:
7167 pragma Validity_Checks ("c"); -- validity checks for copies
7168 pragma Validity_Checks (Off); -- turn off validity checks
7169 A := B; -- B will not be validity checked
7170 pragma Validity_Checks (On); -- turn validity checks back on
7171 A := C; -- C will be validity checked
7182 pragma Volatile (LOCAL_NAME);
7185 This pragma is defined by the Ada Reference Manual, and the GNAT
7186 implementation is fully conformant with this definition. The reason it
7187 is mentioned in this section is that a pragma of the same name was supplied
7188 in some Ada 83 compilers, including DEC Ada 83. The Ada 95 / Ada 2005
7189 implementation of pragma Volatile is upwards compatible with the
7190 implementation in DEC Ada 83.
7192 .. _Pragma-Volatile_Full_Access:
7194 Pragma Volatile_Full_Access
7195 ===========================
7202 pragma Volatile_Full_Access (LOCAL_NAME);
7205 This is similar in effect to pragma Volatile, except that any reference to the
7206 object is guaranteed to be done only with instructions that read or write all
7207 the bits of the object. Furthermore, if the object is of a composite type,
7208 then any reference to a component of the object is guaranteed to read and/or
7209 write all the bits of the object.
7211 The intention is that this be suitable for use with memory-mapped I/O devices
7212 on some machines. Note that there are two important respects in which this is
7213 different from ``pragma Atomic``. First a reference to a ``Volatile_Full_Access``
7214 object is not a sequential action in the RM 9.10 sense and, therefore, does
7215 not create a synchronization point. Second, in the case of ``pragma Atomic``,
7216 there is no guarantee that all the bits will be accessed if the reference
7217 is not to the whole object; the compiler is allowed (and generally will)
7218 access only part of the object in this case.
7220 It is not permissible to specify ``Atomic`` and ``Volatile_Full_Access`` for
7223 It is not permissible to specify ``Volatile_Full_Access`` for a composite
7224 (record or array) type or object that has at least one ``Aliased`` component.
7226 .. _Pragma-Volatile_Function:
7228 Pragma Volatile_Function
7229 ========================
7235 pragma Volatile_Function [ (boolean_EXPRESSION) ];
7237 For the semantics of this pragma, see the entry for aspect ``Volatile_Function``
7238 in the SPARK 2014 Reference Manual, section 7.1.2.
7240 Pragma Warning_As_Error
7241 =======================
7248 pragma Warning_As_Error (static_string_EXPRESSION);
7251 This configuration pragma allows the programmer to specify a set
7252 of warnings that will be treated as errors. Any warning which
7253 matches the pattern given by the pragma argument will be treated
7254 as an error. This gives much more precise control that -gnatwe
7255 which treats all warnings as errors.
7257 The pattern may contain asterisks, which match zero or more characters in
7258 the message. For example, you can use
7259 ``pragma Warning_As_Error ("bits of*unused")`` to treat the warning
7260 message ``warning: 960 bits of "a" unused`` as an error. No other regular
7261 expression notations are permitted. All characters other than asterisk in
7262 these three specific cases are treated as literal characters in the match.
7263 The match is case insensitive, for example XYZ matches xyz.
7265 Note that the pattern matches if it occurs anywhere within the warning
7266 message string (it is not necessary to put an asterisk at the start and
7267 the end of the message, since this is implied).
7269 Another possibility for the static_string_EXPRESSION which works whether
7270 or not error tags are enabled (*-gnatw.d*) is to use the
7271 *-gnatw* tag string, enclosed in brackets,
7272 as shown in the example below, to treat a class of warnings as errors.
7274 The above use of patterns to match the message applies only to warning
7275 messages generated by the front end. This pragma can also be applied to
7276 warnings provided by the back end and mentioned in :ref:`Pragma_Warnings`.
7277 By using a single full *-Wxxx* switch in the pragma, such warnings
7278 can also be treated as errors.
7280 The pragma can appear either in a global configuration pragma file
7281 (e.g. :file:`gnat.adc`), or at the start of a file. Given a global
7282 configuration pragma file containing:
7287 pragma Warning_As_Error ("[-gnatwj]");
7290 which will treat all obsolescent feature warnings as errors, the
7291 following program compiles as shown (compile options here are
7292 *-gnatwa.d -gnatl -gnatj55*).
7297 1. pragma Warning_As_Error ("*never assigned*");
7298 2. function Warnerr return String is
7301 >>> error: variable "X" is never read and
7302 never assigned [-gnatwv] [warning-as-error]
7306 >>> warning: variable "Y" is assigned but
7307 never read [-gnatwu]
7313 >>> error: use of "%" is an obsolescent
7314 feature (RM J.2(4)), use """ instead
7315 [-gnatwj] [warning-as-error]
7319 8 lines: No errors, 3 warnings (2 treated as errors)
7322 Note that this pragma does not affect the set of warnings issued in
7323 any way, it merely changes the effect of a matching warning if one
7324 is produced as a result of other warnings options. As shown in this
7325 example, if the pragma results in a warning being treated as an error,
7326 the tag is changed from "warning:" to "error:" and the string
7327 "[warning-as-error]" is appended to the end of the message.
7329 .. _Pragma_Warnings:
7339 pragma Warnings ([TOOL_NAME,] DETAILS [, REASON]);
7341 DETAILS ::= On | Off
7342 DETAILS ::= On | Off, local_NAME
7343 DETAILS ::= static_string_EXPRESSION
7344 DETAILS ::= On | Off, static_string_EXPRESSION
7346 TOOL_NAME ::= GNAT | GNATProve
7348 REASON ::= Reason => STRING_LITERAL {& STRING_LITERAL}
7350 Note: in Ada 83 mode, a string literal may be used in place of a static string
7351 expression (which does not exist in Ada 83).
7353 Note if the second argument of ``DETAILS`` is a ``local_NAME`` then the
7354 second form is always understood. If the intention is to use
7355 the fourth form, then you can write ``NAME & ""`` to force the
7356 intepretation as a *static_string_EXPRESSION*.
7358 Note: if the first argument is a valid ``TOOL_NAME``, it will be interpreted
7359 that way. The use of the ``TOOL_NAME`` argument is relevant only to users
7360 of SPARK and GNATprove, see last part of this section for details.
7362 Normally warnings are enabled, with the output being controlled by
7363 the command line switch. Warnings (``Off``) turns off generation of
7364 warnings until a Warnings (``On``) is encountered or the end of the
7365 current unit. If generation of warnings is turned off using this
7366 pragma, then some or all of the warning messages are suppressed,
7367 regardless of the setting of the command line switches.
7369 The ``Reason`` parameter may optionally appear as the last argument
7370 in any of the forms of this pragma. It is intended purely for the
7371 purposes of documenting the reason for the ``Warnings`` pragma.
7372 The compiler will check that the argument is a static string but
7373 otherwise ignore this argument. Other tools may provide specialized
7374 processing for this string.
7376 The form with a single argument (or two arguments if Reason present),
7377 where the first argument is ``ON`` or ``OFF``
7378 may be used as a configuration pragma.
7380 If the ``LOCAL_NAME`` parameter is present, warnings are suppressed for
7381 the specified entity. This suppression is effective from the point where
7382 it occurs till the end of the extended scope of the variable (similar to
7383 the scope of ``Suppress``). This form cannot be used as a configuration
7386 In the case where the first argument is other than ``ON`` or
7388 the third form with a single static_string_EXPRESSION argument (and possible
7389 reason) provides more precise
7390 control over which warnings are active. The string is a list of letters
7391 specifying which warnings are to be activated and which deactivated. The
7392 code for these letters is the same as the string used in the command
7393 line switch controlling warnings. For a brief summary, use the gnatmake
7394 command with no arguments, which will generate usage information containing
7395 the list of warnings switches supported. For
7396 full details see the section on ``Warning Message Control`` in the
7397 :title:`GNAT User's Guide`.
7398 This form can also be used as a configuration pragma.
7400 The warnings controlled by the :switch:`-gnatw` switch are generated by the
7401 front end of the compiler. The GCC back end can provide additional warnings
7402 and they are controlled by the :switch:`-W` switch. Such warnings can be
7403 identified by the appearance of a string of the form ``[-W{xxx}]`` in the
7404 message which designates the :switch:`-W{xxx}` switch that controls the message.
7405 The form with a single *static_string_EXPRESSION* argument also works for these
7406 warnings, but the string must be a single full :switch:`-W{xxx}` switch in this
7407 case. The above reference lists a few examples of these additional warnings.
7409 The specified warnings will be in effect until the end of the program
7410 or another pragma ``Warnings`` is encountered. The effect of the pragma is
7411 cumulative. Initially the set of warnings is the standard default set
7412 as possibly modified by compiler switches. Then each pragma Warning
7413 modifies this set of warnings as specified. This form of the pragma may
7414 also be used as a configuration pragma.
7416 The fourth form, with an ``On|Off`` parameter and a string, is used to
7417 control individual messages, based on their text. The string argument
7418 is a pattern that is used to match against the text of individual
7419 warning messages (not including the initial "warning: " tag).
7421 The pattern may contain asterisks, which match zero or more characters in
7422 the message. For example, you can use
7423 ``pragma Warnings (Off, "bits of*unused")`` to suppress the warning
7424 message ``warning: 960 bits of "a" unused``. No other regular
7425 expression notations are permitted. All characters other than asterisk in
7426 these three specific cases are treated as literal characters in the match.
7427 The match is case insensitive, for example XYZ matches xyz.
7429 Note that the pattern matches if it occurs anywhere within the warning
7430 message string (it is not necessary to put an asterisk at the start and
7431 the end of the message, since this is implied).
7433 The above use of patterns to match the message applies only to warning
7434 messages generated by the front end. This form of the pragma with a string
7435 argument can also be used to control warnings provided by the back end and
7436 mentioned above. By using a single full :switch:`-W{xxx}` switch in the pragma,
7437 such warnings can be turned on and off.
7439 There are two ways to use the pragma in this form. The OFF form can be used
7440 as a configuration pragma. The effect is to suppress all warnings (if any)
7441 that match the pattern string throughout the compilation (or match the
7442 -W switch in the back end case).
7444 The second usage is to suppress a warning locally, and in this case, two
7445 pragmas must appear in sequence:
7450 pragma Warnings (Off, Pattern);
7451 ... code where given warning is to be suppressed
7452 pragma Warnings (On, Pattern);
7455 In this usage, the pattern string must match in the Off and On
7456 pragmas, and (if *-gnatw.w* is given) at least one matching
7457 warning must be suppressed.
7459 Note: if the ON form is not found, then the effect of the OFF form extends
7460 until the end of the file (pragma Warnings is purely textual, so its effect
7461 does not stop at the end of the enclosing scope).
7463 Note: to write a string that will match any warning, use the string
7464 ``"***"``. It will not work to use a single asterisk or two
7465 asterisks since this looks like an operator name. This form with three
7466 asterisks is similar in effect to specifying ``pragma Warnings (Off)`` except (if :switch:`-gnatw.w` is given) that a matching
7467 ``pragma Warnings (On, "***")`` will be required. This can be
7468 helpful in avoiding forgetting to turn warnings back on.
7470 Note: the debug flag :switch:`-gnatd.i` (``/NOWARNINGS_PRAGMAS`` in VMS) can be
7471 used to cause the compiler to entirely ignore all WARNINGS pragmas. This can
7472 be useful in checking whether obsolete pragmas in existing programs are hiding
7475 Note: pragma Warnings does not affect the processing of style messages. See
7476 separate entry for pragma Style_Checks for control of style messages.
7478 Users of the formal verification tool GNATprove for the SPARK subset of Ada may
7479 use the version of the pragma with a ``TOOL_NAME`` parameter.
7481 If present, ``TOOL_NAME`` is the name of a tool, currently either ``GNAT`` for the
7482 compiler or ``GNATprove`` for the formal verification tool. A given tool only
7483 takes into account pragma Warnings that do not specify a tool name, or that
7484 specify the matching tool name. This makes it possible to disable warnings
7485 selectively for each tool, and as a consequence to detect useless pragma
7486 Warnings with switch :switch:`-gnatw.w`.
7488 Pragma Weak_External
7489 ====================
7496 pragma Weak_External ([Entity =>] LOCAL_NAME);
7499 ``LOCAL_NAME`` must refer to an object that is declared at the library
7500 level. This pragma specifies that the given entity should be marked as a
7501 weak symbol for the linker. It is equivalent to ``__attribute__((weak))``
7502 in GNU C and causes ``LOCAL_NAME`` to be emitted as a weak symbol instead
7503 of a regular symbol, that is to say a symbol that does not have to be
7504 resolved by the linker if used in conjunction with a pragma Import.
7506 When a weak symbol is not resolved by the linker, its address is set to
7507 zero. This is useful in writing interfaces to external modules that may
7508 or may not be linked in the final executable, for example depending on
7509 configuration settings.
7511 If a program references at run time an entity to which this pragma has been
7512 applied, and the corresponding symbol was not resolved at link time, then
7513 the execution of the program is erroneous. It is not erroneous to take the
7514 Address of such an entity, for example to guard potential references,
7515 as shown in the example below.
7517 Some file formats do not support weak symbols so not all target machines
7518 support this pragma.
7523 -- Example of the use of pragma Weak_External
7525 package External_Module is
7527 pragma Import (C, key);
7528 pragma Weak_External (key);
7529 function Present return boolean;
7530 end External_Module;
7532 with System; use System;
7533 package body External_Module is
7534 function Present return boolean is
7536 return key'Address /= System.Null_Address;
7538 end External_Module;
7541 Pragma Wide_Character_Encoding
7542 ==============================
7549 pragma Wide_Character_Encoding (IDENTIFIER | CHARACTER_LITERAL);
7552 This pragma specifies the wide character encoding to be used in program
7553 source text appearing subsequently. It is a configuration pragma, but may
7554 also be used at any point that a pragma is allowed, and it is permissible
7555 to have more than one such pragma in a file, allowing multiple encodings
7556 to appear within the same file.
7558 However, note that the pragma cannot immediately precede the relevant
7559 wide character, because then the previous encoding will still be in
7560 effect, causing "illegal character" errors.
7562 The argument can be an identifier or a character literal. In the identifier
7563 case, it is one of ``HEX``, ``UPPER``, ``SHIFT_JIS``,
7564 ``EUC``, ``UTF8``, or ``BRACKETS``. In the character literal
7565 case it is correspondingly one of the characters :kbd:`h`, :kbd:`u`,
7566 :kbd:`s`, :kbd:`e`, :kbd:`8`, or :kbd:`b`.
7568 Note that when the pragma is used within a file, it affects only the
7569 encoding within that file, and does not affect withed units, specs,