1.. role:: switch(samp) 2 3.. _Implementation_Defined_Pragmas: 4 5****************************** 6Implementation Defined Pragmas 7****************************** 8 9Ada defines a set of pragmas that can be used to supply additional 10information to the compiler. These language defined pragmas are 11implemented in GNAT and work as described in the Ada Reference Manual. 12 13In addition, Ada allows implementations to define additional pragmas 14whose meaning is defined by the implementation. GNAT provides a number 15of these implementation-defined pragmas, which can be used to extend 16and enhance the functionality of the compiler. This section of the GNAT 17Reference Manual describes these additional pragmas. 18 19Note that any program using these pragmas might not be portable to other 20compilers (although GNAT implements this set of pragmas on all 21platforms). Therefore if portability to other compilers is an important 22consideration, the use of these pragmas should be minimized. 23 24Pragma Abort_Defer 25================== 26 27.. index:: Deferring aborts 28 29Syntax: 30 31.. code-block:: ada 32 33 pragma Abort_Defer; 34 35 36This pragma must appear at the start of the statement sequence of a 37handled sequence of statements (right after the ``begin``). It has 38the effect of deferring aborts for the sequence of statements (but not 39for the declarations or handlers, if any, associated with this statement 40sequence). 41 42.. _Pragma-Abstract_State: 43 44Pragma Abstract_State 45===================== 46 47Syntax: 48 49.. code-block:: ada 50 51 pragma Abstract_State (ABSTRACT_STATE_LIST); 52 53 ABSTRACT_STATE_LIST ::= 54 null 55 | STATE_NAME_WITH_OPTIONS 56 | (STATE_NAME_WITH_OPTIONS {, STATE_NAME_WITH_OPTIONS} ) 57 58 STATE_NAME_WITH_OPTIONS ::= 59 STATE_NAME 60 | (STATE_NAME with OPTION_LIST) 61 62 OPTION_LIST ::= OPTION {, OPTION} 63 64 OPTION ::= 65 SIMPLE_OPTION 66 | NAME_VALUE_OPTION 67 68 SIMPLE_OPTION ::= Ghost | Synchronous 69 70 NAME_VALUE_OPTION ::= 71 Part_Of => ABSTRACT_STATE 72 | External [=> EXTERNAL_PROPERTY_LIST] 73 74 EXTERNAL_PROPERTY_LIST ::= 75 EXTERNAL_PROPERTY 76 | (EXTERNAL_PROPERTY {, EXTERNAL_PROPERTY} ) 77 78 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 84 85 STATE_NAME ::= defining_identifier 86 87 ABSTRACT_STATE ::= name 88 89For the semantics of this pragma, see the entry for aspect ``Abstract_State`` in 90the SPARK 2014 Reference Manual, section 7.1.4. 91 92Pragma Ada_83 93============= 94 95Syntax: 96 97.. code-block:: ada 98 99 pragma Ada_83; 100 101 102A configuration pragma that establishes Ada 83 mode for the unit to 103which it applies, regardless of the mode set by the command line 104switches. In Ada 83 mode, GNAT attempts to be as compatible with 105the syntax and semantics of Ada 83, as defined in the original Ada 10683 Reference Manual as possible. In particular, the keywords added by Ada 95 107and Ada 2005 are not recognized, optional package bodies are allowed, 108and generics may name types with unknown discriminants without using 109the ``(<>)`` notation. In addition, some but not all of the additional 110restrictions of Ada 83 are enforced. 111 112Ada 83 mode is intended for two purposes. Firstly, it allows existing 113Ada 83 code to be compiled and adapted to GNAT with less effort. 114Secondly, it aids in keeping code backwards compatible with Ada 83. 115However, there is no guarantee that code that is processed correctly 116by GNAT in Ada 83 mode will in fact compile and execute with an Ada 11783 compiler, since GNAT does not enforce all the additional checks 118required by Ada 83. 119 120Pragma Ada_95 121============= 122 123Syntax: 124 125.. code-block:: ada 126 127 pragma Ada_95; 128 129 130A configuration pragma that establishes Ada 95 mode for the unit to which 131it applies, regardless of the mode set by the command line switches. 132This mode is set automatically for the ``Ada`` and ``System`` 133packages and their children, so you need not specify it in these 134contexts. This pragma is useful when writing a reusable component that 135itself uses Ada 95 features, but which is intended to be usable from 136either Ada 83 or Ada 95 programs. 137 138Pragma Ada_05 139============= 140 141Syntax: 142 143.. code-block:: ada 144 145 pragma Ada_05; 146 pragma Ada_05 (local_NAME); 147 148 149A configuration pragma that establishes Ada 2005 mode for the unit to which 150it applies, regardless of the mode set by the command line switches. 151This pragma is useful when writing a reusable component that 152itself uses Ada 2005 features, but which is intended to be usable from 153either Ada 83 or Ada 95 programs. 154 155The one argument form (which is not a configuration pragma) 156is used for managing the transition from 157Ada 95 to Ada 2005 in the run-time library. If an entity is marked 158as Ada_2005 only, then referencing the entity in Ada_83 or Ada_95 159mode will generate a warning. In addition, in Ada_83 or Ada_95 160mode, a preference rule is established which does not choose 161such an entity unless it is unambiguously specified. This avoids 162extra subprograms marked this way from generating ambiguities in 163otherwise legal pre-Ada_2005 programs. The one argument form is 164intended for exclusive use in the GNAT run-time library. 165 166Pragma Ada_2005 167=============== 168 169Syntax: 170 171.. code-block:: ada 172 173 pragma Ada_2005; 174 175 176This configuration pragma is a synonym for pragma Ada_05 and has the 177same syntax and effect. 178 179Pragma Ada_12 180============= 181 182Syntax: 183 184.. code-block:: ada 185 186 pragma Ada_12; 187 pragma Ada_12 (local_NAME); 188 189 190A configuration pragma that establishes Ada 2012 mode for the unit to which 191it applies, regardless of the mode set by the command line switches. 192This mode is set automatically for the ``Ada`` and ``System`` 193packages and their children, so you need not specify it in these 194contexts. This pragma is useful when writing a reusable component that 195itself uses Ada 2012 features, but which is intended to be usable from 196Ada 83, Ada 95, or Ada 2005 programs. 197 198The one argument form, which is not a configuration pragma, 199is used for managing the transition from Ada 2002005 to Ada 2012 in the run-time library. If an entity is marked 201as Ada_2012 only, then referencing the entity in any pre-Ada_2012 202mode will generate a warning. In addition, in any pre-Ada_2012 203mode, a preference rule is established which does not choose 204such an entity unless it is unambiguously specified. This avoids 205extra subprograms marked this way from generating ambiguities in 206otherwise legal pre-Ada_2012 programs. The one argument form is 207intended for exclusive use in the GNAT run-time library. 208 209Pragma Ada_2012 210=============== 211 212Syntax: 213 214.. code-block:: ada 215 216 pragma Ada_2012; 217 218 219This configuration pragma is a synonym for pragma Ada_12 and has the 220same syntax and effect. 221 222Pragma Allow_Integer_Address 223============================ 224 225Syntax: 226 227.. code-block:: ada 228 229 pragma Allow_Integer_Address; 230 231 232In almost all versions of GNAT, ``System.Address`` is a private 233type in accordance with the implementation advice in the RM. This 234means that integer values, 235in particular integer literals, are not allowed as address values. 236If the configuration pragma 237``Allow_Integer_Address`` is given, then integer expressions may 238be used anywhere a value of type ``System.Address`` is required. 239The effect is to introduce an implicit unchecked conversion from the 240integer value to type ``System.Address``. The reverse case of using 241an address where an integer type is required is handled analogously. 242The following example compiles without errors: 243 244 245.. code-block:: ada 246 247 pragma Allow_Integer_Address; 248 with System; use System; 249 package AddrAsInt is 250 X : Integer; 251 Y : Integer; 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; 260 RR : R := 1000; 261 Z : Integer; 262 for Z'Address use RR; 263 end AddrAsInt; 264 265 266Note that pragma ``Allow_Integer_Address`` is ignored if ``System.Address`` 267is not a private type. In implementations of ``GNAT`` where 268System.Address is a visible integer type, 269this pragma serves no purpose but is ignored 270rather than rejected to allow common sets of sources to be used 271in the two situations. 272 273.. _Pragma-Annotate: 274 275Pragma Annotate 276=============== 277 278Syntax:: 279 280 pragma Annotate (IDENTIFIER [, IDENTIFIER {, ARG}] [, entity => local_NAME]); 281 282 ARG ::= NAME | EXPRESSION 283 284 285This pragma is used to annotate programs. IDENTIFIER identifies 286the type of annotation. GNAT verifies that it is an identifier, but does 287not otherwise analyze it. The second optional identifier is also left 288unanalyzed, and by convention is used to control the action of the tool to 289which the annotation is addressed. The remaining ARG arguments 290can be either string literals or more generally expressions. 291String literals are assumed to be either of type 292``Standard.String`` or else ``Wide_String`` or ``Wide_Wide_String`` 293depending on the character literals they contain. 294All other kinds of arguments are analyzed as expressions, and must be 295unambiguous. The last argument if present must have the identifier 296``Entity`` and GNAT verifies that a local name is given. 297 298The analyzed pragma is retained in the tree, but not otherwise processed 299by any part of the GNAT compiler, except to generate corresponding note 300lines in the generated ALI file. For the format of these note lines, see 301the compiler source file lib-writ.ads. This pragma is intended for use by 302external tools, including ASIS. The use of pragma Annotate does not 303affect the compilation process in any way. This pragma may be used as 304a configuration pragma. 305 306Pragma Assert 307============= 308 309Syntax:: 310 311 pragma Assert ( 312 boolean_EXPRESSION 313 [, string_EXPRESSION]); 314 315 316The effect of this pragma depends on whether the corresponding command 317line switch is set to activate assertions. The pragma expands into code 318equivalent to the following: 319 320.. code-block:: ada 321 322 if assertions-enabled then 323 if not boolean_EXPRESSION then 324 System.Assertions.Raise_Assert_Failure 325 (string_EXPRESSION); 326 end if; 327 end if; 328 329 330The string argument, if given, is the message that will be associated 331with the exception occurrence if the exception is raised. If no second 332argument is given, the default message is ``file``:``nnn``, 333where ``file`` is the name of the source file containing the assert, 334and ``nnn`` is the line number of the assert. 335 336Note that, as with the ``if`` statement to which it is equivalent, the 337type of the expression is either ``Standard.Boolean``, or any type derived 338from this standard type. 339 340Assert checks can be either checked or ignored. By default they are ignored. 341They will be checked if either the command line switch *-gnata* is 342used, or if an ``Assertion_Policy`` or ``Check_Policy`` pragma is used 343to enable ``Assert_Checks``. 344 345If assertions are ignored, then there 346is no run-time effect (and in particular, any side effects from the 347expression will not occur at run time). (The expression is still 348analyzed at compile time, and may cause types to be frozen if they are 349mentioned here for the first time). 350 351If assertions are checked, then the given expression is tested, and if 352it is ``False`` then ``System.Assertions.Raise_Assert_Failure`` is called 353which results in the raising of ``Assert_Failure`` with the given message. 354 355You should generally avoid side effects in the expression arguments of 356this pragma, because these side effects will turn on and off with the 357setting of the assertions mode, resulting in assertions that have an 358effect on the program. However, the expressions are analyzed for 359semantic correctness whether or not assertions are enabled, so turning 360assertions on and off cannot affect the legality of a program. 361 362Note that the implementation defined policy ``DISABLE``, given in a 363pragma ``Assertion_Policy``, can be used to suppress this semantic analysis. 364 365Note: this is a standard language-defined pragma in versions 366of Ada from 2005 on. In GNAT, it is implemented in all versions 367of Ada, and the DISABLE policy is an implementation-defined 368addition. 369 370Pragma Assert_And_Cut 371===================== 372 373Syntax:: 374 375 pragma Assert_And_Cut ( 376 boolean_EXPRESSION 377 [, string_EXPRESSION]); 378 379 380The effect of this pragma is identical to that of pragma ``Assert``, 381except that in an ``Assertion_Policy`` pragma, the identifier 382``Assert_And_Cut`` is used to control whether it is ignored or checked 383(or disabled). 384 385The intention is that this be used within a subprogram when the 386given test expresion sums up all the work done so far in the 387subprogram, so that the rest of the subprogram can be verified 388(informally or formally) using only the entry preconditions, 389and the expression in this pragma. This allows dividing up 390a subprogram into sections for the purposes of testing or 391formal verification. The pragma also serves as useful 392documentation. 393 394Pragma Assertion_Policy 395======================= 396 397Syntax:: 398 399 pragma Assertion_Policy (CHECK | DISABLE | IGNORE); 400 401 pragma Assertion_Policy ( 402 ASSERTION_KIND => POLICY_IDENTIFIER 403 {, ASSERTION_KIND => POLICY_IDENTIFIER}); 404 405 ASSERTION_KIND ::= RM_ASSERTION_KIND | ID_ASSERTION_KIND 406 407 RM_ASSERTION_KIND ::= Assert | 408 Static_Predicate | 409 Dynamic_Predicate | 410 Pre | 411 Pre'Class | 412 Post | 413 Post'Class | 414 Type_Invariant | 415 Type_Invariant'Class 416 417 ID_ASSERTION_KIND ::= Assertions | 418 Assert_And_Cut | 419 Assume | 420 Contract_Cases | 421 Debug | 422 Ghost | 423 Invariant | 424 Invariant'Class | 425 Loop_Invariant | 426 Loop_Variant | 427 Postcondition | 428 Precondition | 429 Predicate | 430 Refined_Post | 431 Statement_Assertions 432 433 POLICY_IDENTIFIER ::= Check | Disable | Ignore | Suppressible 434 435 436This is a standard Ada 2012 pragma that is available as an 437implementation-defined pragma in earlier versions of Ada. 438The assertion kinds ``RM_ASSERTION_KIND`` are those defined in 439the Ada standard. The assertion kinds ``ID_ASSERTION_KIND`` 440are implementation defined additions recognized by the GNAT compiler. 441 442The pragma applies in both cases to pragmas and aspects with matching 443names, e.g. ``Pre`` applies to the Pre aspect, and ``Precondition`` 444applies to both the ``Precondition`` pragma 445and the aspect ``Precondition``. Note that the identifiers for 446pragmas Pre_Class and Post_Class are Pre'Class and Post'Class (not 447Pre_Class and Post_Class), since these pragmas are intended to be 448identical to the corresponding aspects). 449 450If the policy is ``CHECK``, then assertions are enabled, i.e. 451the corresponding pragma or aspect is activated. 452If the policy is ``IGNORE``, then assertions are ignored, i.e. 453the corresponding pragma or aspect is deactivated. 454This pragma overrides the effect of the *-gnata* switch on the 455command line. 456If the policy is ``SUPPRESSIBLE``, then assertions are enabled by default, 457however, if the *-gnatp* switch is specified all assertions are ignored. 458 459The implementation defined policy ``DISABLE`` is like 460``IGNORE`` except that it completely disables semantic 461checking of the corresponding pragma or aspect. This is 462useful when the pragma or aspect argument references subprograms 463in a with'ed package which is replaced by a dummy package 464for the final build. 465 466The implementation defined assertion kind ``Assertions`` applies to all 467assertion kinds. The form with no assertion kind given implies this 468choice, so it applies to all assertion kinds (RM defined, and 469implementation defined). 470 471The implementation defined assertion kind ``Statement_Assertions`` 472applies to ``Assert``, ``Assert_And_Cut``, 473``Assume``, ``Loop_Invariant``, and ``Loop_Variant``. 474 475Pragma Assume 476============= 477 478Syntax: 479 480:: 481 482 pragma Assume ( 483 boolean_EXPRESSION 484 [, string_EXPRESSION]); 485 486 487The effect of this pragma is identical to that of pragma ``Assert``, 488except that in an ``Assertion_Policy`` pragma, the identifier 489``Assume`` is used to control whether it is ignored or checked 490(or disabled). 491 492The intention is that this be used for assumptions about the 493external environment. So you cannot expect to verify formally 494or informally that the condition is met, this must be 495established by examining things outside the program itself. 496For example, we may have code that depends on the size of 497``Long_Long_Integer`` being at least 64. So we could write: 498 499.. code-block:: ada 500 501 pragma Assume (Long_Long_Integer'Size >= 64); 502 503 504This assumption cannot be proved from the program itself, 505but it acts as a useful run-time check that the assumption 506is met, and documents the need to ensure that it is met by 507reference to information outside the program. 508 509Pragma Assume_No_Invalid_Values 510=============================== 511.. index:: Invalid representations 512 513.. index:: Invalid values 514 515Syntax: 516 517.. code-block:: ada 518 519 pragma Assume_No_Invalid_Values (On | Off); 520 521 522This is a configuration pragma that controls the assumptions made by the 523compiler about the occurrence of invalid representations (invalid values) 524in the code. 525 526The default behavior (corresponding to an Off argument for this pragma), is 527to assume that values may in general be invalid unless the compiler can 528prove they are valid. Consider the following example: 529 530.. code-block:: ada 531 532 V1 : Integer range 1 .. 10; 533 V2 : Integer range 11 .. 20; 534 ... 535 for J in V2 .. V1 loop 536 ... 537 end loop; 538 539 540if V1 and V2 have valid values, then the loop is known at compile 541time not to execute since the lower bound must be greater than the 542upper bound. However in default mode, no such assumption is made, 543and the loop may execute. If ``Assume_No_Invalid_Values (On)`` 544is given, the compiler will assume that any occurrence of a variable 545other than in an explicit ``'Valid`` test always has a valid 546value, and the loop above will be optimized away. 547 548The use of ``Assume_No_Invalid_Values (On)`` is appropriate if 549you know your code is free of uninitialized variables and other 550possible sources of invalid representations, and may result in 551more efficient code. A program that accesses an invalid representation 552with this pragma in effect is erroneous, so no guarantees can be made 553about its behavior. 554 555It is peculiar though permissible to use this pragma in conjunction 556with validity checking (-gnatVa). In such cases, accessing invalid 557values will generally give an exception, though formally the program 558is erroneous so there are no guarantees that this will always be the 559case, and it is recommended that these two options not be used together. 560 561.. _Pragma-Async_Readers: 562 563Pragma Async_Readers 564==================== 565 566Syntax: 567 568.. code-block:: ada 569 570 pragma Asynch_Readers [ (boolean_EXPRESSION) ]; 571 572For the semantics of this pragma, see the entry for aspect ``Async_Readers`` in 573the SPARK 2014 Reference Manual, section 7.1.2. 574 575.. _Pragma-Async_Writers: 576 577Pragma Async_Writers 578==================== 579 580Syntax: 581 582.. code-block:: ada 583 584 pragma Asynch_Writers [ (boolean_EXPRESSION) ]; 585 586For the semantics of this pragma, see the entry for aspect ``Async_Writers`` in 587the SPARK 2014 Reference Manual, section 7.1.2. 588 589Pragma Attribute_Definition 590=========================== 591 592Syntax: 593 594:: 595 596 pragma Attribute_Definition 597 ([Attribute =>] ATTRIBUTE_DESIGNATOR, 598 [Entity =>] LOCAL_NAME, 599 [Expression =>] EXPRESSION | NAME); 600 601 602If ``Attribute`` is a known attribute name, this pragma is equivalent to 603the attribute definition clause: 604 605 606.. code-block:: ada 607 608 for Entity'Attribute use Expression; 609 610 611If ``Attribute`` is not a recognized attribute name, the pragma is 612ignored, and a warning is emitted. This allows source 613code to be written that takes advantage of some new attribute, while remaining 614compilable with earlier compilers. 615 616Pragma C_Pass_By_Copy 617===================== 618.. index:: Passing by copy 619 620 621Syntax: 622 623:: 624 625 pragma C_Pass_By_Copy 626 ([Max_Size =>] static_integer_EXPRESSION); 627 628 629Normally the default mechanism for passing C convention records to C 630convention subprograms is to pass them by reference, as suggested by RM 631B.3(69). Use the configuration pragma ``C_Pass_By_Copy`` to change 632this default, by requiring that record formal parameters be passed by 633copy if all of the following conditions are met: 634 635* 636 The size of the record type does not exceed the value specified for 637 ``Max_Size``. 638* 639 The record type has ``Convention C``. 640* 641 The formal parameter has this record type, and the subprogram has a 642 foreign (non-Ada) convention. 643 644If these conditions are met the argument is passed by copy; i.e., in a 645manner consistent with what C expects if the corresponding formal in the 646C prototype is a struct (rather than a pointer to a struct). 647 648You 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 651passing mechanisms on a parameter by parameter basis. 652 653Pragma Check 654============ 655.. index:: Assertions 656 657.. index:: Named assertions 658 659 660Syntax: 661 662:: 663 664 pragma Check ( 665 [Name =>] CHECK_KIND, 666 [Check =>] Boolean_EXPRESSION 667 [, [Message =>] string_EXPRESSION] ); 668 669 CHECK_KIND ::= IDENTIFIER | 670 Pre'Class | 671 Post'Class | 672 Type_Invariant'Class | 673 Invariant'Class 674 675 676This pragma is similar to the predefined pragma ``Assert`` except that an 677extra identifier argument is present. In conjunction with pragma 678``Check_Policy``, this can be used to define groups of assertions that can 679be independently controlled. The identifier ``Assertion`` is special, it 680refers to the normal set of pragma ``Assert`` statements. 681 682Checks introduced by this pragma are normally deactivated by default. They can 683be activated either by the command line option *-gnata*, which turns on 684all checks, or individually controlled using pragma ``Check_Policy``. 685 686The identifiers ``Assertions`` and ``Statement_Assertions`` are not 687permitted as check kinds, since this would cause confusion with the use 688of these identifiers in ``Assertion_Policy`` and ``Check_Policy`` 689pragmas, where they are used to refer to sets of assertions. 690 691Pragma Check_Float_Overflow 692=========================== 693.. index:: Floating-point overflow 694 695 696Syntax: 697 698.. code-block:: ada 699 700 pragma Check_Float_Overflow; 701 702 703In Ada, the predefined floating-point types (``Short_Float``, 704``Float``, ``Long_Float``, ``Long_Long_Float``) are 705defined to be *unconstrained*. This means that even though each 706has a well-defined base range, an operation that delivers a result 707outside this base range is not required to raise an exception. 708This implementation permission accommodates the notion 709of infinities in IEEE floating-point, and corresponds to the 710efficient execution mode on most machines. GNAT will not raise 711overflow exceptions on these machines; instead it will generate 712infinities and NaN's as defined in the IEEE standard. 713 714Generating infinities, although efficient, is not always desirable. 715Often the preferable approach is to check for overflow, even at the 716(perhaps considerable) expense of run-time performance. 717This can be accomplished by defining your own constrained floating-point subtypes -- i.e., by supplying explicit 718range constraints -- and indeed such a subtype 719can have the same base range as its base type. For example: 720 721 722.. code-block:: ada 723 724 subtype My_Float is Float range Float'Range; 725 726 727Here ``My_Float`` has the same range as 728``Float`` but is constrained, so operations on 729``My_Float`` values will be checked for overflow 730against this range. 731 732This style will achieve the desired goal, but 733it is often more convenient to be able to simply use 734the standard predefined floating-point types as long 735as overflow checking could be guaranteed. 736The ``Check_Float_Overflow`` 737configuration pragma achieves this effect. If a unit is compiled 738subject to this configuration pragma, then all operations 739on predefined floating-point types including operations on 740base types of these floating-point types will be treated as 741though those types were constrained, and overflow checks 742will be generated. The ``Constraint_Error`` 743exception is raised if the result is out of range. 744 745This mode can also be set by use of the compiler 746switch *-gnateF*. 747 748Pragma Check_Name 749================= 750.. index:: Defining check names 751 752.. index:: Check names, defining 753 754 755Syntax: 756 757.. code-block:: ada 758 759 pragma Check_Name (check_name_IDENTIFIER); 760 761 762This is a configuration pragma that defines a new implementation 763defined check name (unless IDENTIFIER matches one of the predefined 764check names, in which case the pragma has no effect). Check names 765are global to a partition, so if two or more configuration pragmas 766are present in a partition mentioning the same name, only one new 767check name is introduced. 768 769An implementation defined check name introduced with this pragma may 770be used in only three contexts: ``pragma Suppress``, 771``pragma Unsuppress``, 772and as the prefix of a ``Check_Name'Enabled`` attribute reference. For 773any of these three cases, the check name must be visible. A check 774name is visible if it is in the configuration pragmas applying to 775the current unit, or if it appears at the start of any unit that 776is part of the dependency set of the current unit (e.g., units that 777are mentioned in ``with`` clauses). 778 779Check names introduced by this pragma are subject to control by compiler 780switches (in particular -gnatp) in the usual manner. 781 782Pragma Check_Policy 783=================== 784.. index:: Controlling assertions 785 786.. index:: Assertions, control 787 788.. index:: Check pragma control 789 790.. index:: Named assertions 791 792 793Syntax: 794 795:: 796 797 pragma Check_Policy 798 ([Name =>] CHECK_KIND, 799 [Policy =>] POLICY_IDENTIFIER); 800 801 pragma Check_Policy ( 802 CHECK_KIND => POLICY_IDENTIFIER 803 {, CHECK_KIND => POLICY_IDENTIFIER}); 804 805 ASSERTION_KIND ::= RM_ASSERTION_KIND | ID_ASSERTION_KIND 806 807 CHECK_KIND ::= IDENTIFIER | 808 Pre'Class | 809 Post'Class | 810 Type_Invariant'Class | 811 Invariant'Class 812 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. 815 816 POLICY_IDENTIFIER ::= ON | OFF | CHECK | DISABLE | IGNORE 817 818 819This pragma is used to set the checking policy for assertions (specified 820by aspects or pragmas), the ``Debug`` pragma, or additional checks 821to be checked using the ``Check`` pragma. It may appear either as 822a configuration pragma, or within a declarative part of package. In the 823latter case, it applies from the point where it appears to the end of 824the declarative region (like pragma ``Suppress``). 825 826The ``Check_Policy`` pragma is similar to the 827predefined ``Assertion_Policy`` pragma, 828and if the check kind corresponds to one of the assertion kinds that 829are allowed by ``Assertion_Policy``, then the effect is identical. 830 831If the first argument is Debug, then the policy applies to Debug pragmas, 832disabling their effect if the policy is ``OFF``, ``DISABLE``, or 833``IGNORE``, and allowing them to execute with normal semantics if 834the policy is ``ON`` or ``CHECK``. In addition if the policy is 835``DISABLE``, then the procedure call in ``Debug`` pragmas will 836be totally ignored and not analyzed semantically. 837 838Finally the first argument may be some other identifier than the above 839possibilities, in which case it controls a set of named assertions 840that can be checked using pragma ``Check``. For example, if the pragma: 841 842 843.. code-block:: ada 844 845 pragma Check_Policy (Critical_Error, OFF); 846 847 848is given, then subsequent ``Check`` pragmas whose first argument is also 849``Critical_Error`` will be disabled. 850 851The check policy is ``OFF`` to turn off corresponding checks, and ``ON`` 852to 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. 855 856The check policy settings ``CHECK`` and ``IGNORE`` are recognized 857as synonyms for ``ON`` and ``OFF``. These synonyms are provided for 858compatibility with the standard ``Assertion_Policy`` pragma. The check 859policy setting ``DISABLE`` causes the second argument of a corresponding 860``Check`` pragma to be completely ignored and not analyzed. 861 862Pragma Comment 863============== 864 865Syntax: 866 867 868.. code-block:: ada 869 870 pragma Comment (static_string_EXPRESSION); 871 872 873This is almost identical in effect to pragma ``Ident``. It allows the 874placement of a comment into the object file and hence into the 875executable file if the operating system permits such usage. The 876difference is that ``Comment``, unlike ``Ident``, has 877no limitations on placement of the pragma (it can be placed 878anywhere in the main source unit), and if more than one pragma 879is used, all comments are retained. 880 881Pragma Common_Object 882==================== 883 884Syntax: 885 886 887:: 888 889 pragma Common_Object ( 890 [Internal =>] LOCAL_NAME 891 [, [External =>] EXTERNAL_SYMBOL] 892 [, [Size =>] EXTERNAL_SYMBOL] ); 893 894 EXTERNAL_SYMBOL ::= 895 IDENTIFIER 896 | static_string_EXPRESSION 897 898 899This pragma enables the shared use of variables stored in overlaid 900linker areas corresponding to the use of ``COMMON`` 901in Fortran. The single 902object ``LOCAL_NAME`` is assigned to the area designated by 903the ``External`` argument. 904You may define a record to correspond to a series 905of fields. The ``Size`` argument 906is syntax checked in GNAT, but otherwise ignored. 907 908``Common_Object`` is not supported on all platforms. If no 909support is available, then the code generator will issue a message 910indicating that the necessary attribute for implementation of this 911pragma is not available. 912 913Pragma Compile_Time_Error 914========================= 915 916Syntax: 917 918 919.. code-block:: ada 920 921 pragma Compile_Time_Error 922 (boolean_EXPRESSION, static_string_EXPRESSION); 923 924 925This pragma can be used to generate additional compile time 926error messages. It 927is particularly useful in generics, where errors can be issued for 928specific problematic instantiations. The first parameter is a boolean 929expression. The pragma is effective only if the value of this expression 930is known at compile time, and has the value True. The set of expressions 931whose values are known at compile time includes all static boolean 932expressions, and also other values which the compiler can determine 933at compile time (e.g., the size of a record type set by an explicit 934size representation clause, or the value of a variable which was 935initialized to a constant and is known not to have been modified). 936If these conditions are met, an error message is generated using 937the value given as the second argument. This string value may contain 938embedded ASCII.LF characters to break the message into multiple lines. 939 940Pragma Compile_Time_Warning 941=========================== 942 943Syntax: 944 945 946.. code-block:: ada 947 948 pragma Compile_Time_Warning 949 (boolean_EXPRESSION, static_string_EXPRESSION); 950 951 952Same as pragma Compile_Time_Error, except a warning is issued instead 953of an error message. Note that if this pragma is used in a package that 954is with'ed by a client, the client will get the warning even though it 955is issued by a with'ed package (normally warnings in with'ed units are 956suppressed, but this is a special exception to that rule). 957 958One typical use is within a generic where compile time known characteristics 959of formal parameters are tested, and warnings given appropriately. Another use 960with a first parameter of True is to warn a client about use of a package, 961for example that it is not fully implemented. 962 963Pragma Compiler_Unit 964==================== 965 966Syntax: 967 968 969.. code-block:: ada 970 971 pragma Compiler_Unit; 972 973 974This pragma is obsolete. It is equivalent to Compiler_Unit_Warning. It is 975retained so that old versions of the GNAT run-time that use this pragma can 976be compiled with newer versions of the compiler. 977 978Pragma Compiler_Unit_Warning 979============================ 980 981Syntax: 982 983 984.. code-block:: ada 985 986 pragma Compiler_Unit_Warning; 987 988 989This pragma is intended only for internal use in the GNAT run-time library. 990It indicates that the unit is used as part of the compiler build. The effect 991is to generate warnings for the use of constructs (for example, conditional 992expressions) that would cause trouble when bootstrapping using an older 993version of GNAT. For the exact list of restrictions, see the compiler sources 994and references to Check_Compiler_Unit. 995 996Pragma Complete_Representation 997============================== 998 999Syntax: 1000 1001 1002.. code-block:: ada 1003 1004 pragma Complete_Representation; 1005 1006 1007This pragma must appear immediately within a record representation 1008clause. Typical placements are before the first component clause 1009or after the last component clause. The effect is to give an error 1010message if any component is missing a component clause. This pragma 1011may be used to ensure that a record representation clause is 1012complete, and that this invariant is maintained if fields are 1013added to the record in the future. 1014 1015Pragma Complex_Representation 1016============================= 1017 1018Syntax: 1019 1020 1021:: 1022 1023 pragma Complex_Representation 1024 ([Entity =>] LOCAL_NAME); 1025 1026 1027The ``Entity`` argument must be the name of a record type which has 1028two fields of the same floating-point type. The effect of this pragma is 1029to force gcc to use the special internal complex representation form for 1030this record, which may be more efficient. Note that this may result in 1031the code for this type not conforming to standard ABI (application 1032binary interface) requirements for the handling of record types. For 1033example, in some environments, there is a requirement for passing 1034records by pointer, and the use of this pragma may result in passing 1035this type in floating-point registers. 1036 1037Pragma Component_Alignment 1038========================== 1039.. index:: Alignments of components 1040.. index:: Pragma Component_Alignment 1041 1042 1043Syntax: 1044 1045:: 1046 1047 pragma Component_Alignment ( 1048 [Form =>] ALIGNMENT_CHOICE 1049 [, [Name =>] type_LOCAL_NAME]); 1050 1051 ALIGNMENT_CHOICE ::= 1052 Component_Size 1053 | Component_Size_4 1054 | Storage_Unit 1055 | Default 1056 1057 1058Specifies the alignment of components in array or record types. 1059The meaning of the ``Form`` argument is as follows: 1060 1061 1062 .. index:: Component_Size (in pragma Component_Alignment) 1063 1064*Component_Size* 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. 1072 1073 .. index:: Component_Size_4 (in pragma Component_Alignment) 1074 1075*Component_Size_4* 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 1078 4-byte boundary. 1079 1080 .. index:: Storage_Unit (in pragma Component_Alignment) 1081 1082*Storage_Unit* 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``. 1086 1087 .. index:: Default (in pragma Component_Alignment) 1088 1089*Default* 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 1093 alignment). 1094 1095If the ``Name`` parameter is present, ``type_LOCAL_NAME`` must 1096refer to a local record or array type, and the specified alignment 1097choice 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 1101is only effective for fields not specified by the representation clause. 1102 1103If the ``Name`` parameter is absent, the pragma can be used as either 1104a configuration pragma, in which case it applies to one or more units in 1105accordance with the normal rules for configuration pragmas, or it can be 1106used within a declarative part, in which case it applies to types that 1107are declared within this declarative part, or within any nested scope 1108within this declarative part. In either case it specifies the alignment 1109to be applied to any record or array type which has otherwise standard 1110representation. 1111 1112If the alignment for a record or array type is not specified (using 1113pragma ``Pack``, pragma ``Component_Alignment``, or a record rep 1114clause), the GNAT uses the default alignment as described previously. 1115 1116.. _Pragma-Constant_After_Elaboration: 1117 1118Pragma Constant_After_Elaboration 1119================================= 1120 1121Syntax: 1122 1123.. code-block:: ada 1124 1125 pragma Constant_After_Elaboration [ (boolean_EXPRESSION) ]; 1126 1127For the semantics of this pragma, see the entry for aspect 1128``Constant_After_Elaboration`` in the SPARK 2014 Reference Manual, section 3.3.1. 1129 1130.. _Pragma-Contract_Cases: 1131 1132Pragma Contract_Cases 1133===================== 1134.. index:: Contract cases 1135 1136Syntax: 1137 1138.. code-block:: ada 1139 1140 pragma Contract_Cases ((CONTRACT_CASE {, CONTRACT_CASE)); 1141 1142 CONTRACT_CASE ::= CASE_GUARD => CONSEQUENCE 1143 1144 CASE_GUARD ::= boolean_EXPRESSION | others 1145 1146 CONSEQUENCE ::= boolean_EXPRESSION 1147 1148The ``Contract_Cases`` pragma allows defining fine-grain specifications 1149that can complement or replace the contract given by a precondition and a 1150postcondition. Additionally, the ``Contract_Cases`` pragma can be used 1151by testing and formal verification tools. The compiler checks its validity and, 1152depending on the assertion policy at the point of declaration of the pragma, 1153it may insert a check in the executable. For code generation, the contract 1154cases 1155 1156 1157.. code-block:: ada 1158 1159 pragma Contract_Cases ( 1160 Cond1 => Pred1, 1161 Cond2 => Pred2); 1162 1163 1164are equivalent to 1165 1166 1167.. code-block:: ada 1168 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); 1174 1175 1176The precondition ensures that one and only one of the conditions is 1177satisfied on entry to the subprogram. 1178The postcondition ensures that for the condition that was True on entry, 1179the corrresponding consequence is True on exit. Other consequence expressions 1180are not evaluated. 1181 1182A precondition ``P`` and postcondition ``Q`` can also be 1183expressed as contract cases: 1184 1185.. code-block:: ada 1186 1187 pragma Contract_Cases (P => Q); 1188 1189 1190The placement and visibility rules for ``Contract_Cases`` pragmas are 1191identical to those described for preconditions and postconditions. 1192 1193The compiler checks that boolean expressions given in conditions and 1194consequences are valid, where the rules for conditions are the same as 1195the rule for an expression in ``Precondition`` and the rules for 1196consequences 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. 1199The condition for the last contract case may be ``others``, to denote 1200any case not captured by the previous cases. The 1201following is an example of use within a package spec: 1202 1203 1204.. code-block:: ada 1205 1206 package Math_Functions is 1207 ... 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)); 1212 ... 1213 end Math_Functions; 1214 1215 1216The meaning of contract cases is that only one case should apply at each 1217call, as determined by the corresponding condition evaluating to True, 1218and that the consequence for this case should hold when the subprogram 1219returns. 1220 1221Pragma Convention_Identifier 1222============================ 1223.. index:: Conventions, synonyms 1224 1225Syntax: 1226 1227 1228:: 1229 1230 pragma Convention_Identifier ( 1231 [Name =>] IDENTIFIER, 1232 [Convention =>] convention_IDENTIFIER); 1233 1234 1235This pragma provides a mechanism for supplying synonyms for existing 1236convention identifiers. The ``Name`` identifier can subsequently 1237be used as a synonym for the given convention in other pragmas (including 1238for example pragma ``Import`` or another ``Convention_Identifier`` 1239pragma). As an example of the use of this, suppose you had legacy code 1240which used Fortran77 as the identifier for Fortran. Then the pragma: 1241 1242 1243.. code-block:: ada 1244 1245 pragma Convention_Identifier (Fortran77, Fortran); 1246 1247 1248would allow the use of the convention identifier ``Fortran77`` in 1249subsequent code, avoiding the need to modify the sources. As another 1250example, you could use this to parameterize convention requirements 1251according to systems. Suppose you needed to use ``Stdcall`` on 1252windows systems, and ``C`` on some other system, then you could 1253define a convention identifier ``Library`` and use a single 1254``Convention_Identifier`` pragma to specify which convention 1255would be used system-wide. 1256 1257Pragma CPP_Class 1258================ 1259.. index:: Interfacing with C++ 1260 1261Syntax: 1262 1263 1264:: 1265 1266 pragma CPP_Class ([Entity =>] LOCAL_NAME); 1267 1268 1269The argument denotes an entity in the current declarative region that is 1270declared as a record type. It indicates that the type corresponds to an 1271externally declared C++ class type, and is to be laid out the same way 1272that C++ would lay out the type. If the C++ class has virtual primitives 1273then the record must be declared as a tagged record type. 1274 1275Types for which ``CPP_Class`` is specified do not have assignment or 1276equality operators defined (such operations can be imported or declared 1277as subprograms as required). Initialization is allowed only by constructor 1278functions (see pragma ``CPP_Constructor``). Such types are implicitly 1279limited if not explicitly declared as limited or derived from a limited 1280type, and an error is issued in that case. 1281 1282See :ref:`Interfacing_to_C++` for related information. 1283 1284Note: Pragma ``CPP_Class`` is currently obsolete. It is supported 1285for backward compatibility but its functionality is available 1286using pragma ``Import`` with ``Convention`` = ``CPP``. 1287 1288Pragma CPP_Constructor 1289====================== 1290.. index:: Interfacing with C++ 1291 1292 1293Syntax: 1294 1295 1296:: 1297 1298 pragma CPP_Constructor ([Entity =>] LOCAL_NAME 1299 [, [External_Name =>] static_string_EXPRESSION ] 1300 [, [Link_Name =>] static_string_EXPRESSION ]); 1301 1302 1303This pragma identifies an imported function (imported in the usual way 1304with 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 1307in a pragma ``Import`` with ``Convention`` = ``CPP``. Such name 1308must be of one of the following forms: 1309 1310* 1311 **function** ``Fname`` **return** T` 1312 1313* 1314 **function** ``Fname`` **return** T'Class 1315 1316* 1317 **function** ``Fname`` (...) **return** T` 1318 1319* 1320 **function** ``Fname`` (...) **return** T'Class 1321 1322where ``T`` is a limited record type imported from C++ with pragma 1323``Import`` and ``Convention`` = ``CPP``. 1324 1325The first two forms import the default constructor, used when an object 1326of type ``T`` is created on the Ada side with no explicit constructor. 1327The latter two forms cover all the non-default constructors of the type. 1328See the GNAT User's Guide for details. 1329 1330If no constructors are imported, it is impossible to create any objects 1331on the Ada side and the type is implicitly declared abstract. 1332 1333Pragma ``CPP_Constructor`` is intended primarily for automatic generation 1334using an automatic binding generator tool (such as the :switch:`-fdump-ada-spec` 1335GCC switch). 1336See :ref:`Interfacing_to_C++` for more related information. 1337 1338Note: The use of functions returning class-wide types for constructors is 1339currently obsolete. They are supported for backward compatibility. The 1340use of functions returning the type T leave the Ada sources more clear 1341because the imported C++ constructors always return an object of type T; 1342that is, they never return an object whose type is a descendant of type T. 1343 1344Pragma CPP_Virtual 1345================== 1346.. index:: Interfacing to C++ 1347 1348 1349This pragma is now obsolete and, other than generating a warning if warnings 1350on obsolescent features are enabled, is completely ignored. 1351It is retained for compatibility 1352purposes. It used to be required to ensure compoatibility with C++, but 1353is no longer required for that purpose because GNAT generates 1354the same object layout as the G++ compiler by default. 1355 1356See :ref:`Interfacing_to_C++` for related information. 1357 1358Pragma CPP_Vtable 1359================= 1360.. index:: Interfacing with C++ 1361 1362 1363This pragma is now obsolete and, other than generating a warning if warnings 1364on obsolescent features are enabled, is completely ignored. 1365It used to be required to ensure compatibility with C++, but 1366is no longer required for that purpose because GNAT generates 1367the same object layout as the G++ compiler by default. 1368 1369See :ref:`Interfacing_to_C++` for related information. 1370 1371Pragma CPU 1372========== 1373 1374Syntax: 1375 1376 1377.. code-block:: ada 1378 1379 pragma CPU (EXPRESSION); 1380 1381 1382This pragma is standard in Ada 2012, but is available in all earlier 1383versions of Ada as an implementation-defined pragma. 1384See Ada 2012 Reference Manual for details. 1385 1386Pragma Deadline_Floor 1387===================== 1388 1389Syntax: 1390 1391 1392.. code-block:: ada 1393 1394 pragma Deadline_Floor (time_span_EXPRESSION); 1395 1396 1397This pragma applies only to protected types and specifies the floor 1398deadline inherited by a task when the task enters a protected object. 1399It is effective only when the EDF scheduling policy is used. 1400 1401.. _Pragma-Default_Initial_Condition: 1402 1403Pragma Default_Initial_Condition 1404================================ 1405 1406Syntax: 1407 1408.. code-block:: ada 1409 1410 pragma Default_Initial_Condition [ (null | boolean_EXPRESSION) ]; 1411 1412For the semantics of this pragma, see the entry for aspect 1413``Default_Initial_Condition`` in the SPARK 2014 Reference Manual, section 7.3.3. 1414 1415Pragma Debug 1416============ 1417 1418Syntax: 1419 1420 1421:: 1422 1423 pragma Debug ([CONDITION, ]PROCEDURE_CALL_WITHOUT_SEMICOLON); 1424 1425 PROCEDURE_CALL_WITHOUT_SEMICOLON ::= 1426 PROCEDURE_NAME 1427 | PROCEDURE_PREFIX ACTUAL_PARAMETER_PART 1428 1429 1430The procedure call argument has the syntactic form of an expression, meeting 1431the syntactic requirements for pragmas. 1432 1433If debug pragmas are not enabled or if the condition is present and evaluates 1434to False, this pragma has no effect. If debug pragmas are enabled, the 1435semantics of the pragma is exactly equivalent to the procedure call statement 1436corresponding to the argument with a terminating semicolon. Pragmas are 1437permitted in sequences of declarations, so you can use pragma ``Debug`` to 1438intersperse calls to debug procedures in the middle of declarations. Debug 1439pragmas can be enabled either by use of the command line switch *-gnata* 1440or by use of the pragma ``Check_Policy`` with a first argument of 1441``Debug``. 1442 1443Pragma Debug_Policy 1444=================== 1445 1446Syntax: 1447 1448 1449.. code-block:: ada 1450 1451 pragma Debug_Policy (CHECK | DISABLE | IGNORE | ON | OFF); 1452 1453 1454This pragma is equivalent to a corresponding ``Check_Policy`` pragma 1455with a first argument of ``Debug``. It is retained for historical 1456compatibility reasons. 1457 1458Pragma Default_Scalar_Storage_Order 1459=================================== 1460.. index:: Default_Scalar_Storage_Order 1461 1462.. index:: Scalar_Storage_Order 1463 1464 1465Syntax: 1466 1467 1468.. code-block:: ada 1469 1470 pragma Default_Scalar_Storage_Order (High_Order_First | Low_Order_First); 1471 1472 1473Normally if no explicit ``Scalar_Storage_Order`` is given for a record 1474type or array type, then the scalar storage order defaults to the ordinary 1475default for the target. But this default may be overridden using this pragma. 1476The pragma may appear as a configuration pragma, or locally within a package 1477spec or declarative part. In the latter case, it applies to all subsequent 1478types declared within that package spec or declarative part. 1479 1480The following example shows the use of this pragma: 1481 1482 1483.. code-block:: ada 1484 1485 pragma Default_Scalar_Storage_Order (High_Order_First); 1486 with System; use System; 1487 package DSSO1 is 1488 type H1 is record 1489 a : Integer; 1490 end record; 1491 1492 type L2 is record 1493 a : Integer; 1494 end record; 1495 for L2'Scalar_Storage_Order use Low_Order_First; 1496 1497 type L2a is new L2; 1498 1499 package Inner is 1500 type H3 is record 1501 a : Integer; 1502 end record; 1503 1504 pragma Default_Scalar_Storage_Order (Low_Order_First); 1505 1506 type L4 is record 1507 a : Integer; 1508 end record; 1509 end Inner; 1510 1511 type H4a is new Inner.L4; 1512 1513 type H5 is record 1514 a : Integer; 1515 end record; 1516 end DSSO1; 1517 1518 1519In this example record types with names starting with *L* have `Low_Order_First` scalar 1520storage order, and record types with names starting with *H* have ``High_Order_First``. 1521Note that in the case of ``H4a``, the order is not inherited 1522from the parent type. Only an explicitly set ``Scalar_Storage_Order`` 1523gets inherited on type derivation. 1524 1525If this pragma is used as a configuration pragma which appears within a 1526configuration pragma file (as opposed to appearing explicitly at the start 1527of a single unit), then the binder will require that all units in a partition 1528be compiled in a similar manner, other than run-time units, which are not 1529affected by this pragma. Note that the use of this form is discouraged because 1530it may significantly degrade the run-time performance of the software, instead 1531the default scalar storage order ought to be changed only on a local basis. 1532 1533Pragma Default_Storage_Pool 1534=========================== 1535.. index:: Default_Storage_Pool 1536 1537 1538Syntax: 1539 1540 1541.. code-block:: ada 1542 1543 pragma Default_Storage_Pool (storage_pool_NAME | null); 1544 1545 1546This pragma is standard in Ada 2012, but is available in all earlier 1547versions of Ada as an implementation-defined pragma. 1548See Ada 2012 Reference Manual for details. 1549 1550.. _Pragma-Depends: 1551 1552Pragma Depends 1553============== 1554 1555Syntax: 1556 1557.. code-block:: ada 1558 1559 pragma Depends (DEPENDENCY_RELATION); 1560 1561 DEPENDENCY_RELATION ::= 1562 null 1563 | (DEPENDENCY_CLAUSE {, DEPENDENCY_CLAUSE}) 1564 1565 DEPENDENCY_CLAUSE ::= 1566 OUTPUT_LIST =>[+] INPUT_LIST 1567 | NULL_DEPENDENCY_CLAUSE 1568 1569 NULL_DEPENDENCY_CLAUSE ::= null => INPUT_LIST 1570 1571 OUTPUT_LIST ::= OUTPUT | (OUTPUT {, OUTPUT}) 1572 1573 INPUT_LIST ::= null | INPUT | (INPUT {, INPUT}) 1574 1575 OUTPUT ::= NAME | FUNCTION_RESULT 1576 INPUT ::= NAME 1577 1578 where FUNCTION_RESULT is a function Result attribute_reference 1579 1580For the semantics of this pragma, see the entry for aspect ``Depends`` in the 1581SPARK 2014 Reference Manual, section 6.1.5. 1582 1583Pragma Detect_Blocking 1584====================== 1585 1586Syntax: 1587 1588.. code-block:: ada 1589 1590 pragma Detect_Blocking; 1591 1592 1593This is a standard pragma in Ada 2005, that is available in all earlier 1594versions of Ada as an implementation-defined pragma. 1595 1596This is a configuration pragma that forces the detection of potentially 1597blocking operations within a protected operation, and to raise Program_Error 1598if that happens. 1599 1600Pragma Disable_Atomic_Synchronization 1601===================================== 1602 1603.. index:: Atomic Synchronization 1604 1605Syntax: 1606 1607:: 1608 1609 pragma Disable_Atomic_Synchronization [(Entity)]; 1610 1611 1612Ada requires that accesses (reads or writes) of an atomic variable be 1613regarded as synchronization points in the case of multiple tasks. 1614Particularly in the case of multi-processors this may require special 1615handling, e.g. the generation of memory barriers. This capability may 1616be turned off using this pragma in cases where it is known not to be 1617required. 1618 1619The placement and scope rules for this pragma are the same as those 1620for ``pragma Suppress``. In particular it can be used as a 1621configuration pragma, or in a declaration sequence where it applies 1622till the end of the scope. If an ``Entity`` argument is present, 1623the action applies only to that entity. 1624 1625Pragma Dispatching_Domain 1626========================= 1627 1628Syntax: 1629 1630 1631.. code-block:: ada 1632 1633 pragma Dispatching_Domain (EXPRESSION); 1634 1635 1636This pragma is standard in Ada 2012, but is available in all earlier 1637versions of Ada as an implementation-defined pragma. 1638See Ada 2012 Reference Manual for details. 1639 1640.. _Pragma-Effective_Reads: 1641 1642Pragma Effective_Reads 1643====================== 1644 1645Syntax: 1646 1647.. code-block:: ada 1648 1649 pragma Effective_Reads [ (boolean_EXPRESSION) ]; 1650 1651For the semantics of this pragma, see the entry for aspect ``Effective_Reads`` in 1652the SPARK 2014 Reference Manual, section 7.1.2. 1653 1654.. _Pragma-Effective_Writes: 1655 1656Pragma Effective_Writes 1657======================= 1658 1659Syntax: 1660 1661.. code-block:: ada 1662 1663 pragma Effective_Writes [ (boolean_EXPRESSION) ]; 1664 1665For the semantics of this pragma, see the entry for aspect ``Effective_Writes`` 1666in the SPARK 2014 Reference Manual, section 7.1.2. 1667 1668Pragma Elaboration_Checks 1669========================= 1670.. index:: Elaboration control 1671 1672 1673Syntax: 1674 1675 1676.. code-block:: ada 1677 1678 pragma Elaboration_Checks (Dynamic | Static); 1679 1680 1681This is a configuration pragma that provides control over the 1682elaboration model used by the compilation affected by the 1683pragma. If the parameter is ``Dynamic``, 1684then the dynamic elaboration 1685model described in the Ada Reference Manual is used, as though 1686the *-gnatE* switch had been specified on the command 1687line. If the parameter is ``Static``, then the default GNAT static 1688model is used. This configuration pragma overrides the setting 1689of the command line. For full details on the elaboration models 1690used by the GNAT compiler, see the chapter on elaboration order handling 1691in the *GNAT User's Guide*. 1692 1693 1694Pragma Eliminate 1695================ 1696.. index:: Elimination of unused subprograms 1697 1698 1699Syntax: 1700 1701 1702:: 1703 1704 pragma Eliminate ( 1705 [ Unit_Name => ] IDENTIFIER | SELECTED_COMPONENT , 1706 [ Entity => ] IDENTIFIER | 1707 SELECTED_COMPONENT | 1708 STRING_LITERAL 1709 [, Source_Location => SOURCE_TRACE ] ); 1710 1711 SOURCE_TRACE ::= STRING_LITERAL 1712 1713 1714This pragma indicates that the given entity is not used in the program to be 1715compiled and built, thus allowing the compiler to 1716eliminate the code or data associated with the named entity. Any reference to 1717an eliminated entity causes a compile-time or link-time error. 1718 1719The pragma has the following semantics, where ``U`` is the unit specified by 1720the ``Unit_Name`` argument and ``E`` is the entity specified by the ``Entity`` 1721argument: 1722 1723* ``E`` must be a subprogram that is explicitly declared either: 1724 1725 o Within ``U``, or 1726 1727 o Within a generic package that is instantiated in ``U``, or 1728 1729 o As an instance of generic subprogram instantiated in ``U``. 1730 1731 Otherwise the pragma is ignored. 1732 1733* If ``E`` is overloaded within ``U`` then, in the absence of a 1734 ``Source_Location`` argument, all overloadings are eliminated. 1735 1736* If ``E`` is overloaded within ``U`` and only some overloadings 1737 are to be eliminated, then each overloading to be eliminated 1738 must be specified in a corresponding pragma ``Eliminate`` 1739 with a ``Source_Location`` argument identifying the line where the 1740 declaration appears, as described below. 1741 1742* If ``E`` is declared as the result of a generic instantiation, then 1743 a ``Source_Location`` argument is needed, as described below 1744 1745Pragma ``Eliminate`` allows a program to be compiled in a system-independent 1746manner, so that unused entities are eliminated but without 1747needing to modify the source text. Normally the required set of 1748``Eliminate`` pragmas is constructed automatically using the ``gnatelim`` tool. 1749 1750Any source file change that removes, splits, or 1751adds lines may make the set of ``Eliminate`` pragmas invalid because their 1752``Source_Location`` argument values may get out of date. 1753 1754Pragma ``Eliminate`` may be used where the referenced entity is a dispatching 1755operation. In this case all the subprograms to which the given operation can 1756dispatch are considered to be unused (are never called as a result of a direct 1757or a dispatching call). 1758 1759The string literal given for the source location specifies the line number 1760of the declaration of the entity, using the following syntax for ``SOURCE_TRACE``: 1761 1762:: 1763 1764 SOURCE_TRACE ::= SOURCE_REFERENCE [ LBRACKET SOURCE_TRACE RBRACKET ] 1765 1766 LBRACKET ::= '[' 1767 RBRACKET ::= ']' 1768 1769 SOURCE_REFERENCE ::= FILE_NAME : LINE_NUMBER 1770 1771 LINE_NUMBER ::= DIGIT {DIGIT} 1772 1773 1774Spaces around the colon in a ``SOURCE_REFERENCE`` are optional. 1775 1776The source trace that is given as the ``Source_Location`` must obey the 1777following rules (or else the pragma is ignored), where ``U`` is 1778the unit ``U`` specified by the ``Unit_Name`` argument and ``E`` is the 1779subprogram specified by the ``Entity`` argument: 1780 1781* ``FILE_NAME`` is the short name (with no directory 1782 information) of the Ada source file for ``U``, using the required syntax 1783 for the underlying file system (e.g. case is significant if the underlying 1784 operating system is case sensitive). 1785 If ``U`` is a package and ``E`` is a subprogram declared in the package 1786 specification and its full declaration appears in the package body, 1787 then the relevant source file is the one for the package specification; 1788 analogously if ``U`` is a generic package. 1789 1790* If ``E`` is not declared in a generic instantiation (this includes 1791 generic subprogram instances), the source trace includes only one source 1792 line reference. ``LINE_NUMBER`` gives the line number of the occurrence 1793 of the declaration of ``E`` within the source file (as a decimal literal 1794 without an exponent or point). 1795 1796* If ``E`` is declared by a generic instantiation, its source trace 1797 (from left to right) starts with the source location of the 1798 declaration of ``E`` in the generic unit and ends with the source 1799 location of the instantiation, given in square brackets. This approach is 1800 applied recursively with nested instantiations: the rightmost (nested 1801 most deeply in square brackets) element of the source trace is the location 1802 of the outermost instantiation, and the leftmost element (that is, outside 1803 of any square brackets) is the location of the declaration of ``E`` in 1804 the generic unit. 1805 1806Examples: 1807 1808 .. code-block:: ada 1809 1810 pragma Eliminate (Pkg0, Proc); 1811 -- Eliminate (all overloadings of) Proc in Pkg0 1812 1813 pragma Eliminate (Pkg1, Proc, 1814 Source_Location => "pkg1.ads:8"); 1815 -- Eliminate overloading of Proc at line 8 in pkg1.ads 1816 1817 -- Assume the following file contents: 1818 -- gen_pkg.ads 1819 -- 1: generic 1820 -- 2: type T is private; 1821 -- 3: package Gen_Pkg is 1822 -- 4: procedure Proc(N : T); 1823 -- ... ... 1824 -- ... end Gen_Pkg; 1825 -- 1826 -- q.adb 1827 -- 1: with Gen_Pkg; 1828 -- 2: procedure Q is 1829 -- 3: package Inst_Pkg is new Gen_Pkg(Integer); 1830 -- ... -- No calls on Inst_Pkg.Proc 1831 -- ... end Q; 1832 1833 -- The following pragma eliminates Inst_Pkg.Proc from Q 1834 pragma Eliminate (Q, Proc, 1835 Source_Location => "gen_pkg.ads:4[q.adb:3]"); 1836 1837 1838 1839Pragma Enable_Atomic_Synchronization 1840==================================== 1841.. index:: Atomic Synchronization 1842 1843 1844Syntax: 1845 1846 1847:: 1848 1849 pragma Enable_Atomic_Synchronization [(Entity)]; 1850 1851 1852Ada requires that accesses (reads or writes) of an atomic variable be 1853regarded as synchronization points in the case of multiple tasks. 1854Particularly in the case of multi-processors this may require special 1855handling, e.g. the generation of memory barriers. This synchronization 1856is performed by default, but can be turned off using 1857``pragma Disable_Atomic_Synchronization``. The 1858``Enable_Atomic_Synchronization`` pragma can be used to turn 1859it back on. 1860 1861The placement and scope rules for this pragma are the same as those 1862for ``pragma Unsuppress``. In particular it can be used as a 1863configuration pragma, or in a declaration sequence where it applies 1864till the end of the scope. If an ``Entity`` argument is present, 1865the action applies only to that entity. 1866 1867Pragma Export_Function 1868====================== 1869.. index:: Argument passing mechanisms 1870 1871 1872Syntax: 1873 1874 1875:: 1876 1877 pragma Export_Function ( 1878 [Internal =>] LOCAL_NAME 1879 [, [External =>] EXTERNAL_SYMBOL] 1880 [, [Parameter_Types =>] PARAMETER_TYPES] 1881 [, [Result_Type =>] result_SUBTYPE_MARK] 1882 [, [Mechanism =>] MECHANISM] 1883 [, [Result_Mechanism =>] MECHANISM_NAME]); 1884 1885 EXTERNAL_SYMBOL ::= 1886 IDENTIFIER 1887 | static_string_EXPRESSION 1888 | "" 1889 1890 PARAMETER_TYPES ::= 1891 null 1892 | TYPE_DESIGNATOR {, TYPE_DESIGNATOR} 1893 1894 TYPE_DESIGNATOR ::= 1895 subtype_NAME 1896 | subtype_Name ' Access 1897 1898 MECHANISM ::= 1899 MECHANISM_NAME 1900 | (MECHANISM_ASSOCIATION {, MECHANISM_ASSOCIATION}) 1901 1902 MECHANISM_ASSOCIATION ::= 1903 [formal_parameter_NAME =>] MECHANISM_NAME 1904 1905 MECHANISM_NAME ::= Value | Reference 1906 1907 1908Use this pragma to make a function externally callable and optionally 1909provide information on mechanisms to be used for passing parameter and 1910result values. We recommend, for the purposes of improving portability, 1911this pragma always be used in conjunction with a separate pragma 1912``Export``, which must precede the pragma ``Export_Function``. 1913GNAT does not require a separate pragma ``Export``, but if none is 1914present, ``Convention Ada`` is assumed, which is usually 1915not what is wanted, so it is usually appropriate to use this 1916pragma in conjunction with a ``Export`` or ``Convention`` 1917pragma that specifies the desired foreign convention. 1918Pragma ``Export_Function`` 1919(and ``Export``, if present) must appear in the same declarative 1920region as the function to which they apply. 1921 1922The ``internal_name`` must uniquely designate the function to which the 1923pragma applies. If more than one function name exists of this name in 1924the declarative part you must use the ``Parameter_Types`` and 1925``Result_Type`` parameters to achieve the required 1926unique designation. The `subtype_mark`\ s in these parameters must 1927exactly match the subtypes in the corresponding function specification, 1928using positional notation to match parameters with subtype marks. 1929The form with an ``'Access`` attribute can be used to match an 1930anonymous access parameter. 1931 1932.. index:: Suppressing external name 1933 1934Special treatment is given if the EXTERNAL is an explicit null 1935string or a static string expressions that evaluates to the null 1936string. In this case, no external name is generated. This form 1937still allows the specification of parameter mechanisms. 1938 1939Pragma Export_Object 1940==================== 1941 1942Syntax: 1943 1944 1945:: 1946 1947 pragma Export_Object 1948 [Internal =>] LOCAL_NAME 1949 [, [External =>] EXTERNAL_SYMBOL] 1950 [, [Size =>] EXTERNAL_SYMBOL] 1951 1952 EXTERNAL_SYMBOL ::= 1953 IDENTIFIER 1954 | static_string_EXPRESSION 1955 1956 1957This pragma designates an object as exported, and apart from the 1958extended rules for external symbols, is identical in effect to the use of 1959the normal ``Export`` pragma applied to an object. You may use a 1960separate Export pragma (and you probably should from the point of view 1961of portability), but it is not required. ``Size`` is syntax checked, 1962but otherwise ignored by GNAT. 1963 1964Pragma Export_Procedure 1965======================= 1966 1967Syntax: 1968 1969 1970:: 1971 1972 pragma Export_Procedure ( 1973 [Internal =>] LOCAL_NAME 1974 [, [External =>] EXTERNAL_SYMBOL] 1975 [, [Parameter_Types =>] PARAMETER_TYPES] 1976 [, [Mechanism =>] MECHANISM]); 1977 1978 EXTERNAL_SYMBOL ::= 1979 IDENTIFIER 1980 | static_string_EXPRESSION 1981 | "" 1982 1983 PARAMETER_TYPES ::= 1984 null 1985 | TYPE_DESIGNATOR {, TYPE_DESIGNATOR} 1986 1987 TYPE_DESIGNATOR ::= 1988 subtype_NAME 1989 | subtype_Name ' Access 1990 1991 MECHANISM ::= 1992 MECHANISM_NAME 1993 | (MECHANISM_ASSOCIATION {, MECHANISM_ASSOCIATION}) 1994 1995 MECHANISM_ASSOCIATION ::= 1996 [formal_parameter_NAME =>] MECHANISM_NAME 1997 1998 MECHANISM_NAME ::= Value | Reference 1999 2000 2001This pragma is identical to ``Export_Function`` except that it 2002applies to a procedure rather than a function and the parameters 2003``Result_Type`` and ``Result_Mechanism`` are not permitted. 2004GNAT does not require a separate pragma ``Export``, but if none is 2005present, ``Convention Ada`` is assumed, which is usually 2006not what is wanted, so it is usually appropriate to use this 2007pragma in conjunction with a ``Export`` or ``Convention`` 2008pragma that specifies the desired foreign convention. 2009 2010.. index:: Suppressing external name 2011 2012Special treatment is given if the EXTERNAL is an explicit null 2013string or a static string expressions that evaluates to the null 2014string. In this case, no external name is generated. This form 2015still allows the specification of parameter mechanisms. 2016 2017Pragma Export_Value 2018=================== 2019 2020Syntax: 2021 2022 2023:: 2024 2025 pragma Export_Value ( 2026 [Value =>] static_integer_EXPRESSION, 2027 [Link_Name =>] static_string_EXPRESSION); 2028 2029 2030This pragma serves to export a static integer value for external use. 2031The first argument specifies the value to be exported. The Link_Name 2032argument specifies the symbolic name to be associated with the integer 2033value. This pragma is useful for defining a named static value in Ada 2034that can be referenced in assembly language units to be linked with 2035the application. This pragma is currently supported only for the 2036AAMP target and is ignored for other targets. 2037 2038Pragma Export_Valued_Procedure 2039============================== 2040 2041Syntax: 2042 2043 2044:: 2045 2046 pragma Export_Valued_Procedure ( 2047 [Internal =>] LOCAL_NAME 2048 [, [External =>] EXTERNAL_SYMBOL] 2049 [, [Parameter_Types =>] PARAMETER_TYPES] 2050 [, [Mechanism =>] MECHANISM]); 2051 2052 EXTERNAL_SYMBOL ::= 2053 IDENTIFIER 2054 | static_string_EXPRESSION 2055 | "" 2056 2057 PARAMETER_TYPES ::= 2058 null 2059 | TYPE_DESIGNATOR {, TYPE_DESIGNATOR} 2060 2061 TYPE_DESIGNATOR ::= 2062 subtype_NAME 2063 | subtype_Name ' Access 2064 2065 MECHANISM ::= 2066 MECHANISM_NAME 2067 | (MECHANISM_ASSOCIATION {, MECHANISM_ASSOCIATION}) 2068 2069 MECHANISM_ASSOCIATION ::= 2070 [formal_parameter_NAME =>] MECHANISM_NAME 2071 2072 MECHANISM_NAME ::= Value | Reference 2073 2074 2075This pragma is identical to ``Export_Procedure`` except that the 2076first parameter of ``LOCAL_NAME``, which must be present, must be of 2077mode ``out``, and externally the subprogram is treated as a function 2078with this parameter as the result of the function. GNAT provides for 2079this capability to allow the use of ``out`` and ``in out`` 2080parameters in interfacing to external functions (which are not permitted 2081in Ada functions). 2082GNAT does not require a separate pragma ``Export``, but if none is 2083present, ``Convention Ada`` is assumed, which is almost certainly 2084not what is wanted since the whole point of this pragma is to interface 2085with foreign language functions, so it is usually appropriate to use this 2086pragma in conjunction with a ``Export`` or ``Convention`` 2087pragma that specifies the desired foreign convention. 2088 2089.. index:: Suppressing external name 2090 2091Special treatment is given if the EXTERNAL is an explicit null 2092string or a static string expressions that evaluates to the null 2093string. In this case, no external name is generated. This form 2094still allows the specification of parameter mechanisms. 2095 2096Pragma Extend_System 2097==================== 2098.. index:: System, extending 2099 2100.. index:: DEC Ada 83 2101 2102 2103Syntax: 2104 2105 2106:: 2107 2108 pragma Extend_System ([Name =>] IDENTIFIER); 2109 2110 2111This pragma is used to provide backwards compatibility with other 2112implementations that extend the facilities of package ``System``. In 2113GNAT, ``System`` contains only the definitions that are present in 2114the Ada RM. However, other implementations, notably the DEC Ada 83 2115implementation, provide many extensions to package ``System``. 2116 2117For each such implementation accommodated by this pragma, GNAT provides a 2118package :samp:`Aux_{xxx}`, e.g., ``Aux_DEC`` for the DEC Ada 83 2119implementation, which provides the required additional definitions. You 2120can use this package in two ways. You can ``with`` it in the normal 2121way and access entities either by selection or using a ``use`` 2122clause. In this case no special processing is required. 2123 2124However, if existing code contains references such as 2125:samp:`System.{xxx}` where *xxx* is an entity in the extended 2126definitions provided in package ``System``, you may use this pragma 2127to extend visibility in ``System`` in a non-standard way that 2128provides greater compatibility with the existing code. Pragma 2129``Extend_System`` is a configuration pragma whose single argument is 2130the name of the package containing the extended definition 2131(e.g., ``Aux_DEC`` for the DEC Ada case). A unit compiled under 2132control of this pragma will be processed using special visibility 2133processing that looks in package :samp:`System.Aux_{xxx}` where 2134:samp:`Aux_{xxx}` is the pragma argument for any entity referenced in 2135package ``System``, but not found in package ``System``. 2136 2137You can use this pragma either to access a predefined ``System`` 2138extension supplied with the compiler, for example ``Aux_DEC`` or 2139you can construct your own extension unit following the above 2140definition. Note that such a package is a child of ``System`` 2141and thus is considered part of the implementation. 2142To compile it you will have to use the *-gnatg* switch 2143for compiling System units, as explained in the 2144GNAT User's Guide. 2145 2146Pragma Extensions_Allowed 2147========================= 2148.. index:: Ada Extensions 2149 2150.. index:: GNAT Extensions 2151 2152 2153Syntax: 2154 2155.. code-block:: ada 2156 2157 pragma Extensions_Allowed (On | Off); 2158 2159 2160This configuration pragma enables or disables the implementation 2161extension mode (the use of Off as a parameter cancels the effect 2162of the *-gnatX* command switch). 2163 2164In extension mode, the latest version of the Ada language is 2165implemented (currently Ada 2012), and in addition a small number 2166of GNAT specific extensions are recognized as follows: 2167 2168 2169 2170*Constrained attribute for generic objects* 2171 The ``Constrained`` attribute is permitted for objects of 2172 generic types. The result indicates if the corresponding actual 2173 is constrained. 2174 2175.. _Pragma-Extensions_Visible: 2176 2177Pragma Extensions_Visible 2178========================= 2179 2180Syntax: 2181 2182.. code-block:: ada 2183 2184 pragma Extensions_Visible [ (boolean_EXPRESSION) ]; 2185 2186For the semantics of this pragma, see the entry for aspect ``Extensions_Visible`` 2187in the SPARK 2014 Reference Manual, section 6.1.7. 2188 2189Pragma External 2190=============== 2191 2192Syntax: 2193 2194 2195:: 2196 2197 pragma External ( 2198 [ Convention =>] convention_IDENTIFIER, 2199 [ Entity =>] LOCAL_NAME 2200 [, [External_Name =>] static_string_EXPRESSION ] 2201 [, [Link_Name =>] static_string_EXPRESSION ]); 2202 2203 2204This pragma is identical in syntax and semantics to pragma 2205``Export`` as defined in the Ada Reference Manual. It is 2206provided for compatibility with some Ada 83 compilers that 2207used this pragma for exactly the same purposes as pragma 2208``Export`` before the latter was standardized. 2209 2210Pragma External_Name_Casing 2211=========================== 2212.. index:: Dec Ada 83 casing compatibility 2213 2214.. index:: External Names, casing 2215 2216.. index:: Casing of External names 2217 2218 2219Syntax: 2220 2221 2222:: 2223 2224 pragma External_Name_Casing ( 2225 Uppercase | Lowercase 2226 [, Uppercase | Lowercase | As_Is]); 2227 2228 2229This pragma provides control over the casing of external names associated 2230with Import and Export pragmas. There are two cases to consider: 2231 2232 2233 2234* Implicit external names 2235 2236 Implicit external names are derived from identifiers. The most common case 2237 arises when a standard Ada Import or Export pragma is used with only two 2238 arguments, as in: 2239 2240 .. code-block:: ada 2241 2242 pragma Import (C, C_Routine); 2243 2244 Since Ada is a case-insensitive language, the spelling of the identifier in 2245 the Ada source program does not provide any information on the desired 2246 casing of the external name, and so a convention is needed. In GNAT the 2247 default treatment is that such names are converted to all lower case 2248 letters. This corresponds to the normal C style in many environments. 2249 The first argument of pragma ``External_Name_Casing`` can be used to 2250 control this treatment. If ``Uppercase`` is specified, then the name 2251 will be forced to all uppercase letters. If ``Lowercase`` is specified, 2252 then the normal default of all lower case letters will be used. 2253 2254 This same implicit treatment is also used in the case of extended DEC Ada 83 2255 compatible Import and Export pragmas where an external name is explicitly 2256 specified using an identifier rather than a string. 2257 2258 2259* Explicit external names 2260 2261 Explicit external names are given as string literals. The most common case 2262 arises when a standard Ada Import or Export pragma is used with three 2263 arguments, as in: 2264 2265 .. code-block:: ada 2266 2267 pragma Import (C, C_Routine, "C_routine"); 2268 2269 In this case, the string literal normally provides the exact casing required 2270 for the external name. The second argument of pragma 2271 ``External_Name_Casing`` may be used to modify this behavior. 2272 If ``Uppercase`` is specified, then the name 2273 will be forced to all uppercase letters. If ``Lowercase`` is specified, 2274 then the name will be forced to all lowercase letters. A specification of 2275 ``As_Is`` provides the normal default behavior in which the casing is 2276 taken from the string provided. 2277 2278This pragma may appear anywhere that a pragma is valid. In particular, it 2279can be used as a configuration pragma in the :file:`gnat.adc` file, in which 2280case it applies to all subsequent compilations, or it can be used as a program 2281unit pragma, in which case it only applies to the current unit, or it can 2282be used more locally to control individual Import/Export pragmas. 2283 2284It was primarily intended for use with OpenVMS systems, where many 2285compilers convert all symbols to upper case by default. For interfacing to 2286such compilers (e.g., the DEC C compiler), it may be convenient to use 2287the pragma: 2288 2289.. code-block:: ada 2290 2291 pragma External_Name_Casing (Uppercase, Uppercase); 2292 2293 2294to enforce the upper casing of all external symbols. 2295 2296Pragma Fast_Math 2297================ 2298 2299Syntax: 2300 2301 2302.. code-block:: ada 2303 2304 pragma Fast_Math; 2305 2306 2307This is a configuration pragma which activates a mode in which speed is 2308considered more important for floating-point operations than absolutely 2309accurate adherence to the requirements of the standard. Currently the 2310following operations are affected: 2311 2312 2313 2314*Complex Multiplication* 2315 The normal simple formula for complex multiplication can result in intermediate 2316 overflows for numbers near the end of the range. The Ada standard requires that 2317 this situation be detected and corrected by scaling, but in Fast_Math mode such 2318 cases will simply result in overflow. Note that to take advantage of this you 2319 must instantiate your own version of ``Ada.Numerics.Generic_Complex_Types`` 2320 under control of the pragma, rather than use the preinstantiated versions. 2321 2322.. _Pragma-Favor_Top_Level: 2323 2324Pragma Favor_Top_Level 2325====================== 2326 2327Syntax: 2328 2329 2330.. code-block:: ada 2331 2332 pragma Favor_Top_Level (type_NAME); 2333 2334 2335The argument of pragma ``Favor_Top_Level`` must be a named access-to-subprogram 2336type. This pragma is an efficiency hint to the compiler, regarding the use of 2337``'Access`` or ``'Unrestricted_Access`` on nested (non-library-level) subprograms. 2338The pragma means that nested subprograms are not used with this type, or are 2339rare, so that the generated code should be efficient in the top-level case. 2340When this pragma is used, dynamically generated trampolines may be used on some 2341targets for nested subprograms. See restriction ``No_Implicit_Dynamic_Code``. 2342 2343Pragma Finalize_Storage_Only 2344============================ 2345 2346Syntax: 2347 2348 2349.. code-block:: ada 2350 2351 pragma Finalize_Storage_Only (first_subtype_LOCAL_NAME); 2352 2353 2354The argument of pragma ``Finalize_Storage_Only`` must denote a local type which 2355is derived from ``Ada.Finalization.Controlled`` or ``Limited_Controlled``. The 2356pragma suppresses the call to ``Finalize`` for declared library-level objects 2357of the argument type. This is mostly useful for types where finalization is 2358only used to deal with storage reclamation since in most environments it is 2359not necessary to reclaim memory just before terminating execution, hence the 2360name. Note that this pragma does not suppress Finalize calls for library-level 2361heap-allocated objects (see pragma ``No_Heap_Finalization``). 2362 2363Pragma Float_Representation 2364=========================== 2365 2366Syntax:: 2367 2368 pragma Float_Representation (FLOAT_REP[, float_type_LOCAL_NAME]); 2369 2370 FLOAT_REP ::= VAX_Float | IEEE_Float 2371 2372 2373In the one argument form, this pragma is a configuration pragma which 2374allows control over the internal representation chosen for the predefined 2375floating point types declared in the packages ``Standard`` and 2376``System``. This pragma is only provided for compatibility and has no effect. 2377 2378The two argument form specifies the representation to be used for 2379the specified floating-point type. The argument must 2380be ``IEEE_Float`` to specify the use of IEEE format, as follows: 2381 2382* 2383 For a digits value of 6, 32-bit IEEE short format will be used. 2384* 2385 For a digits value of 15, 64-bit IEEE long format will be used. 2386* 2387 No other value of digits is permitted. 2388 2389.. _Pragma-Ghost: 2390 2391Pragma Ghost 2392============ 2393 2394Syntax: 2395 2396.. code-block:: ada 2397 2398 pragma Ghost [ (boolean_EXPRESSION) ]; 2399 2400For the semantics of this pragma, see the entry for aspect ``Ghost`` in the SPARK 24012014 Reference Manual, section 6.9. 2402 2403.. _Pragma-Global: 2404 2405Pragma Global 2406============= 2407 2408Syntax: 2409 2410.. code-block:: ada 2411 2412 pragma Global (GLOBAL_SPECIFICATION); 2413 2414 GLOBAL_SPECIFICATION ::= 2415 null 2416 | (GLOBAL_LIST) 2417 | (MODED_GLOBAL_LIST {, MODED_GLOBAL_LIST}) 2418 2419 MODED_GLOBAL_LIST ::= MODE_SELECTOR => GLOBAL_LIST 2420 2421 MODE_SELECTOR ::= In_Out | Input | Output | Proof_In 2422 GLOBAL_LIST ::= GLOBAL_ITEM | (GLOBAL_ITEM {, GLOBAL_ITEM}) 2423 GLOBAL_ITEM ::= NAME 2424 2425For the semantics of this pragma, see the entry for aspect ``Global`` in the 2426SPARK 2014 Reference Manual, section 6.1.4. 2427 2428Pragma Ident 2429============ 2430 2431Syntax: 2432 2433 2434.. code-block:: ada 2435 2436 pragma Ident (static_string_EXPRESSION); 2437 2438 2439This pragma is identical in effect to pragma ``Comment``. It is provided 2440for compatibility with other Ada compilers providing this pragma. 2441 2442Pragma Ignore_Pragma 2443==================== 2444 2445Syntax: 2446 2447 2448.. code-block:: ada 2449 2450 pragma Ignore_Pragma (pragma_IDENTIFIER); 2451 2452This is a configuration pragma 2453that takes a single argument that is a simple identifier. Any subsequent 2454use of a pragma whose pragma identifier matches this argument will be 2455silently ignored. This may be useful when legacy code or code intended 2456for compilation with some other compiler contains pragmas that match the 2457name, but not the exact implementation, of a GNAT pragma. The use of this 2458pragma allows such pragmas to be ignored, which may be useful in CodePeer 2459mode, or during porting of legacy code. 2460 2461Pragma Implementation_Defined 2462============================= 2463 2464Syntax: 2465 2466 2467.. code-block:: ada 2468 2469 pragma Implementation_Defined (local_NAME); 2470 2471 2472This pragma marks a previously declared entity as implementation-defined. 2473For an overloaded entity, applies to the most recent homonym. 2474 2475 2476.. code-block:: ada 2477 2478 pragma Implementation_Defined; 2479 2480 2481The form with no arguments appears anywhere within a scope, most 2482typically a package spec, and indicates that all entities that are 2483defined within the package spec are Implementation_Defined. 2484 2485This pragma is used within the GNAT runtime library to identify 2486implementation-defined entities introduced in language-defined units, 2487for the purpose of implementing the No_Implementation_Identifiers 2488restriction. 2489 2490Pragma Implemented 2491================== 2492 2493Syntax: 2494 2495 2496:: 2497 2498 pragma Implemented (procedure_LOCAL_NAME, implementation_kind); 2499 2500 implementation_kind ::= By_Entry | By_Protected_Procedure | By_Any 2501 2502 2503This is an Ada 2012 representation pragma which applies to protected, task 2504and synchronized interface primitives. The use of pragma Implemented provides 2505a way to impose a static requirement on the overriding operation by adhering 2506to one of the three implementation kinds: entry, protected procedure or any of 2507the above. This pragma is available in all earlier versions of Ada as an 2508implementation-defined pragma. 2509 2510 2511.. code-block:: ada 2512 2513 type Synch_Iface is synchronized interface; 2514 procedure Prim_Op (Obj : in out Iface) is abstract; 2515 pragma Implemented (Prim_Op, By_Protected_Procedure); 2516 2517 protected type Prot_1 is new Synch_Iface with 2518 procedure Prim_Op; -- Legal 2519 end Prot_1; 2520 2521 protected type Prot_2 is new Synch_Iface with 2522 entry Prim_Op; -- Illegal 2523 end Prot_2; 2524 2525 task type Task_Typ is new Synch_Iface with 2526 entry Prim_Op; -- Illegal 2527 end Task_Typ; 2528 2529 2530When applied to the procedure_or_entry_NAME of a requeue statement, pragma 2531Implemented determines the runtime behavior of the requeue. Implementation kind 2532By_Entry guarantees that the action of requeueing will proceed from an entry to 2533another entry. Implementation kind By_Protected_Procedure transforms the 2534requeue into a dispatching call, thus eliminating the chance of blocking. Kind 2535By_Any shares the behavior of By_Entry and By_Protected_Procedure depending on 2536the target's overriding subprogram kind. 2537 2538Pragma Implicit_Packing 2539======================= 2540.. index:: Rational Profile 2541 2542Syntax: 2543 2544 2545.. code-block:: ada 2546 2547 pragma Implicit_Packing; 2548 2549 2550This is a configuration pragma that requests implicit packing for packed 2551arrays for which a size clause is given but no explicit pragma Pack or 2552specification of Component_Size is present. It also applies to records 2553where no record representation clause is present. Consider this example: 2554 2555 2556.. code-block:: ada 2557 2558 type R is array (0 .. 7) of Boolean; 2559 for R'Size use 8; 2560 2561 2562In accordance with the recommendation in the RM (RM 13.3(53)), a Size clause 2563does not change the layout of a composite object. So the Size clause in the 2564above example is normally rejected, since the default layout of the array uses 25658-bit components, and thus the array requires a minimum of 64 bits. 2566 2567If this declaration is compiled in a region of code covered by an occurrence 2568of the configuration pragma Implicit_Packing, then the Size clause in this 2569and similar examples will cause implicit packing and thus be accepted. For 2570this implicit packing to occur, the type in question must be an array of small 2571components whose size is known at compile time, and the Size clause must 2572specify the exact size that corresponds to the number of elements in the array 2573multiplied by the size in bits of the component type (both single and 2574multi-dimensioned arrays can be controlled with this pragma). 2575 2576.. index:: Array packing 2577 2578Similarly, the following example shows the use in the record case 2579 2580 2581.. code-block:: ada 2582 2583 type r is record 2584 a, b, c, d, e, f, g, h : boolean; 2585 chr : character; 2586 end record; 2587 for r'size use 16; 2588 2589 2590Without a pragma Pack, each Boolean field requires 8 bits, so the 2591minimum size is 72 bits, but with a pragma Pack, 16 bits would be 2592sufficient. The use of pragma Implicit_Packing allows this record 2593declaration to compile without an explicit pragma Pack. 2594 2595Pragma Import_Function 2596====================== 2597 2598Syntax: 2599 2600 2601:: 2602 2603 pragma Import_Function ( 2604 [Internal =>] LOCAL_NAME, 2605 [, [External =>] EXTERNAL_SYMBOL] 2606 [, [Parameter_Types =>] PARAMETER_TYPES] 2607 [, [Result_Type =>] SUBTYPE_MARK] 2608 [, [Mechanism =>] MECHANISM] 2609 [, [Result_Mechanism =>] MECHANISM_NAME]); 2610 2611 EXTERNAL_SYMBOL ::= 2612 IDENTIFIER 2613 | static_string_EXPRESSION 2614 2615 PARAMETER_TYPES ::= 2616 null 2617 | TYPE_DESIGNATOR {, TYPE_DESIGNATOR} 2618 2619 TYPE_DESIGNATOR ::= 2620 subtype_NAME 2621 | subtype_Name ' Access 2622 2623 MECHANISM ::= 2624 MECHANISM_NAME 2625 | (MECHANISM_ASSOCIATION {, MECHANISM_ASSOCIATION}) 2626 2627 MECHANISM_ASSOCIATION ::= 2628 [formal_parameter_NAME =>] MECHANISM_NAME 2629 2630 MECHANISM_NAME ::= 2631 Value 2632 | Reference 2633 2634 2635This pragma is used in conjunction with a pragma ``Import`` to 2636specify additional information for an imported function. The pragma 2637``Import`` (or equivalent pragma ``Interface``) must precede the 2638``Import_Function`` pragma and both must appear in the same 2639declarative part as the function specification. 2640 2641The ``Internal`` argument must uniquely designate 2642the function to which the 2643pragma applies. If more than one function name exists of this name in 2644the declarative part you must use the ``Parameter_Types`` and 2645``Result_Type`` parameters to achieve the required unique 2646designation. Subtype marks in these parameters must exactly match the 2647subtypes in the corresponding function specification, using positional 2648notation to match parameters with subtype marks. 2649The form with an ``'Access`` attribute can be used to match an 2650anonymous access parameter. 2651 2652You may optionally use the ``Mechanism`` and ``Result_Mechanism`` 2653parameters to specify passing mechanisms for the 2654parameters and result. If you specify a single mechanism name, it 2655applies to all parameters. Otherwise you may specify a mechanism on a 2656parameter by parameter basis using either positional or named 2657notation. If the mechanism is not specified, the default mechanism 2658is used. 2659 2660Pragma Import_Object 2661==================== 2662 2663Syntax: 2664 2665 2666:: 2667 2668 pragma Import_Object 2669 [Internal =>] LOCAL_NAME 2670 [, [External =>] EXTERNAL_SYMBOL] 2671 [, [Size =>] EXTERNAL_SYMBOL]); 2672 2673 EXTERNAL_SYMBOL ::= 2674 IDENTIFIER 2675 | static_string_EXPRESSION 2676 2677 2678This pragma designates an object as imported, and apart from the 2679extended rules for external symbols, is identical in effect to the use of 2680the normal ``Import`` pragma applied to an object. Unlike the 2681subprogram case, you need not use a separate ``Import`` pragma, 2682although you may do so (and probably should do so from a portability 2683point of view). ``size`` is syntax checked, but otherwise ignored by 2684GNAT. 2685 2686Pragma Import_Procedure 2687======================= 2688 2689Syntax: 2690 2691 2692:: 2693 2694 pragma Import_Procedure ( 2695 [Internal =>] LOCAL_NAME 2696 [, [External =>] EXTERNAL_SYMBOL] 2697 [, [Parameter_Types =>] PARAMETER_TYPES] 2698 [, [Mechanism =>] MECHANISM]); 2699 2700 EXTERNAL_SYMBOL ::= 2701 IDENTIFIER 2702 | static_string_EXPRESSION 2703 2704 PARAMETER_TYPES ::= 2705 null 2706 | TYPE_DESIGNATOR {, TYPE_DESIGNATOR} 2707 2708 TYPE_DESIGNATOR ::= 2709 subtype_NAME 2710 | subtype_Name ' Access 2711 2712 MECHANISM ::= 2713 MECHANISM_NAME 2714 | (MECHANISM_ASSOCIATION {, MECHANISM_ASSOCIATION}) 2715 2716 MECHANISM_ASSOCIATION ::= 2717 [formal_parameter_NAME =>] MECHANISM_NAME 2718 2719 MECHANISM_NAME ::= Value | Reference 2720 2721 2722This pragma is identical to ``Import_Function`` except that it 2723applies to a procedure rather than a function and the parameters 2724``Result_Type`` and ``Result_Mechanism`` are not permitted. 2725 2726Pragma Import_Valued_Procedure 2727============================== 2728 2729Syntax: 2730 2731 2732:: 2733 2734 pragma Import_Valued_Procedure ( 2735 [Internal =>] LOCAL_NAME 2736 [, [External =>] EXTERNAL_SYMBOL] 2737 [, [Parameter_Types =>] PARAMETER_TYPES] 2738 [, [Mechanism =>] MECHANISM]); 2739 2740 EXTERNAL_SYMBOL ::= 2741 IDENTIFIER 2742 | static_string_EXPRESSION 2743 2744 PARAMETER_TYPES ::= 2745 null 2746 | TYPE_DESIGNATOR {, TYPE_DESIGNATOR} 2747 2748 TYPE_DESIGNATOR ::= 2749 subtype_NAME 2750 | subtype_Name ' Access 2751 2752 MECHANISM ::= 2753 MECHANISM_NAME 2754 | (MECHANISM_ASSOCIATION {, MECHANISM_ASSOCIATION}) 2755 2756 MECHANISM_ASSOCIATION ::= 2757 [formal_parameter_NAME =>] MECHANISM_NAME 2758 2759 MECHANISM_NAME ::= Value | Reference 2760 2761 2762This pragma is identical to ``Import_Procedure`` except that the 2763first parameter of ``LOCAL_NAME``, which must be present, must be of 2764mode ``out``, and externally the subprogram is treated as a function 2765with this parameter as the result of the function. The purpose of this 2766capability is to allow the use of ``out`` and ``in out`` 2767parameters in interfacing to external functions (which are not permitted 2768in Ada functions). You may optionally use the ``Mechanism`` 2769parameters to specify passing mechanisms for the parameters. 2770If you specify a single mechanism name, it applies to all parameters. 2771Otherwise you may specify a mechanism on a parameter by parameter 2772basis using either positional or named notation. If the mechanism is not 2773specified, the default mechanism is used. 2774 2775Note that it is important to use this pragma in conjunction with a separate 2776pragma Import that specifies the desired convention, since otherwise the 2777default convention is Ada, which is almost certainly not what is required. 2778 2779Pragma Independent 2780================== 2781 2782Syntax: 2783 2784 2785.. code-block:: ada 2786 2787 pragma Independent (Local_NAME); 2788 2789 2790This pragma is standard in Ada 2012 mode (which also provides an aspect 2791of the same name). It is also available as an implementation-defined 2792pragma in all earlier versions. It specifies that the 2793designated object or all objects of the designated type must be 2794independently addressable. This means that separate tasks can safely 2795manipulate such objects. For example, if two components of a record are 2796independent, then two separate tasks may access these two components. 2797This may place 2798constraints on the representation of the object (for instance prohibiting 2799tight packing). 2800 2801Pragma Independent_Components 2802============================= 2803 2804Syntax: 2805 2806 2807.. code-block:: ada 2808 2809 pragma Independent_Components (Local_NAME); 2810 2811 2812This pragma is standard in Ada 2012 mode (which also provides an aspect 2813of the same name). It is also available as an implementation-defined 2814pragma in all earlier versions. It specifies that the components of the 2815designated object, or the components of each object of the designated 2816type, must be 2817independently addressable. This means that separate tasks can safely 2818manipulate separate components in the composite object. This may place 2819constraints on the representation of the object (for instance prohibiting 2820tight packing). 2821 2822.. _Pragma-Initial_Condition: 2823 2824Pragma Initial_Condition 2825======================== 2826 2827Syntax: 2828 2829.. code-block:: ada 2830 2831 pragma Initial_Condition (boolean_EXPRESSION); 2832 2833For the semantics of this pragma, see the entry for aspect ``Initial_Condition`` 2834in the SPARK 2014 Reference Manual, section 7.1.6. 2835 2836Pragma Initialize_Scalars 2837========================= 2838.. index:: debugging with Initialize_Scalars 2839 2840Syntax: 2841 2842 2843.. code-block:: ada 2844 2845 pragma Initialize_Scalars; 2846 2847 2848This pragma is similar to ``Normalize_Scalars`` conceptually but has 2849two important differences. First, there is no requirement for the pragma 2850to be used uniformly in all units of a partition, in particular, it is fine 2851to use this just for some or all of the application units of a partition, 2852without needing to recompile the run-time library. 2853 2854In the case where some units are compiled with the pragma, and some without, 2855then a declaration of a variable where the type is defined in package 2856Standard or is locally declared will always be subject to initialization, 2857as will any declaration of a scalar variable. For composite variables, 2858whether the variable is initialized may also depend on whether the package 2859in which the type of the variable is declared is compiled with the pragma. 2860 2861The other important difference is that you can control the value used 2862for initializing scalar objects. At bind time, you can select several 2863options for initialization. You can 2864initialize with invalid values (similar to Normalize_Scalars, though for 2865Initialize_Scalars it is not always possible to determine the invalid 2866values in complex cases like signed component fields with non-standard 2867sizes). You can also initialize with high or 2868low values, or with a specified bit pattern. See the GNAT 2869User's Guide for binder options for specifying these cases. 2870 2871This means that you can compile a program, and then without having to 2872recompile the program, you can run it with different values being used 2873for initializing otherwise uninitialized values, to test if your program 2874behavior depends on the choice. Of course the behavior should not change, 2875and if it does, then most likely you have an incorrect reference to an 2876uninitialized value. 2877 2878It is even possible to change the value at execution time eliminating even 2879the need to rebind with a different switch using an environment variable. 2880See the GNAT User's Guide for details. 2881 2882Note that pragma ``Initialize_Scalars`` is particularly useful in 2883conjunction with the enhanced validity checking that is now provided 2884in GNAT, which checks for invalid values under more conditions. 2885Using this feature (see description of the *-gnatV* flag in the 2886GNAT User's Guide) in conjunction with 2887pragma ``Initialize_Scalars`` 2888provides a powerful new tool to assist in the detection of problems 2889caused by uninitialized variables. 2890 2891Note: the use of ``Initialize_Scalars`` has a fairly extensive 2892effect on the generated code. This may cause your code to be 2893substantially larger. It may also cause an increase in the amount 2894of stack required, so it is probably a good idea to turn on stack 2895checking (see description of stack checking in the GNAT 2896User's Guide) when using this pragma. 2897 2898.. _Pragma-Initializes: 2899 2900Pragma Initializes 2901================== 2902 2903Syntax: 2904 2905.. code-block:: ada 2906 2907 pragma Initializes (INITIALIZATION_LIST); 2908 2909 INITIALIZATION_LIST ::= 2910 null 2911 | (INITIALIZATION_ITEM {, INITIALIZATION_ITEM}) 2912 2913 INITIALIZATION_ITEM ::= name [=> INPUT_LIST] 2914 2915 INPUT_LIST ::= 2916 null 2917 | INPUT 2918 | (INPUT {, INPUT}) 2919 2920 INPUT ::= name 2921 2922For the semantics of this pragma, see the entry for aspect ``Initializes`` in the 2923SPARK 2014 Reference Manual, section 7.1.5. 2924 2925.. _Pragma-Inline_Always: 2926 2927Pragma Inline_Always 2928==================== 2929 2930Syntax: 2931 2932 2933:: 2934 2935 pragma Inline_Always (NAME [, NAME]); 2936 2937 2938Similar to pragma ``Inline`` except that inlining is unconditional. 2939Inline_Always instructs the compiler to inline every direct call to the 2940subprogram or else to emit a compilation error, independently of any 2941option, in particular *-gnatn* or *-gnatN* or the optimization level. 2942It is an error to take the address or access of ``NAME``. It is also an error to 2943apply this pragma to a primitive operation of a tagged type. Thanks to such 2944restrictions, the compiler is allowed to remove the out-of-line body of ``NAME``. 2945 2946Pragma Inline_Generic 2947===================== 2948 2949Syntax: 2950 2951 2952:: 2953 2954 pragma Inline_Generic (GNAME {, GNAME}); 2955 2956 GNAME ::= generic_unit_NAME | generic_instance_NAME 2957 2958 2959This pragma is provided for compatibility with Dec Ada 83. It has 2960no effect in GNAT (which always inlines generics), other 2961than to check that the given names are all names of generic units or 2962generic instances. 2963 2964Pragma Interface 2965================ 2966 2967Syntax: 2968 2969 2970:: 2971 2972 pragma Interface ( 2973 [Convention =>] convention_identifier, 2974 [Entity =>] local_NAME 2975 [, [External_Name =>] static_string_expression] 2976 [, [Link_Name =>] static_string_expression]); 2977 2978 2979This pragma is identical in syntax and semantics to 2980the standard Ada pragma ``Import``. It is provided for compatibility 2981with Ada 83. The definition is upwards compatible both with pragma 2982``Interface`` as defined in the Ada 83 Reference Manual, and also 2983with some extended implementations of this pragma in certain Ada 83 2984implementations. The only difference between pragma ``Interface`` 2985and pragma ``Import`` is that there is special circuitry to allow 2986both pragmas to appear for the same subprogram entity (normally it 2987is illegal to have multiple ``Import`` pragmas. This is useful in 2988maintaining Ada 83/Ada 95 compatibility and is compatible with other 2989Ada 83 compilers. 2990 2991Pragma Interface_Name 2992===================== 2993 2994Syntax: 2995 2996 2997:: 2998 2999 pragma Interface_Name ( 3000 [Entity =>] LOCAL_NAME 3001 [, [External_Name =>] static_string_EXPRESSION] 3002 [, [Link_Name =>] static_string_EXPRESSION]); 3003 3004 3005This pragma provides an alternative way of specifying the interface name 3006for an interfaced subprogram, and is provided for compatibility with Ada 300783 compilers that use the pragma for this purpose. You must provide at 3008least one of ``External_Name`` or ``Link_Name``. 3009 3010Pragma Interrupt_Handler 3011======================== 3012 3013Syntax: 3014 3015 3016.. code-block:: ada 3017 3018 pragma Interrupt_Handler (procedure_LOCAL_NAME); 3019 3020 3021This program unit pragma is supported for parameterless protected procedures 3022as described in Annex C of the Ada Reference Manual. On the AAMP target 3023the pragma can also be specified for nonprotected parameterless procedures 3024that are declared at the library level (which includes procedures 3025declared at the top level of a library package). In the case of AAMP, 3026when this pragma is applied to a nonprotected procedure, the instruction 3027``IERET`` is generated for returns from the procedure, enabling 3028maskable interrupts, in place of the normal return instruction. 3029 3030Pragma Interrupt_State 3031====================== 3032 3033Syntax: 3034 3035 3036:: 3037 3038 pragma Interrupt_State 3039 ([Name =>] value, 3040 [State =>] SYSTEM | RUNTIME | USER); 3041 3042 3043Normally certain interrupts are reserved to the implementation. Any attempt 3044to attach an interrupt causes Program_Error to be raised, as described in 3045RM C.3.2(22). A typical example is the ``SIGINT`` interrupt used in 3046many systems for an :kbd:`Ctrl-C` interrupt. Normally this interrupt is 3047reserved to the implementation, so that :kbd:`Ctrl-C` can be used to 3048interrupt execution. Additionally, signals such as ``SIGSEGV``, 3049``SIGABRT``, ``SIGFPE`` and ``SIGILL`` are often mapped to specific 3050Ada exceptions, or used to implement run-time functions such as the 3051``abort`` statement and stack overflow checking. 3052 3053Pragma ``Interrupt_State`` provides a general mechanism for overriding 3054such uses of interrupts. It subsumes the functionality of pragma 3055``Unreserve_All_Interrupts``. Pragma ``Interrupt_State`` is not 3056available on Windows or VMS. On all other platforms than VxWorks, 3057it applies to signals; on VxWorks, it applies to vectored hardware interrupts 3058and may be used to mark interrupts required by the board support package 3059as reserved. 3060 3061Interrupts can be in one of three states: 3062 3063* System 3064 3065 The interrupt is reserved (no Ada handler can be installed), and the 3066 Ada run-time may not install a handler. As a result you are guaranteed 3067 standard system default action if this interrupt is raised. This also allows 3068 installing a low level handler via C APIs such as sigaction(), outside 3069 of Ada control. 3070 3071* Runtime 3072 3073 The interrupt is reserved (no Ada handler can be installed). The run time 3074 is allowed to install a handler for internal control purposes, but is 3075 not required to do so. 3076 3077* User 3078 3079 The interrupt is unreserved. The user may install an Ada handler via 3080 Ada.Interrupts and pragma Interrupt_Handler or Attach_Handler to provide 3081 some other action. 3082 3083These states are the allowed values of the ``State`` parameter of the 3084pragma. The ``Name`` parameter is a value of the type 3085``Ada.Interrupts.Interrupt_ID``. Typically, it is a name declared in 3086``Ada.Interrupts.Names``. 3087 3088This is a configuration pragma, and the binder will check that there 3089are no inconsistencies between different units in a partition in how a 3090given interrupt is specified. It may appear anywhere a pragma is legal. 3091 3092The effect is to move the interrupt to the specified state. 3093 3094By declaring interrupts to be SYSTEM, you guarantee the standard system 3095action, such as a core dump. 3096 3097By declaring interrupts to be USER, you guarantee that you can install 3098a handler. 3099 3100Note that certain signals on many operating systems cannot be caught and 3101handled by applications. In such cases, the pragma is ignored. See the 3102operating system documentation, or the value of the array ``Reserved`` 3103declared in the spec of package ``System.OS_Interface``. 3104 3105Overriding the default state of signals used by the Ada runtime may interfere 3106with an application's runtime behavior in the cases of the synchronous signals, 3107and in the case of the signal used to implement the ``abort`` statement. 3108 3109.. _Pragma-Invariant: 3110 3111Pragma Invariant 3112================ 3113 3114Syntax: 3115 3116 3117:: 3118 3119 pragma Invariant 3120 ([Entity =>] private_type_LOCAL_NAME, 3121 [Check =>] EXPRESSION 3122 [,[Message =>] String_Expression]); 3123 3124 3125This pragma provides exactly the same capabilities as the Type_Invariant aspect 3126defined in AI05-0146-1, and in the Ada 2012 Reference Manual. The 3127Type_Invariant aspect is fully implemented in Ada 2012 mode, but since it 3128requires the use of the aspect syntax, which is not available except in 2012 3129mode, it is not possible to use the Type_Invariant aspect in earlier versions 3130of Ada. However the Invariant pragma may be used in any version of Ada. Also 3131note that the aspect Invariant is a synonym in GNAT for the aspect 3132Type_Invariant, but there is no pragma Type_Invariant. 3133 3134The pragma must appear within the visible part of the package specification, 3135after the type to which its Entity argument appears. As with the Invariant 3136aspect, the Check expression is not analyzed until the end of the visible 3137part of the package, so it may contain forward references. The Message 3138argument, if present, provides the exception message used if the invariant 3139is violated. If no Message parameter is provided, a default message that 3140identifies the line on which the pragma appears is used. 3141 3142It is permissible to have multiple Invariants for the same type entity, in 3143which case they are and'ed together. It is permissible to use this pragma 3144in Ada 2012 mode, but you cannot have both an invariant aspect and an 3145invariant pragma for the same entity. 3146 3147For further details on the use of this pragma, see the Ada 2012 documentation 3148of the Type_Invariant aspect. 3149 3150Pragma Keep_Names 3151================= 3152 3153Syntax: 3154 3155 3156:: 3157 3158 pragma Keep_Names ([On =>] enumeration_first_subtype_LOCAL_NAME); 3159 3160 3161The ``LOCAL_NAME`` argument 3162must refer to an enumeration first subtype 3163in the current declarative part. The effect is to retain the enumeration 3164literal names for use by ``Image`` and ``Value`` even if a global 3165``Discard_Names`` pragma applies. This is useful when you want to 3166generally suppress enumeration literal names and for example you therefore 3167use a ``Discard_Names`` pragma in the :file:`gnat.adc` file, but you 3168want to retain the names for specific enumeration types. 3169 3170Pragma License 3171============== 3172.. index:: License checking 3173 3174Syntax: 3175 3176 3177.. code-block:: ada 3178 3179 pragma License (Unrestricted | GPL | Modified_GPL | Restricted); 3180 3181 3182This pragma is provided to allow automated checking for appropriate license 3183conditions with respect to the standard and modified GPL. A pragma 3184``License``, which is a configuration pragma that typically appears at 3185the start of a source file or in a separate :file:`gnat.adc` file, specifies 3186the licensing conditions of a unit as follows: 3187 3188* Unrestricted 3189 This is used for a unit that can be freely used with no license restrictions. 3190 Examples of such units are public domain units, and units from the Ada 3191 Reference Manual. 3192 3193* GPL 3194 This is used for a unit that is licensed under the unmodified GPL, and which 3195 therefore cannot be ``with``\ ed by a restricted unit. 3196 3197* Modified_GPL 3198 This is used for a unit licensed under the GNAT modified GPL that includes 3199 a special exception paragraph that specifically permits the inclusion of 3200 the unit in programs without requiring the entire program to be released 3201 under the GPL. 3202 3203* Restricted 3204 This is used for a unit that is restricted in that it is not permitted to 3205 depend on units that are licensed under the GPL. Typical examples are 3206 proprietary code that is to be released under more restrictive license 3207 conditions. Note that restricted units are permitted to ``with`` units 3208 which are licensed under the modified GPL (this is the whole point of the 3209 modified GPL). 3210 3211 3212Normally a unit with no ``License`` pragma is considered to have an 3213unknown license, and no checking is done. However, standard GNAT headers 3214are recognized, and license information is derived from them as follows. 3215 3216A GNAT license header starts with a line containing 78 hyphens. The following 3217comment text is searched for the appearance of any of the following strings. 3218 3219If the string 'GNU General Public License' is found, then the unit is assumed 3220to have GPL license, unless the string 'As a special exception' follows, in 3221which case the license is assumed to be modified GPL. 3222 3223If one of the strings 3224'This specification is adapted from the Ada Semantic Interface' or 3225'This specification is derived from the Ada Reference Manual' is found 3226then the unit is assumed to be unrestricted. 3227 3228These default actions means that a program with a restricted license pragma 3229will automatically get warnings if a GPL unit is inappropriately 3230``with``\ ed. For example, the program: 3231 3232.. code-block:: ada 3233 3234 with Sem_Ch3; 3235 with GNAT.Sockets; 3236 procedure Secret_Stuff is 3237 ... 3238 end Secret_Stuff 3239 3240 3241if compiled with pragma ``License`` (``Restricted``) in a 3242:file:`gnat.adc` file will generate the warning:: 3243 3244 1. with Sem_Ch3; 3245 | 3246 >>> license of withed unit "Sem_Ch3" is incompatible 3247 3248 2. with GNAT.Sockets; 3249 3. procedure Secret_Stuff is 3250 3251 3252Here we get a warning on ``Sem_Ch3`` since it is part of the GNAT 3253compiler and is licensed under the 3254GPL, but no warning for ``GNAT.Sockets`` which is part of the GNAT 3255run time, and is therefore licensed under the modified GPL. 3256 3257Pragma Link_With 3258================ 3259 3260Syntax: 3261 3262 3263:: 3264 3265 pragma Link_With (static_string_EXPRESSION {,static_string_EXPRESSION}); 3266 3267 3268This pragma is provided for compatibility with certain Ada 83 compilers. 3269It has exactly the same effect as pragma ``Linker_Options`` except 3270that spaces occurring within one of the string expressions are treated 3271as separators. For example, in the following case: 3272 3273.. code-block:: ada 3274 3275 pragma Link_With ("-labc -ldef"); 3276 3277 3278results in passing the strings ``-labc`` and ``-ldef`` as two 3279separate arguments to the linker. In addition pragma Link_With allows 3280multiple arguments, with the same effect as successive pragmas. 3281 3282Pragma Linker_Alias 3283=================== 3284 3285Syntax: 3286 3287 3288:: 3289 3290 pragma Linker_Alias ( 3291 [Entity =>] LOCAL_NAME, 3292 [Target =>] static_string_EXPRESSION); 3293 3294 3295``LOCAL_NAME`` must refer to an object that is declared at the library 3296level. This pragma establishes the given entity as a linker alias for the 3297given target. It is equivalent to ``__attribute__((alias))`` in GNU C 3298and causes ``LOCAL_NAME`` to be emitted as an alias for the symbol 3299``static_string_EXPRESSION`` in the object file, that is to say no space 3300is reserved for ``LOCAL_NAME`` by the assembler and it will be resolved 3301to the same address as ``static_string_EXPRESSION`` by the linker. 3302 3303The actual linker name for the target must be used (e.g., the fully 3304encoded name with qualification in Ada, or the mangled name in C++), 3305or it must be declared using the C convention with ``pragma Import`` 3306or ``pragma Export``. 3307 3308Not all target machines support this pragma. On some of them it is accepted 3309only if ``pragma Weak_External`` has been applied to ``LOCAL_NAME``. 3310 3311 3312.. code-block:: ada 3313 3314 -- Example of the use of pragma Linker_Alias 3315 3316 package p is 3317 i : Integer := 1; 3318 pragma Export (C, i); 3319 3320 new_name_for_i : Integer; 3321 pragma Linker_Alias (new_name_for_i, "i"); 3322 end p; 3323 3324 3325Pragma Linker_Constructor 3326========================= 3327 3328Syntax: 3329 3330 3331.. code-block:: ada 3332 3333 pragma Linker_Constructor (procedure_LOCAL_NAME); 3334 3335 3336``procedure_LOCAL_NAME`` must refer to a parameterless procedure that 3337is declared at the library level. A procedure to which this pragma is 3338applied will be treated as an initialization routine by the linker. 3339It is equivalent to ``__attribute__((constructor))`` in GNU C and 3340causes ``procedure_LOCAL_NAME`` to be invoked before the entry point 3341of the executable is called (or immediately after the shared library is 3342loaded if the procedure is linked in a shared library), in particular 3343before the Ada run-time environment is set up. 3344 3345Because of these specific contexts, the set of operations such a procedure 3346can perform is very limited and the type of objects it can manipulate is 3347essentially restricted to the elementary types. In particular, it must only 3348contain code to which pragma Restrictions (No_Elaboration_Code) applies. 3349 3350This pragma is used by GNAT to implement auto-initialization of shared Stand 3351Alone Libraries, which provides a related capability without the restrictions 3352listed above. Where possible, the use of Stand Alone Libraries is preferable 3353to the use of this pragma. 3354 3355Pragma Linker_Destructor 3356======================== 3357 3358Syntax: 3359 3360 3361.. code-block:: ada 3362 3363 pragma Linker_Destructor (procedure_LOCAL_NAME); 3364 3365 3366``procedure_LOCAL_NAME`` must refer to a parameterless procedure that 3367is declared at the library level. A procedure to which this pragma is 3368applied will be treated as a finalization routine by the linker. 3369It is equivalent to ``__attribute__((destructor))`` in GNU C and 3370causes ``procedure_LOCAL_NAME`` to be invoked after the entry point 3371of the executable has exited (or immediately before the shared library 3372is unloaded if the procedure is linked in a shared library), in particular 3373after the Ada run-time environment is shut down. 3374 3375See ``pragma Linker_Constructor`` for the set of restrictions that apply 3376because of these specific contexts. 3377 3378.. _Pragma-Linker_Section: 3379 3380Pragma Linker_Section 3381===================== 3382 3383Syntax: 3384 3385 3386:: 3387 3388 pragma Linker_Section ( 3389 [Entity =>] LOCAL_NAME, 3390 [Section =>] static_string_EXPRESSION); 3391 3392 3393``LOCAL_NAME`` must refer to an object, type, or subprogram that is 3394declared at the library level. This pragma specifies the name of the 3395linker section for the given entity. It is equivalent to 3396``__attribute__((section))`` in GNU C and causes ``LOCAL_NAME`` to 3397be placed in the ``static_string_EXPRESSION`` section of the 3398executable (assuming the linker doesn't rename the section). 3399GNAT also provides an implementation defined aspect of the same name. 3400 3401In the case of specifying this aspect for a type, the effect is to 3402specify the corresponding section for all library-level objects of 3403the type that do not have an explicit linker section set. Note that 3404this only applies to whole objects, not to components of composite objects. 3405 3406In the case of a subprogram, the linker section applies to all previously 3407declared matching overloaded subprograms in the current declarative part 3408which do not already have a linker section assigned. The linker section 3409aspect is useful in this case for specifying different linker sections 3410for different elements of such an overloaded set. 3411 3412Note that an empty string specifies that no linker section is specified. 3413This is not quite the same as omitting the pragma or aspect, since it 3414can be used to specify that one element of an overloaded set of subprograms 3415has the default linker section, or that one object of a type for which a 3416linker section is specified should has the default linker section. 3417 3418The compiler normally places library-level entities in standard sections 3419depending on the class: procedures and functions generally go in the 3420``.text`` section, initialized variables in the ``.data`` section 3421and uninitialized variables in the ``.bss`` section. 3422 3423Other, special sections may exist on given target machines to map special 3424hardware, for example I/O ports or flash memory. This pragma is a means to 3425defer the final layout of the executable to the linker, thus fully working 3426at the symbolic level with the compiler. 3427 3428Some file formats do not support arbitrary sections so not all target 3429machines support this pragma. The use of this pragma may cause a program 3430execution to be erroneous if it is used to place an entity into an 3431inappropriate section (e.g., a modified variable into the ``.text`` 3432section). See also ``pragma Persistent_BSS``. 3433 3434 3435.. code-block:: ada 3436 3437 -- Example of the use of pragma Linker_Section 3438 3439 package IO_Card is 3440 Port_A : Integer; 3441 pragma Volatile (Port_A); 3442 pragma Linker_Section (Port_A, ".bss.port_a"); 3443 3444 Port_B : Integer; 3445 pragma Volatile (Port_B); 3446 pragma Linker_Section (Port_B, ".bss.port_b"); 3447 3448 type Port_Type is new Integer with Linker_Section => ".bss"; 3449 PA : Port_Type with Linker_Section => ".bss.PA"; 3450 PB : Port_Type; -- ends up in linker section ".bss" 3451 3452 procedure Q with Linker_Section => "Qsection"; 3453 end IO_Card; 3454 3455.. _Pragma-Lock_Free: 3456 3457Pragma Lock_Free 3458================ 3459 3460Syntax: 3461This pragma may be specified for protected types or objects. It specifies that 3462the implementation of protected operations must be implemented without locks. 3463Compilation fails if the compiler cannot generate lock-free code for the 3464operations. 3465 3466Pragma Loop_Invariant 3467===================== 3468 3469Syntax: 3470 3471 3472.. code-block:: ada 3473 3474 pragma Loop_Invariant ( boolean_EXPRESSION ); 3475 3476 3477The effect of this pragma is similar to that of pragma ``Assert``, 3478except that in an ``Assertion_Policy`` pragma, the identifier 3479``Loop_Invariant`` is used to control whether it is ignored or checked 3480(or disabled). 3481 3482``Loop_Invariant`` can only appear as one of the items in the sequence 3483of statements of a loop body, or nested inside block statements that 3484appear in the sequence of statements of a loop body. 3485The intention is that it be used to 3486represent a "loop invariant" assertion, i.e. something that is true each 3487time through the loop, and which can be used to show that the loop is 3488achieving its purpose. 3489 3490Multiple ``Loop_Invariant`` and ``Loop_Variant`` pragmas that 3491apply to the same loop should be grouped in the same sequence of 3492statements. 3493 3494To aid in writing such invariants, the special attribute ``Loop_Entry`` 3495may be used to refer to the value of an expression on entry to the loop. This 3496attribute can only be used within the expression of a ``Loop_Invariant`` 3497pragma. For full details, see documentation of attribute ``Loop_Entry``. 3498 3499Pragma Loop_Optimize 3500==================== 3501 3502Syntax: 3503 3504 3505:: 3506 3507 pragma Loop_Optimize (OPTIMIZATION_HINT {, OPTIMIZATION_HINT}); 3508 3509 OPTIMIZATION_HINT ::= Ivdep | No_Unroll | Unroll | No_Vector | Vector 3510 3511 3512This pragma must appear immediately within a loop statement. It allows the 3513programmer to specify optimization hints for the enclosing loop. The hints 3514are not mutually exclusive and can be freely mixed, but not all combinations 3515will yield a sensible outcome. 3516 3517There are five supported optimization hints for a loop: 3518 3519* Ivdep 3520 3521 The programmer asserts that there are no loop-carried dependencies 3522 which would prevent consecutive iterations of the loop from being 3523 executed simultaneously. 3524 3525* No_Unroll 3526 3527 The loop must not be unrolled. This is a strong hint: the compiler will not 3528 unroll a loop marked with this hint. 3529 3530* Unroll 3531 3532 The loop should be unrolled. This is a weak hint: the compiler will try to 3533 apply unrolling to this loop preferably to other optimizations, notably 3534 vectorization, but there is no guarantee that the loop will be unrolled. 3535 3536* No_Vector 3537 3538 The loop must not be vectorized. This is a strong hint: the compiler will not 3539 vectorize a loop marked with this hint. 3540 3541* Vector 3542 3543 The loop should be vectorized. This is a weak hint: the compiler will try to 3544 apply vectorization to this loop preferably to other optimizations, notably 3545 unrolling, but there is no guarantee that the loop will be vectorized. 3546 3547 3548These hints do not remove the need to pass the appropriate switches to the 3549compiler in order to enable the relevant optimizations, that is to say 3550*-funroll-loops* for unrolling and *-ftree-vectorize* for 3551vectorization. 3552 3553Pragma Loop_Variant 3554=================== 3555 3556Syntax: 3557 3558 3559:: 3560 3561 pragma Loop_Variant ( LOOP_VARIANT_ITEM {, LOOP_VARIANT_ITEM } ); 3562 LOOP_VARIANT_ITEM ::= CHANGE_DIRECTION => discrete_EXPRESSION 3563 CHANGE_DIRECTION ::= Increases | Decreases 3564 3565 3566``Loop_Variant`` can only appear as one of the items in the sequence 3567of statements of a loop body, or nested inside block statements that 3568appear in the sequence of statements of a loop body. 3569It allows the specification of quantities which must always 3570decrease or increase in successive iterations of the loop. In its simplest 3571form, just one expression is specified, whose value must increase or decrease 3572on each iteration of the loop. 3573 3574In a more complex form, multiple arguments can be given which are intepreted 3575in a nesting lexicographic manner. For example: 3576 3577.. code-block:: ada 3578 3579 pragma Loop_Variant (Increases => X, Decreases => Y); 3580 3581 3582specifies that each time through the loop either X increases, or X stays 3583the same and Y decreases. A ``Loop_Variant`` pragma ensures that the 3584loop is making progress. It can be useful in helping to show informally 3585or prove formally that the loop always terminates. 3586 3587``Loop_Variant`` is an assertion whose effect can be controlled using 3588an ``Assertion_Policy`` with a check name of ``Loop_Variant``. The 3589policy can be ``Check`` to enable the loop variant check, ``Ignore`` 3590to ignore the check (in which case the pragma has no effect on the program), 3591or ``Disable`` in which case the pragma is not even checked for correct 3592syntax. 3593 3594Multiple ``Loop_Invariant`` and ``Loop_Variant`` pragmas that 3595apply to the same loop should be grouped in the same sequence of 3596statements. 3597 3598The ``Loop_Entry`` attribute may be used within the expressions of the 3599``Loop_Variant`` pragma to refer to values on entry to the loop. 3600 3601Pragma Machine_Attribute 3602======================== 3603 3604Syntax: 3605 3606 3607:: 3608 3609 pragma Machine_Attribute ( 3610 [Entity =>] LOCAL_NAME, 3611 [Attribute_Name =>] static_string_EXPRESSION 3612 [, [Info =>] static_EXPRESSION] ); 3613 3614 3615Machine-dependent attributes can be specified for types and/or 3616declarations. This pragma is semantically equivalent to 3617:samp:`__attribute__(({attribute_name}))` (if ``info`` is not 3618specified) or :samp:`__attribute__(({attribute_name(info})))` 3619in GNU C, where *attribute_name* is recognized by the 3620compiler middle-end or the ``TARGET_ATTRIBUTE_TABLE`` machine 3621specific macro. A string literal for the optional parameter ``info`` 3622is transformed into an identifier, which may make this pragma unusable 3623for some attributes. 3624For further information see :title:`GNU Compiler Collection (GCC) Internals`. 3625 3626Pragma Main 3627=========== 3628 3629Syntax:: 3630 3631 pragma Main 3632 (MAIN_OPTION [, MAIN_OPTION]); 3633 3634 MAIN_OPTION ::= 3635 [Stack_Size =>] static_integer_EXPRESSION 3636 | [Task_Stack_Size_Default =>] static_integer_EXPRESSION 3637 | [Time_Slicing_Enabled =>] static_boolean_EXPRESSION 3638 3639 3640This pragma is provided for compatibility with OpenVMS VAX Systems. It has 3641no effect in GNAT, other than being syntax checked. 3642 3643Pragma Main_Storage 3644=================== 3645 3646Syntax:: 3647 3648 pragma Main_Storage 3649 (MAIN_STORAGE_OPTION [, MAIN_STORAGE_OPTION]); 3650 3651 MAIN_STORAGE_OPTION ::= 3652 [WORKING_STORAGE =>] static_SIMPLE_EXPRESSION 3653 | [TOP_GUARD =>] static_SIMPLE_EXPRESSION 3654 3655 3656This pragma is provided for compatibility with OpenVMS VAX Systems. It has 3657no effect in GNAT, other than being syntax checked. 3658 3659.. _Pragma-Max_Queue_Length: 3660 3661Pragma Max_Queue_Length 3662======================= 3663 3664Syntax:: 3665 3666 pragma Max_Entry_Queue (static_integer_EXPRESSION); 3667 3668 3669This pragma is used to specify the maximum callers per entry queue for 3670individual protected entries and entry families. It accepts a single 3671positive integer as a parameter and must appear after the declaration 3672of an entry. 3673 3674Pragma No_Body 3675============== 3676 3677Syntax: 3678 3679 3680.. code-block:: ada 3681 3682 pragma No_Body; 3683 3684 3685There are a number of cases in which a package spec does not require a body, 3686and in fact a body is not permitted. GNAT will not permit the spec to be 3687compiled if there is a body around. The pragma No_Body allows you to provide 3688a body file, even in a case where no body is allowed. The body file must 3689contain only comments and a single No_Body pragma. This is recognized by 3690the compiler as indicating that no body is logically present. 3691 3692This is particularly useful during maintenance when a package is modified in 3693such a way that a body needed before is no longer needed. The provision of a 3694dummy body with a No_Body pragma ensures that there is no interference from 3695earlier versions of the package body. 3696 3697Pragma No_Component_Reordering 3698============================== 3699 3700Syntax: 3701 3702 3703:: 3704 3705 pragma No_Component_Reordering [([Entity =>] type_LOCAL_NAME)]; 3706 3707 3708``type_LOCAL_NAME`` must refer to a record type declaration in the current 3709declarative part. The effect is to preclude any reordering of components 3710for the layout of the record, i.e. the record is laid out by the compiler 3711in the order in which the components are declared textually. The form with 3712no argument is a configuration pragma which applies to all record types 3713declared in units to which the pragma applies and there is a requirement 3714that this pragma be used consistently within a partition. 3715 3716.. _Pragma-No_Elaboration_Code_All: 3717 3718Pragma No_Elaboration_Code_All 3719============================== 3720 3721Syntax: 3722 3723 3724:: 3725 3726 pragma No_Elaboration_Code_All [(program_unit_NAME)]; 3727 3728 3729This is a program unit pragma (there is also an equivalent aspect of the 3730same name) that establishes the restriction ``No_Elaboration_Code`` for 3731the current unit and any extended main source units (body and subunits). 3732It also has the effect of enforcing a transitive application of this 3733aspect, so that if any unit is implicitly or explicitly with'ed by the 3734current unit, it must also have the No_Elaboration_Code_All aspect set. 3735It may be applied to package or subprogram specs or their generic versions. 3736 3737Pragma No_Heap_Finalization 3738=========================== 3739 3740Syntax: 3741 3742 3743:: 3744 3745 pragma No_Heap_Finalization [ (first_subtype_LOCAL_NAME) ]; 3746 3747 3748Pragma ``No_Heap_Finalization`` may be used as a configuration pragma or as a 3749type-specific pragma. 3750 3751In its configuration form, the pragma must appear within a configuration file 3752such as gnat.adc, without an argument. The pragma suppresses the call to 3753``Finalize`` for heap-allocated objects created through library-level named 3754access-to-object types in cases where the designated type requires finalization 3755actions. 3756 3757In its type-specific form, the argument of the pragma must denote a 3758library-level named access-to-object type. The pragma suppresses the call to 3759``Finalize`` for heap-allocated objects created through the specific access type 3760in cases where the designated type requires finalization actions. 3761 3762It is still possible to finalize such heap-allocated objects by explicitly 3763deallocating them. 3764 3765A library-level named access-to-object type declared within a generic unit will 3766lose its ``No_Heap_Finalization`` pragma when the corresponding instance does not 3767appear at the library level. 3768 3769.. _Pragma-No_Inline: 3770 3771Pragma No_Inline 3772================ 3773 3774Syntax: 3775 3776 3777:: 3778 3779 pragma No_Inline (NAME {, NAME}); 3780 3781 3782This pragma suppresses inlining for the callable entity or the instances of 3783the generic subprogram designated by ``NAME``, including inlining that 3784results from the use of pragma ``Inline``. This pragma is always active, 3785in particular it is not subject to the use of option *-gnatn* or 3786*-gnatN*. It is illegal to specify both pragma ``No_Inline`` and 3787pragma ``Inline_Always`` for the same ``NAME``. 3788 3789Pragma No_Return 3790================ 3791 3792Syntax: 3793 3794 3795:: 3796 3797 pragma No_Return (procedure_LOCAL_NAME {, procedure_LOCAL_NAME}); 3798 3799 3800Each ``procedure_LOCAL_NAME`` argument must refer to one or more procedure 3801declarations in the current declarative part. A procedure to which this 3802pragma is applied may not contain any explicit ``return`` statements. 3803In addition, if the procedure contains any implicit returns from falling 3804off the end of a statement sequence, then execution of that implicit 3805return will cause Program_Error to be raised. 3806 3807One use of this pragma is to identify procedures whose only purpose is to raise 3808an exception. Another use of this pragma is to suppress incorrect warnings 3809about missing returns in functions, where the last statement of a function 3810statement sequence is a call to such a procedure. 3811 3812Note that in Ada 2005 mode, this pragma is part of the language. It is 3813available in all earlier versions of Ada as an implementation-defined 3814pragma. 3815 3816Pragma No_Run_Time 3817================== 3818 3819Syntax: 3820 3821 3822.. code-block:: ada 3823 3824 pragma No_Run_Time; 3825 3826 3827This is an obsolete configuration pragma that historically was used to 3828set up a runtime library with no object code. It is now used only for 3829internal testing. The pragma has been superseded by the reconfigurable 3830runtime capability of GNAT. 3831 3832Pragma No_Strict_Aliasing 3833========================= 3834 3835Syntax: 3836 3837 3838:: 3839 3840 pragma No_Strict_Aliasing [([Entity =>] type_LOCAL_NAME)]; 3841 3842 3843``type_LOCAL_NAME`` must refer to an access type 3844declaration in the current declarative part. The effect is to inhibit 3845strict aliasing optimization for the given type. The form with no 3846arguments is a configuration pragma which applies to all access types 3847declared in units to which the pragma applies. For a detailed 3848description of the strict aliasing optimization, and the situations 3849in which it must be suppressed, see the section on Optimization and Strict Aliasing 3850in the :title:`GNAT User's Guide`. 3851 3852This pragma currently has no effects on access to unconstrained array types. 3853 3854.. _Pragma-No_Tagged_Streams: 3855 3856Pragma No_Tagged_Streams 3857======================== 3858 3859Syntax: 3860 3861 3862:: 3863 3864 pragma No_Tagged_Streams [([Entity =>] tagged_type_LOCAL_NAME)]; 3865 3866 3867Normally when a tagged type is introduced using a full type declaration, 3868part of the processing includes generating stream access routines to be 3869used by stream attributes referencing the type (or one of its subtypes 3870or derived types). This can involve the generation of significant amounts 3871of code which is wasted space if stream routines are not needed for the 3872type in question. 3873 3874The ``No_Tagged_Streams`` pragma causes the generation of these stream 3875routines to be skipped, and any attempt to use stream operations on 3876types subject to this pragma will be statically rejected as illegal. 3877 3878There are two forms of the pragma. The form with no arguments must appear 3879in a declarative sequence or in the declarations of a package spec. This 3880pragma affects all subsequent root tagged types declared in the declaration 3881sequence, and specifies that no stream routines be generated. The form with 3882an argument (for which there is also a corresponding aspect) specifies a 3883single root tagged type for which stream routines are not to be generated. 3884 3885Once the pragma has been given for a particular root tagged type, all subtypes 3886and derived types of this type inherit the pragma automatically, so the effect 3887applies to a complete hierarchy (this is necessary to deal with the class-wide 3888dispatching versions of the stream routines). 3889 3890Pragma Normalize_Scalars 3891======================== 3892 3893Syntax: 3894 3895 3896.. code-block:: ada 3897 3898 pragma Normalize_Scalars; 3899 3900 3901This is a language defined pragma which is fully implemented in GNAT. The 3902effect is to cause all scalar objects that are not otherwise initialized 3903to be initialized. The initial values are implementation dependent and 3904are as follows: 3905 3906 3907 3908*Standard.Character* 3909 Objects whose root type is Standard.Character are initialized to 3910 Character'Last unless the subtype range excludes NUL (in which case 3911 NUL is used). This choice will always generate an invalid value if 3912 one exists. 3913 3914 3915*Standard.Wide_Character* 3916 Objects whose root type is Standard.Wide_Character are initialized to 3917 Wide_Character'Last unless the subtype range excludes NUL (in which case 3918 NUL is used). This choice will always generate an invalid value if 3919 one exists. 3920 3921 3922*Standard.Wide_Wide_Character* 3923 Objects whose root type is Standard.Wide_Wide_Character are initialized to 3924 the invalid value 16#FFFF_FFFF# unless the subtype range excludes NUL (in 3925 which case NUL is used). This choice will always generate an invalid value if 3926 one exists. 3927 3928 3929*Integer types* 3930 Objects of an integer type are treated differently depending on whether 3931 negative values are present in the subtype. If no negative values are 3932 present, then all one bits is used as the initial value except in the 3933 special case where zero is excluded from the subtype, in which case 3934 all zero bits are used. This choice will always generate an invalid 3935 value if one exists. 3936 3937 For subtypes with negative values present, the largest negative number 3938 is used, except in the unusual case where this largest negative number 3939 is in the subtype, and the largest positive number is not, in which case 3940 the largest positive value is used. This choice will always generate 3941 an invalid value if one exists. 3942 3943 3944*Floating-Point Types* 3945 Objects of all floating-point types are initialized to all 1-bits. For 3946 standard IEEE format, this corresponds to a NaN (not a number) which is 3947 indeed an invalid value. 3948 3949 3950*Fixed-Point Types* 3951 Objects of all fixed-point types are treated as described above for integers, 3952 with the rules applying to the underlying integer value used to represent 3953 the fixed-point value. 3954 3955 3956*Modular types* 3957 Objects of a modular type are initialized to all one bits, except in 3958 the special case where zero is excluded from the subtype, in which 3959 case all zero bits are used. This choice will always generate an 3960 invalid value if one exists. 3961 3962 3963*Enumeration types* 3964 Objects of an enumeration type are initialized to all one-bits, i.e., to 3965 the value ``2 ** typ'Size - 1`` unless the subtype excludes the literal 3966 whose Pos value is zero, in which case a code of zero is used. This choice 3967 will always generate an invalid value if one exists. 3968 3969.. _Pragma_Obsolescent: 3970 3971Pragma Obsolescent 3972================== 3973 3974Syntax: 3975 3976 3977:: 3978 3979 pragma Obsolescent; 3980 3981 pragma Obsolescent ( 3982 [Message =>] static_string_EXPRESSION 3983 [,[Version =>] Ada_05]]); 3984 3985 pragma Obsolescent ( 3986 [Entity =>] NAME 3987 [,[Message =>] static_string_EXPRESSION 3988 [,[Version =>] Ada_05]] ); 3989 3990 3991This pragma can occur immediately following a declaration of an entity, 3992including the case of a record component. If no Entity argument is present, 3993then this declaration is the one to which the pragma applies. If an Entity 3994parameter is present, it must either match the name of the entity in this 3995declaration, or alternatively, the pragma can immediately follow an enumeration 3996type declaration, where the Entity argument names one of the enumeration 3997literals. 3998 3999This pragma is used to indicate that the named entity 4000is considered obsolescent and should not be used. Typically this is 4001used when an API must be modified by eventually removing or modifying 4002existing subprograms or other entities. The pragma can be used at an 4003intermediate stage when the entity is still present, but will be 4004removed later. 4005 4006The effect of this pragma is to output a warning message on a reference to 4007an entity thus marked that the subprogram is obsolescent if the appropriate 4008warning option in the compiler is activated. If the ``Message`` parameter is 4009present, then a second warning message is given containing this text. In 4010addition, a reference to the entity is considered to be a violation of pragma 4011``Restrictions (No_Obsolescent_Features)``. 4012 4013This pragma can also be used as a program unit pragma for a package, 4014in which case the entity name is the name of the package, and the 4015pragma indicates that the entire package is considered 4016obsolescent. In this case a client ``with``\ ing such a package 4017violates the restriction, and the ``with`` clause is 4018flagged with warnings if the warning option is set. 4019 4020If the ``Version`` parameter is present (which must be exactly 4021the identifier ``Ada_05``, no other argument is allowed), then the 4022indication of obsolescence applies only when compiling in Ada 2005 4023mode. This is primarily intended for dealing with the situations 4024in the predefined library where subprograms or packages 4025have become defined as obsolescent in Ada 2005 4026(e.g., in ``Ada.Characters.Handling``), but may be used anywhere. 4027 4028The following examples show typical uses of this pragma: 4029 4030 4031.. code-block:: ada 4032 4033 package p is 4034 pragma Obsolescent (p, Message => "use pp instead of p"); 4035 end p; 4036 4037 package q is 4038 procedure q2; 4039 pragma Obsolescent ("use q2new instead"); 4040 4041 type R is new integer; 4042 pragma Obsolescent 4043 (Entity => R, 4044 Message => "use RR in Ada 2005", 4045 Version => Ada_05); 4046 4047 type M is record 4048 F1 : Integer; 4049 F2 : Integer; 4050 pragma Obsolescent; 4051 F3 : Integer; 4052 end record; 4053 4054 type E is (a, bc, 'd', quack); 4055 pragma Obsolescent (Entity => bc) 4056 pragma Obsolescent (Entity => 'd') 4057 4058 function "+" 4059 (a, b : character) return character; 4060 pragma Obsolescent (Entity => "+"); 4061 end; 4062 4063 4064Note that, as for all pragmas, if you use a pragma argument identifier, 4065then all subsequent parameters must also use a pragma argument identifier. 4066So if you specify ``Entity =>`` for the ``Entity`` argument, and a ``Message`` 4067argument is present, it must be preceded by ``Message =>``. 4068 4069Pragma Optimize_Alignment 4070========================= 4071.. index:: Alignment, default settings 4072 4073Syntax: 4074 4075 4076.. code-block:: ada 4077 4078 pragma Optimize_Alignment (TIME | SPACE | OFF); 4079 4080 4081This is a configuration pragma which affects the choice of default alignments 4082for types and objects where no alignment is explicitly specified. There is a 4083time/space trade-off in the selection of these values. Large alignments result 4084in more efficient code, at the expense of larger data space, since sizes have 4085to be increased to match these alignments. Smaller alignments save space, but 4086the access code is slower. The normal choice of default alignments for types 4087and individual alignment promotions for objects (which is what you get if you 4088do not use this pragma, or if you use an argument of OFF), tries to balance 4089these two requirements. 4090 4091Specifying SPACE causes smaller default alignments to be chosen in two cases. 4092First any packed record is given an alignment of 1. Second, if a size is given 4093for the type, then the alignment is chosen to avoid increasing this size. For 4094example, consider: 4095 4096 4097.. code-block:: ada 4098 4099 type R is record 4100 X : Integer; 4101 Y : Character; 4102 end record; 4103 4104 for R'Size use 5*8; 4105 4106 4107In the default mode, this type gets an alignment of 4, so that access to the 4108Integer field X are efficient. But this means that objects of the type end up 4109with a size of 8 bytes. This is a valid choice, since sizes of objects are 4110allowed to be bigger than the size of the type, but it can waste space if for 4111example fields of type R appear in an enclosing record. If the above type is 4112compiled in ``Optimize_Alignment (Space)`` mode, the alignment is set to 1. 4113 4114However, there is one case in which SPACE is ignored. If a variable length 4115record (that is a discriminated record with a component which is an array 4116whose length depends on a discriminant), has a pragma Pack, then it is not 4117in general possible to set the alignment of such a record to one, so the 4118pragma is ignored in this case (with a warning). 4119 4120Specifying SPACE also disables alignment promotions for standalone objects, 4121which occur when the compiler increases the alignment of a specific object 4122without changing the alignment of its type. 4123 4124Specifying SPACE also disables component reordering in unpacked record types, 4125which can result in larger sizes in order to meet alignment requirements. 4126 4127Specifying TIME causes larger default alignments to be chosen in the case of 4128small types with sizes that are not a power of 2. For example, consider: 4129 4130 4131.. code-block:: ada 4132 4133 type R is record 4134 A : Character; 4135 B : Character; 4136 C : Boolean; 4137 end record; 4138 4139 pragma Pack (R); 4140 for R'Size use 17; 4141 4142 4143The default alignment for this record is normally 1, but if this type is 4144compiled in ``Optimize_Alignment (Time)`` mode, then the alignment is set 4145to 4, which wastes space for objects of the type, since they are now 4 bytes 4146long, but results in more efficient access when the whole record is referenced. 4147 4148As noted above, this is a configuration pragma, and there is a requirement 4149that all units in a partition be compiled with a consistent setting of the 4150optimization setting. This would normally be achieved by use of a configuration 4151pragma file containing the appropriate setting. The exception to this rule is 4152that units with an explicit configuration pragma in the same file as the source 4153unit are excluded from the consistency check, as are all predefined units. The 4154latter are compiled by default in pragma Optimize_Alignment (Off) mode if no 4155pragma appears at the start of the file. 4156 4157Pragma Ordered 4158============== 4159 4160Syntax: 4161 4162 4163.. code-block:: ada 4164 4165 pragma Ordered (enumeration_first_subtype_LOCAL_NAME); 4166 4167 4168Most enumeration types are from a conceptual point of view unordered. 4169For example, consider: 4170 4171 4172.. code-block:: ada 4173 4174 type Color is (Red, Blue, Green, Yellow); 4175 4176 4177By Ada semantics ``Blue > Red`` and ``Green > Blue``, 4178but really these relations make no sense; the enumeration type merely 4179specifies a set of possible colors, and the order is unimportant. 4180 4181For unordered enumeration types, it is generally a good idea if 4182clients avoid comparisons (other than equality or inequality) and 4183explicit ranges. (A *client* is a unit where the type is referenced, 4184other than the unit where the type is declared, its body, and its subunits.) 4185For example, if code buried in some client says: 4186 4187 4188.. code-block:: ada 4189 4190 if Current_Color < Yellow then ... 4191 if Current_Color in Blue .. Green then ... 4192 4193 4194then the client code is relying on the order, which is undesirable. 4195It makes the code hard to read and creates maintenance difficulties if 4196entries have to be added to the enumeration type. Instead, 4197the code in the client should list the possibilities, or an 4198appropriate subtype should be declared in the unit that declares 4199the original enumeration type. E.g., the following subtype could 4200be declared along with the type ``Color``: 4201 4202 4203.. code-block:: ada 4204 4205 subtype RBG is Color range Red .. Green; 4206 4207 4208and then the client could write: 4209 4210 4211.. code-block:: ada 4212 4213 if Current_Color in RBG then ... 4214 if Current_Color = Blue or Current_Color = Green then ... 4215 4216 4217However, some enumeration types are legitimately ordered from a conceptual 4218point of view. For example, if you declare: 4219 4220 4221.. code-block:: ada 4222 4223 type Day is (Mon, Tue, Wed, Thu, Fri, Sat, Sun); 4224 4225 4226then the ordering imposed by the language is reasonable, and 4227clients can depend on it, writing for example: 4228 4229 4230.. code-block:: ada 4231 4232 if D in Mon .. Fri then ... 4233 if D < Wed then ... 4234 4235 4236The pragma *Ordered* is provided to mark enumeration types that 4237are conceptually ordered, alerting the reader that clients may depend 4238on the ordering. GNAT provides a pragma to mark enumerations as ordered 4239rather than one to mark them as unordered, since in our experience, 4240the great majority of enumeration types are conceptually unordered. 4241 4242The types ``Boolean``, ``Character``, ``Wide_Character``, 4243and ``Wide_Wide_Character`` 4244are considered to be ordered types, so each is declared with a 4245pragma ``Ordered`` in package ``Standard``. 4246 4247Normally pragma ``Ordered`` serves only as documentation and a guide for 4248coding standards, but GNAT provides a warning switch *-gnatw.u* that 4249requests warnings for inappropriate uses (comparisons and explicit 4250subranges) for unordered types. If this switch is used, then any 4251enumeration type not marked with pragma ``Ordered`` will be considered 4252as unordered, and will generate warnings for inappropriate uses. 4253 4254Note that generic types are not considered ordered or unordered (since the 4255template can be instantiated for both cases), so we never generate warnings 4256for the case of generic enumerated types. 4257 4258For additional information please refer to the description of the 4259*-gnatw.u* switch in the GNAT User's Guide. 4260 4261Pragma Overflow_Mode 4262==================== 4263 4264Syntax: 4265 4266 4267:: 4268 4269 pragma Overflow_Mode 4270 ( [General =>] MODE 4271 [,[Assertions =>] MODE]); 4272 4273 MODE ::= STRICT | MINIMIZED | ELIMINATED 4274 4275 4276This pragma sets the current overflow mode to the given setting. For details 4277of the meaning of these modes, please refer to the 4278'Overflow Check Handling in GNAT' appendix in the 4279GNAT User's Guide. If only the ``General`` parameter is present, 4280the given mode applies to all expressions. If both parameters are present, 4281the ``General`` mode applies to expressions outside assertions, and 4282the ``Eliminated`` mode applies to expressions within assertions. 4283 4284The case of the ``MODE`` parameter is ignored, 4285so ``MINIMIZED``, ``Minimized`` and 4286``minimized`` all have the same effect. 4287 4288The ``Overflow_Mode`` pragma has the same scoping and placement 4289rules as pragma ``Suppress``, so it can occur either as a 4290configuration pragma, specifying a default for the whole 4291program, or in a declarative scope, where it applies to the 4292remaining declarations and statements in that scope. 4293 4294The pragma ``Suppress (Overflow_Check)`` suppresses 4295overflow checking, but does not affect the overflow mode. 4296 4297The pragma ``Unsuppress (Overflow_Check)`` unsuppresses (enables) 4298overflow checking, but does not affect the overflow mode. 4299 4300Pragma Overriding_Renamings 4301=========================== 4302.. index:: Rational profile 4303 4304.. index:: Rational compatibility 4305 4306Syntax: 4307 4308 4309.. code-block:: ada 4310 4311 pragma Overriding_Renamings; 4312 4313 4314This is a GNAT configuration pragma to simplify porting 4315legacy code accepted by the Rational 4316Ada compiler. In the presence of this pragma, a renaming declaration that 4317renames an inherited operation declared in the same scope is legal if selected 4318notation is used as in: 4319 4320 4321.. code-block:: ada 4322 4323 pragma Overriding_Renamings; 4324 ... 4325 package R is 4326 function F (..); 4327 ... 4328 function F (..) renames R.F; 4329 end R; 4330 4331 4332even though 4333RM 8.3 (15) stipulates that an overridden operation is not visible within the 4334declaration of the overriding operation. 4335 4336Pragma Partition_Elaboration_Policy 4337=================================== 4338 4339Syntax: 4340 4341 4342:: 4343 4344 pragma Partition_Elaboration_Policy (POLICY_IDENTIFIER); 4345 4346 POLICY_IDENTIFIER ::= Concurrent | Sequential 4347 4348 4349This pragma is standard in Ada 2005, but is available in all earlier 4350versions of Ada as an implementation-defined pragma. 4351See Ada 2012 Reference Manual for details. 4352 4353.. _Pragma-Part_Of: 4354 4355Pragma Part_Of 4356============== 4357 4358Syntax: 4359 4360.. code-block:: ada 4361 4362 pragma Part_Of (ABSTRACT_STATE); 4363 4364 ABSTRACT_STATE ::= NAME 4365 4366For the semantics of this pragma, see the entry for aspect ``Part_Of`` in the 4367SPARK 2014 Reference Manual, section 7.2.6. 4368 4369Pragma Passive 4370============== 4371 4372Syntax: 4373 4374 4375:: 4376 4377 pragma Passive [(Semaphore | No)]; 4378 4379 4380Syntax checked, but otherwise ignored by GNAT. This is recognized for 4381compatibility with DEC Ada 83 implementations, where it is used within a 4382task definition to request that a task be made passive. If the argument 4383``Semaphore`` is present, or the argument is omitted, then DEC Ada 83 4384treats the pragma as an assertion that the containing task is passive 4385and that optimization of context switch with this task is permitted and 4386desired. If the argument ``No`` is present, the task must not be 4387optimized. GNAT does not attempt to optimize any tasks in this manner 4388(since protected objects are available in place of passive tasks). 4389 4390For more information on the subject of passive tasks, see the section 4391'Passive Task Optimization' in the GNAT Users Guide. 4392 4393.. _Pragma-Persistent_BSS: 4394 4395Pragma Persistent_BSS 4396===================== 4397 4398Syntax: 4399 4400 4401:: 4402 4403 pragma Persistent_BSS [(LOCAL_NAME)] 4404 4405 4406This pragma allows selected objects to be placed in the ``.persistent_bss`` 4407section. On some targets the linker and loader provide for special 4408treatment of this section, allowing a program to be reloaded without 4409affecting the contents of this data (hence the name persistent). 4410 4411There are two forms of usage. If an argument is given, it must be the 4412local name of a library-level object, with no explicit initialization 4413and whose type is potentially persistent. If no argument is given, then 4414the pragma is a configuration pragma, and applies to all library-level 4415objects with no explicit initialization of potentially persistent types. 4416 4417A potentially persistent type is a scalar type, or an untagged, 4418non-discriminated record, all of whose components have no explicit 4419initialization and are themselves of a potentially persistent type, 4420or an array, all of whose constraints are static, and whose component 4421type is potentially persistent. 4422 4423If this pragma is used on a target where this feature is not supported, 4424then the pragma will be ignored. See also ``pragma Linker_Section``. 4425 4426Pragma Polling 4427============== 4428 4429Syntax: 4430 4431 4432.. code-block:: ada 4433 4434 pragma Polling (ON | OFF); 4435 4436 4437This pragma controls the generation of polling code. This is normally off. 4438If ``pragma Polling (ON)`` is used then periodic calls are generated to 4439the routine ``Ada.Exceptions.Poll``. This routine is a separate unit in the 4440runtime library, and can be found in file :file:`a-excpol.adb`. 4441 4442Pragma ``Polling`` can appear as a configuration pragma (for example it 4443can be placed in the :file:`gnat.adc` file) to enable polling globally, or it 4444can be used in the statement or declaration sequence to control polling 4445more locally. 4446 4447A call to the polling routine is generated at the start of every loop and 4448at the start of every subprogram call. This guarantees that the ``Poll`` 4449routine is called frequently, and places an upper bound (determined by 4450the complexity of the code) on the period between two ``Poll`` calls. 4451 4452The primary purpose of the polling interface is to enable asynchronous 4453aborts on targets that cannot otherwise support it (for example Windows 4454NT), but it may be used for any other purpose requiring periodic polling. 4455The standard version is null, and can be replaced by a user program. This 4456will require re-compilation of the ``Ada.Exceptions`` package that can 4457be found in files :file:`a-except.ads` and :file:`a-except.adb`. 4458 4459A standard alternative unit (in file :file:`4wexcpol.adb` in the standard GNAT 4460distribution) is used to enable the asynchronous abort capability on 4461targets that do not normally support the capability. The version of 4462``Poll`` in this file makes a call to the appropriate runtime routine 4463to test for an abort condition. 4464 4465Note that polling can also be enabled by use of the *-gnatP* switch. 4466See the section on switches for gcc in the :title:`GNAT User's Guide`. 4467 4468Pragma Post 4469=========== 4470.. index:: Post 4471 4472.. index:: Checks, postconditions 4473 4474 4475Syntax: 4476 4477 4478.. code-block:: ada 4479 4480 pragma Post (Boolean_Expression); 4481 4482 4483The ``Post`` pragma is intended to be an exact replacement for 4484the language-defined 4485``Post`` aspect, and shares its restrictions and semantics. 4486It must appear either immediately following the corresponding 4487subprogram declaration (only other pragmas may intervene), or 4488if there is no separate subprogram declaration, then it can 4489appear at the start of the declarations in a subprogram body 4490(preceded only by other pragmas). 4491 4492Pragma Postcondition 4493==================== 4494.. index:: Postcondition 4495 4496.. index:: Checks, postconditions 4497 4498 4499Syntax: 4500 4501 4502:: 4503 4504 pragma Postcondition ( 4505 [Check =>] Boolean_Expression 4506 [,[Message =>] String_Expression]); 4507 4508 4509The ``Postcondition`` pragma allows specification of automatic 4510postcondition checks for subprograms. These checks are similar to 4511assertions, but are automatically inserted just prior to the return 4512statements of the subprogram with which they are associated (including 4513implicit returns at the end of procedure bodies and associated 4514exception handlers). 4515 4516In addition, the boolean expression which is the condition which 4517must be true may contain references to function'Result in the case 4518of a function to refer to the returned value. 4519 4520``Postcondition`` pragmas may appear either immediately following the 4521(separate) declaration of a subprogram, or at the start of the 4522declarations of a subprogram body. Only other pragmas may intervene 4523(that is appear between the subprogram declaration and its 4524postconditions, or appear before the postcondition in the 4525declaration sequence in a subprogram body). In the case of a 4526postcondition appearing after a subprogram declaration, the 4527formal arguments of the subprogram are visible, and can be 4528referenced in the postcondition expressions. 4529 4530The postconditions are collected and automatically tested just 4531before any return (implicit or explicit) in the subprogram body. 4532A postcondition is only recognized if postconditions are active 4533at the time the pragma is encountered. The compiler switch *gnata* 4534turns on all postconditions by default, and pragma ``Check_Policy`` 4535with an identifier of ``Postcondition`` can also be used to 4536control whether postconditions are active. 4537 4538The general approach is that postconditions are placed in the spec 4539if they represent functional aspects which make sense to the client. 4540For example we might have: 4541 4542 4543.. code-block:: ada 4544 4545 function Direction return Integer; 4546 pragma Postcondition 4547 (Direction'Result = +1 4548 or else 4549 Direction'Result = -1); 4550 4551 4552which serves to document that the result must be +1 or -1, and 4553will test that this is the case at run time if postcondition 4554checking is active. 4555 4556Postconditions within the subprogram body can be used to 4557check that some internal aspect of the implementation, 4558not visible to the client, is operating as expected. 4559For instance if a square root routine keeps an internal 4560counter of the number of times it is called, then we 4561might have the following postcondition: 4562 4563 4564.. code-block:: ada 4565 4566 Sqrt_Calls : Natural := 0; 4567 4568 function Sqrt (Arg : Float) return Float is 4569 pragma Postcondition 4570 (Sqrt_Calls = Sqrt_Calls'Old + 1); 4571 ... 4572 end Sqrt 4573 4574 4575As this example, shows, the use of the ``Old`` attribute 4576is often useful in postconditions to refer to the state on 4577entry to the subprogram. 4578 4579Note that postconditions are only checked on normal returns 4580from the subprogram. If an abnormal return results from 4581raising an exception, then the postconditions are not checked. 4582 4583If a postcondition fails, then the exception 4584``System.Assertions.Assert_Failure`` is raised. If 4585a message argument was supplied, then the given string 4586will be used as the exception message. If no message 4587argument was supplied, then the default message has 4588the form "Postcondition failed at file_name:line". The 4589exception is raised in the context of the subprogram 4590body, so it is possible to catch postcondition failures 4591within the subprogram body itself. 4592 4593Within a package spec, normal visibility rules 4594in Ada would prevent forward references within a 4595postcondition pragma to functions defined later in 4596the same package. This would introduce undesirable 4597ordering constraints. To avoid this problem, all 4598postcondition pragmas are analyzed at the end of 4599the package spec, allowing forward references. 4600 4601The following example shows that this even allows 4602mutually recursive postconditions as in: 4603 4604 4605.. code-block:: ada 4606 4607 package Parity_Functions is 4608 function Odd (X : Natural) return Boolean; 4609 pragma Postcondition 4610 (Odd'Result = 4611 (x = 1 4612 or else 4613 (x /= 0 and then Even (X - 1)))); 4614 4615 function Even (X : Natural) return Boolean; 4616 pragma Postcondition 4617 (Even'Result = 4618 (x = 0 4619 or else 4620 (x /= 1 and then Odd (X - 1)))); 4621 4622 end Parity_Functions; 4623 4624 4625There are no restrictions on the complexity or form of 4626conditions used within ``Postcondition`` pragmas. 4627The following example shows that it is even possible 4628to verify performance behavior. 4629 4630 4631.. code-block:: ada 4632 4633 package Sort is 4634 4635 Performance : constant Float; 4636 -- Performance constant set by implementation 4637 -- to match target architecture behavior. 4638 4639 procedure Treesort (Arg : String); 4640 -- Sorts characters of argument using N*logN sort 4641 pragma Postcondition 4642 (Float (Clock - Clock'Old) <= 4643 Float (Arg'Length) * 4644 log (Float (Arg'Length)) * 4645 Performance); 4646 end Sort; 4647 4648 4649Note: postcondition pragmas associated with subprograms that are 4650marked as Inline_Always, or those marked as Inline with front-end 4651inlining (-gnatN option set) are accepted and legality-checked 4652by the compiler, but are ignored at run-time even if postcondition 4653checking is enabled. 4654 4655Note that pragma ``Postcondition`` differs from the language-defined 4656``Post`` aspect (and corresponding ``Post`` pragma) in allowing 4657multiple occurrences, allowing occurences in the body even if there 4658is a separate spec, and allowing a second string parameter, and the 4659use of the pragma identifier ``Check``. Historically, pragma 4660``Postcondition`` was implemented prior to the development of 4661Ada 2012, and has been retained in its original form for 4662compatibility purposes. 4663 4664Pragma Post_Class 4665================= 4666.. index:: Post 4667 4668.. index:: Checks, postconditions 4669 4670 4671Syntax: 4672 4673 4674.. code-block:: ada 4675 4676 pragma Post_Class (Boolean_Expression); 4677 4678 4679The ``Post_Class`` pragma is intended to be an exact replacement for 4680the language-defined 4681``Post'Class`` aspect, and shares its restrictions and semantics. 4682It must appear either immediately following the corresponding 4683subprogram declaration (only other pragmas may intervene), or 4684if there is no separate subprogram declaration, then it can 4685appear at the start of the declarations in a subprogram body 4686(preceded only by other pragmas). 4687 4688Note: This pragma is called ``Post_Class`` rather than 4689``Post'Class`` because the latter would not be strictly 4690conforming to the allowed syntax for pragmas. The motivation 4691for provinding pragmas equivalent to the aspects is to allow a program 4692to be written using the pragmas, and then compiled if necessary 4693using an Ada compiler that does not recognize the pragmas or 4694aspects, but is prepared to ignore the pragmas. The assertion 4695policy that controls this pragma is ``Post'Class``, not 4696``Post_Class``. 4697 4698Pragma Rename_Pragma 4699============================ 4700.. index:: Pragmas, synonyms 4701 4702Syntax: 4703 4704 4705:: 4706 4707 pragma Rename_Pragma ( 4708 [New_Name =>] IDENTIFIER, 4709 [Renamed =>] pragma_IDENTIFIER); 4710 4711This pragma provides a mechanism for supplying new names for existing 4712pragmas. The ``New_Name`` identifier can subsequently be used as a synonym for 4713the Renamed pragma. For example, suppose you have code that was originally 4714developed on a compiler that supports Inline_Only as an implementation defined 4715pragma. And suppose the semantics of pragma Inline_Only are identical to (or at 4716least very similar to) the GNAT implementation defined pragma 4717Inline_Always. You could globally replace Inline_Only with Inline_Always. 4718 4719However, to avoid that source modification, you could instead add a 4720configuration pragma: 4721 4722.. code-block:: ada 4723 4724 pragma Rename_Pragma ( 4725 New_Name => Inline_Only, 4726 Renamed => Inline_Always); 4727 4728 4729Then GNAT will treat "pragma Inline_Only ..." as if you had written 4730"pragma Inline_Always ...". 4731 4732Pragma Inline_Only will not necessarily mean the same thing as the other Ada 4733compiler; it's up to you to make sure the semantics are close enough. 4734 4735Pragma Pre 4736========== 4737.. index:: Pre 4738 4739.. index:: Checks, preconditions 4740 4741 4742Syntax: 4743 4744 4745.. code-block:: ada 4746 4747 pragma Pre (Boolean_Expression); 4748 4749 4750The ``Pre`` pragma is intended to be an exact replacement for 4751the language-defined 4752``Pre`` aspect, and shares its restrictions and semantics. 4753It must appear either immediately following the corresponding 4754subprogram declaration (only other pragmas may intervene), or 4755if there is no separate subprogram declaration, then it can 4756appear at the start of the declarations in a subprogram body 4757(preceded only by other pragmas). 4758 4759Pragma Precondition 4760=================== 4761.. index:: Preconditions 4762 4763.. index:: Checks, preconditions 4764 4765 4766Syntax: 4767 4768 4769:: 4770 4771 pragma Precondition ( 4772 [Check =>] Boolean_Expression 4773 [,[Message =>] String_Expression]); 4774 4775 4776The ``Precondition`` pragma is similar to ``Postcondition`` 4777except that the corresponding checks take place immediately upon 4778entry to the subprogram, and if a precondition fails, the exception 4779is raised in the context of the caller, and the attribute 'Result 4780cannot be used within the precondition expression. 4781 4782Otherwise, the placement and visibility rules are identical to those 4783described for postconditions. The following is an example of use 4784within a package spec: 4785 4786 4787.. code-block:: ada 4788 4789 package Math_Functions is 4790 ... 4791 function Sqrt (Arg : Float) return Float; 4792 pragma Precondition (Arg >= 0.0) 4793 ... 4794 end Math_Functions; 4795 4796 4797``Precondition`` pragmas may appear either immediately following the 4798(separate) declaration of a subprogram, or at the start of the 4799declarations of a subprogram body. Only other pragmas may intervene 4800(that is appear between the subprogram declaration and its 4801postconditions, or appear before the postcondition in the 4802declaration sequence in a subprogram body). 4803 4804Note: precondition pragmas associated with subprograms that are 4805marked as Inline_Always, or those marked as Inline with front-end 4806inlining (-gnatN option set) are accepted and legality-checked 4807by the compiler, but are ignored at run-time even if precondition 4808checking is enabled. 4809 4810Note that pragma ``Precondition`` differs from the language-defined 4811``Pre`` aspect (and corresponding ``Pre`` pragma) in allowing 4812multiple occurrences, allowing occurences in the body even if there 4813is a separate spec, and allowing a second string parameter, and the 4814use of the pragma identifier ``Check``. Historically, pragma 4815``Precondition`` was implemented prior to the development of 4816Ada 2012, and has been retained in its original form for 4817compatibility purposes. 4818 4819.. _Pragma-Predicate: 4820 4821Pragma Predicate 4822================ 4823 4824Syntax: 4825 4826 4827:: 4828 4829 pragma Predicate 4830 ([Entity =>] type_LOCAL_NAME, 4831 [Check =>] EXPRESSION); 4832 4833 4834This pragma (available in all versions of Ada in GNAT) encompasses both 4835the ``Static_Predicate`` and ``Dynamic_Predicate`` aspects in 4836Ada 2012. A predicate is regarded as static if it has an allowed form 4837for ``Static_Predicate`` and is otherwise treated as a 4838``Dynamic_Predicate``. Otherwise, predicates specified by this 4839pragma behave exactly as described in the Ada 2012 reference manual. 4840For example, if we have 4841 4842 4843.. code-block:: ada 4844 4845 type R is range 1 .. 10; 4846 subtype S is R; 4847 pragma Predicate (Entity => S, Check => S not in 4 .. 6); 4848 subtype Q is R 4849 pragma Predicate (Entity => Q, Check => F(Q) or G(Q)); 4850 4851 4852the effect is identical to the following Ada 2012 code: 4853 4854 4855.. code-block:: ada 4856 4857 type R is range 1 .. 10; 4858 subtype S is R with 4859 Static_Predicate => S not in 4 .. 6; 4860 subtype Q is R with 4861 Dynamic_Predicate => F(Q) or G(Q); 4862 4863 4864Note that there are no pragmas ``Dynamic_Predicate`` 4865or ``Static_Predicate``. That is 4866because these pragmas would affect legality and semantics of 4867the program and thus do not have a neutral effect if ignored. 4868The motivation behind providing pragmas equivalent to 4869corresponding aspects is to allow a program to be written 4870using the pragmas, and then compiled with a compiler that 4871will ignore the pragmas. That doesn't work in the case of 4872static and dynamic predicates, since if the corresponding 4873pragmas are ignored, then the behavior of the program is 4874fundamentally changed (for example a membership test 4875``A in B`` would not take into account a predicate 4876defined for subtype B). When following this approach, the 4877use of predicates should be avoided. 4878 4879Pragma Predicate_Failure 4880======================== 4881 4882Syntax: 4883 4884 4885:: 4886 4887 pragma Predicate_Failure 4888 ([Entity =>] type_LOCAL_NAME, 4889 [Message =>] String_Expression); 4890 4891 4892The ``Predicate_Failure`` pragma is intended to be an exact replacement for 4893the language-defined 4894``Predicate_Failure`` aspect, and shares its restrictions and semantics. 4895 4896Pragma Preelaborable_Initialization 4897=================================== 4898 4899Syntax: 4900 4901 4902.. code-block:: ada 4903 4904 pragma Preelaborable_Initialization (DIRECT_NAME); 4905 4906 4907This pragma is standard in Ada 2005, but is available in all earlier 4908versions of Ada as an implementation-defined pragma. 4909See Ada 2012 Reference Manual for details. 4910 4911Pragma Prefix_Exception_Messages 4912================================ 4913.. index:: Prefix_Exception_Messages 4914 4915.. index:: exception 4916 4917.. index:: Exception_Message 4918 4919 4920Syntax: 4921 4922 4923.. code-block:: ada 4924 4925 pragma Prefix_Exception_Messages; 4926 4927 4928This is an implementation-defined configuration pragma that affects the 4929behavior of raise statements with a message given as a static string 4930constant (typically a string literal). In such cases, the string will 4931be automatically prefixed by the name of the enclosing entity (giving 4932the package and subprogram containing the raise statement). This helps 4933to identify where messages are coming from, and this mode is automatic 4934for the run-time library. 4935 4936The pragma has no effect if the message is computed with an expression other 4937than a static string constant, since the assumption in this case is that 4938the program computes exactly the string it wants. If you still want the 4939prefixing in this case, you can always call 4940``GNAT.Source_Info.Enclosing_Entity`` and prepend the string manually. 4941 4942Pragma Pre_Class 4943================ 4944.. index:: Pre_Class 4945 4946.. index:: Checks, preconditions 4947 4948 4949Syntax: 4950 4951 4952.. code-block:: ada 4953 4954 pragma Pre_Class (Boolean_Expression); 4955 4956 4957The ``Pre_Class`` pragma is intended to be an exact replacement for 4958the language-defined 4959``Pre'Class`` aspect, and shares its restrictions and semantics. 4960It must appear either immediately following the corresponding 4961subprogram declaration (only other pragmas may intervene), or 4962if there is no separate subprogram declaration, then it can 4963appear at the start of the declarations in a subprogram body 4964(preceded only by other pragmas). 4965 4966Note: This pragma is called ``Pre_Class`` rather than 4967``Pre'Class`` because the latter would not be strictly 4968conforming to the allowed syntax for pragmas. The motivation 4969for providing pragmas equivalent to the aspects is to allow a program 4970to be written using the pragmas, and then compiled if necessary 4971using an Ada compiler that does not recognize the pragmas or 4972aspects, but is prepared to ignore the pragmas. The assertion 4973policy that controls this pragma is ``Pre'Class``, not 4974``Pre_Class``. 4975 4976Pragma Priority_Specific_Dispatching 4977==================================== 4978 4979Syntax: 4980 4981 4982:: 4983 4984 pragma Priority_Specific_Dispatching ( 4985 POLICY_IDENTIFIER, 4986 first_priority_EXPRESSION, 4987 last_priority_EXPRESSION) 4988 4989 POLICY_IDENTIFIER ::= 4990 EDF_Across_Priorities | 4991 FIFO_Within_Priorities | 4992 Non_Preemptive_Within_Priorities | 4993 Round_Robin_Within_Priorities 4994 4995 4996This pragma is standard in Ada 2005, but is available in all earlier 4997versions of Ada as an implementation-defined pragma. 4998See Ada 2012 Reference Manual for details. 4999 5000Pragma Profile 5001============== 5002 5003Syntax: 5004 5005 5006.. code-block:: ada 5007 5008 pragma Profile (Ravenscar | Restricted | Rational | 5009 GNAT_Extended_Ravenscar | GNAT_Ravenscar_EDF ); 5010 5011 5012This pragma is standard in Ada 2005, but is available in all earlier 5013versions of Ada as an implementation-defined pragma. This is a 5014configuration pragma that establishes a set of configuration pragmas 5015that depend on the argument. ``Ravenscar`` is standard in Ada 2005. 5016The other possibilities (``Restricted``, ``Rational``, 5017``GNAT_Extended_Ravenscar``, ``GNAT_Ravenscar_EDF``) 5018are implementation-defined. The set of configuration pragmas 5019is defined in the following sections. 5020 5021 5022* Pragma Profile (Ravenscar) 5023 5024 The ``Ravenscar`` profile is standard in Ada 2005, 5025 but is available in all earlier 5026 versions of Ada as an implementation-defined pragma. This profile 5027 establishes the following set of configuration pragmas: 5028 5029 * ``Task_Dispatching_Policy (FIFO_Within_Priorities)`` 5030 5031 [RM D.2.2] Tasks are dispatched following a preemptive 5032 priority-ordered scheduling policy. 5033 5034 5035 * ``Locking_Policy (Ceiling_Locking)`` 5036 5037 [RM D.3] While tasks and interrupts execute a protected action, they inherit 5038 the ceiling priority of the corresponding protected object. 5039 5040 5041 * ``Detect_Blocking`` 5042 5043 This pragma forces the detection of potentially blocking operations within a 5044 protected operation, and to raise Program_Error if that happens. 5045 5046 plus the following set of restrictions: 5047 5048 * ``Max_Entry_Queue_Length => 1`` 5049 5050 No task can be queued on a protected entry. 5051 5052 * ``Max_Protected_Entries => 1`` 5053 5054 * ``Max_Task_Entries => 0`` 5055 5056 No rendezvous statements are allowed. 5057 5058 * ``No_Abort_Statements`` 5059 5060 * ``No_Dynamic_Attachment`` 5061 5062 * ``No_Dynamic_Priorities`` 5063 5064 * ``No_Implicit_Heap_Allocations`` 5065 5066 * ``No_Local_Protected_Objects`` 5067 5068 * ``No_Local_Timing_Events`` 5069 5070 * ``No_Protected_Type_Allocators`` 5071 5072 * ``No_Relative_Delay`` 5073 5074 * ``No_Requeue_Statements`` 5075 5076 * ``No_Select_Statements`` 5077 5078 * ``No_Specific_Termination_Handlers`` 5079 5080 * ``No_Task_Allocators`` 5081 5082 * ``No_Task_Hierarchy`` 5083 5084 * ``No_Task_Termination`` 5085 5086 * ``Simple_Barriers`` 5087 5088 The Ravenscar profile also includes the following restrictions that specify 5089 that there are no semantic dependences on the corresponding predefined 5090 packages: 5091 5092 * ``No_Dependence => Ada.Asynchronous_Task_Control`` 5093 5094 * ``No_Dependence => Ada.Calendar`` 5095 5096 * ``No_Dependence => Ada.Execution_Time.Group_Budget`` 5097 5098 * ``No_Dependence => Ada.Execution_Time.Timers`` 5099 5100 * ``No_Dependence => Ada.Task_Attributes`` 5101 5102 * ``No_Dependence => System.Multiprocessors.Dispatching_Domains`` 5103 5104 This set of configuration pragmas and restrictions correspond to the 5105 definition of the 'Ravenscar Profile' for limited tasking, devised and 5106 published by the :title:`International Real-Time Ada Workshop, 1997`. 5107 A description is also available at 5108 `http://www-users.cs.york.ac.uk/~burns/ravenscar.ps <http://www-users.cs.york.ac.uk/~burns/ravenscar.ps>`_. 5109 5110 The original definition of the profile was revised at subsequent IRTAW 5111 meetings. It has been included in the ISO 5112 :title:`Guide for the Use of the Ada Programming Language in High Integrity Systems`, 5113 and was made part of the Ada 2005 standard. 5114 The formal definition given by 5115 the Ada Rapporteur Group (ARG) can be found in two Ada Issues (AI-249 and 5116 AI-305) available at 5117 `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 5118 `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>`_. 5119 5120 The above set is a superset of the restrictions provided by pragma 5121 ``Profile (Restricted)``, it includes six additional restrictions 5122 (``Simple_Barriers``, ``No_Select_Statements``, 5123 ``No_Calendar``, ``No_Implicit_Heap_Allocations``, 5124 ``No_Relative_Delay`` and ``No_Task_Termination``). This means 5125 that pragma ``Profile (Ravenscar)``, like the pragma 5126 ``Profile (Restricted)``, 5127 automatically causes the use of a simplified, 5128 more efficient version of the tasking run-time library. 5129 5130* Pragma Profile (GNAT_Extended_Ravenscar) 5131 5132 This profile corresponds to a GNAT specific extension of the 5133 Ravenscar profile. The profile may change in the future although 5134 only in a compatible way: some restrictions may be removed or 5135 relaxed. It is defined as a variation of the Ravenscar profile. 5136 5137 The ``No_Implicit_Heap_Allocations`` restriction has been replaced 5138 by ``No_Implicit_Task_Allocations`` and 5139 ``No_Implicit_Protected_Object_Allocations``. 5140 5141 The ``Simple_Barriers`` restriction has been replaced by 5142 ``Pure_Barriers``. 5143 5144 The ``Max_Protected_Entries``, ``Max_Entry_Queue_Length``, and 5145 ``No_Relative_Delay`` restrictions have been removed. 5146 5147* Pragma Profile (GNAT_Ravenscar_EDF) 5148 5149 This profile corresponds to the Ravenscar profile but using 5150 EDF_Across_Priority as the Task_Scheduling_Policy. 5151 5152* Pragma Profile (Restricted) 5153 5154 This profile corresponds to the GNAT restricted run time. It 5155 establishes the following set of restrictions: 5156 5157 * ``No_Abort_Statements`` 5158 * ``No_Entry_Queue`` 5159 * ``No_Task_Hierarchy`` 5160 * ``No_Task_Allocators`` 5161 * ``No_Dynamic_Priorities`` 5162 * ``No_Terminate_Alternatives`` 5163 * ``No_Dynamic_Attachment`` 5164 * ``No_Protected_Type_Allocators`` 5165 * ``No_Local_Protected_Objects`` 5166 * ``No_Requeue_Statements`` 5167 * ``No_Task_Attributes_Package`` 5168 * ``Max_Asynchronous_Select_Nesting = 0`` 5169 * ``Max_Task_Entries = 0`` 5170 * ``Max_Protected_Entries = 1`` 5171 * ``Max_Select_Alternatives = 0`` 5172 5173 This set of restrictions causes the automatic selection of a simplified 5174 version of the run time that provides improved performance for the 5175 limited set of tasking functionality permitted by this set of restrictions. 5176 5177* Pragma Profile (Rational) 5178 5179 The Rational profile is intended to facilitate porting legacy code that 5180 compiles with the Rational APEX compiler, even when the code includes non- 5181 conforming Ada constructs. The profile enables the following three pragmas: 5182 5183 * ``pragma Implicit_Packing`` 5184 * ``pragma Overriding_Renamings`` 5185 * ``pragma Use_VADS_Size`` 5186 5187 5188Pragma Profile_Warnings 5189======================= 5190 5191Syntax: 5192 5193 5194.. code-block:: ada 5195 5196 pragma Profile_Warnings (Ravenscar | Restricted | Rational); 5197 5198 5199This is an implementation-defined pragma that is similar in 5200effect to ``pragma Profile`` except that instead of 5201generating ``Restrictions`` pragmas, it generates 5202``Restriction_Warnings`` pragmas. The result is that 5203violations of the profile generate warning messages instead 5204of error messages. 5205 5206Pragma Propagate_Exceptions 5207=========================== 5208.. index:: Interfacing to C++ 5209 5210 5211Syntax: 5212 5213 5214.. code-block:: ada 5215 5216 pragma Propagate_Exceptions; 5217 5218 5219This pragma is now obsolete and, other than generating a warning if warnings 5220on obsolescent features are enabled, is ignored. 5221It is retained for compatibility 5222purposes. It used to be used in connection with optimization of 5223a now-obsolete mechanism for implementation of exceptions. 5224 5225Pragma Provide_Shift_Operators 5226============================== 5227.. index:: Shift operators 5228 5229 5230Syntax: 5231 5232 5233.. code-block:: ada 5234 5235 pragma Provide_Shift_Operators (integer_first_subtype_LOCAL_NAME); 5236 5237 5238This pragma can be applied to a first subtype local name that specifies 5239either an unsigned or signed type. It has the effect of providing the 5240five shift operators (Shift_Left, Shift_Right, Shift_Right_Arithmetic, 5241Rotate_Left and Rotate_Right) for the given type. It is similar to 5242including the function declarations for these five operators, together 5243with the pragma Import (Intrinsic, ...) statements. 5244 5245Pragma Psect_Object 5246=================== 5247 5248Syntax: 5249 5250 5251:: 5252 5253 pragma Psect_Object ( 5254 [Internal =>] LOCAL_NAME, 5255 [, [External =>] EXTERNAL_SYMBOL] 5256 [, [Size =>] EXTERNAL_SYMBOL]); 5257 5258 EXTERNAL_SYMBOL ::= 5259 IDENTIFIER 5260 | static_string_EXPRESSION 5261 5262 5263This pragma is identical in effect to pragma ``Common_Object``. 5264 5265.. _Pragma-Pure_Function: 5266 5267Pragma Pure_Function 5268==================== 5269 5270Syntax: 5271 5272 5273:: 5274 5275 pragma Pure_Function ([Entity =>] function_LOCAL_NAME); 5276 5277 5278This pragma appears in the same declarative part as a function 5279declaration (or a set of function declarations if more than one 5280overloaded declaration exists, in which case the pragma applies 5281to all entities). It specifies that the function ``Entity`` is 5282to be considered pure for the purposes of code generation. This means 5283that the compiler can assume that there are no side effects, and 5284in particular that two calls with identical arguments produce the 5285same result. It also means that the function can be used in an 5286address clause. 5287 5288Note that, quite deliberately, there are no static checks to try 5289to ensure that this promise is met, so ``Pure_Function`` can be used 5290with functions that are conceptually pure, even if they do modify 5291global variables. For example, a square root function that is 5292instrumented to count the number of times it is called is still 5293conceptually pure, and can still be optimized, even though it 5294modifies a global variable (the count). Memo functions are another 5295example (where a table of previous calls is kept and consulted to 5296avoid re-computation). 5297 5298Note also that the normal rules excluding optimization of subprograms 5299in pure units (when parameter types are descended from System.Address, 5300or when the full view of a parameter type is limited), do not apply 5301for the Pure_Function case. If you explicitly specify Pure_Function, 5302the compiler may optimize away calls with identical arguments, and 5303if that results in unexpected behavior, the proper action is not to 5304use the pragma for subprograms that are not (conceptually) pure. 5305 5306Note: Most functions in a ``Pure`` package are automatically pure, and 5307there is no need to use pragma ``Pure_Function`` for such functions. One 5308exception is any function that has at least one formal of type 5309``System.Address`` or a type derived from it. Such functions are not 5310considered pure by default, since the compiler assumes that the 5311``Address`` parameter may be functioning as a pointer and that the 5312referenced data may change even if the address value does not. 5313Similarly, imported functions are not considered to be pure by default, 5314since there is no way of checking that they are in fact pure. The use 5315of pragma ``Pure_Function`` for such a function will override these default 5316assumption, and cause the compiler to treat a designated subprogram as pure 5317in these cases. 5318 5319Note: If pragma ``Pure_Function`` is applied to a renamed function, it 5320applies to the underlying renamed function. This can be used to 5321disambiguate cases of overloading where some but not all functions 5322in a set of overloaded functions are to be designated as pure. 5323 5324If pragma ``Pure_Function`` is applied to a library-level function, the 5325function is also considered pure from an optimization point of view, but the 5326unit is not a Pure unit in the categorization sense. So for example, a function 5327thus marked is free to ``with`` non-pure units. 5328 5329Pragma Rational 5330=============== 5331 5332Syntax: 5333 5334 5335.. code-block:: ada 5336 5337 pragma Rational; 5338 5339 5340This pragma is considered obsolescent, but is retained for 5341compatibility purposes. It is equivalent to: 5342 5343 5344.. code-block:: ada 5345 5346 pragma Profile (Rational); 5347 5348 5349Pragma Ravenscar 5350================ 5351 5352Syntax: 5353 5354 5355.. code-block:: ada 5356 5357 pragma Ravenscar; 5358 5359 5360This pragma is considered obsolescent, but is retained for 5361compatibility purposes. It is equivalent to: 5362 5363 5364.. code-block:: ada 5365 5366 pragma Profile (Ravenscar); 5367 5368 5369which is the preferred method of setting the ``Ravenscar`` profile. 5370 5371.. _Pragma-Refined_Depends: 5372 5373Pragma Refined_Depends 5374====================== 5375 5376Syntax: 5377 5378.. code-block:: ada 5379 5380 pragma Refined_Depends (DEPENDENCY_RELATION); 5381 5382 DEPENDENCY_RELATION ::= 5383 null 5384 | (DEPENDENCY_CLAUSE {, DEPENDENCY_CLAUSE}) 5385 5386 DEPENDENCY_CLAUSE ::= 5387 OUTPUT_LIST =>[+] INPUT_LIST 5388 | NULL_DEPENDENCY_CLAUSE 5389 5390 NULL_DEPENDENCY_CLAUSE ::= null => INPUT_LIST 5391 5392 OUTPUT_LIST ::= OUTPUT | (OUTPUT {, OUTPUT}) 5393 5394 INPUT_LIST ::= null | INPUT | (INPUT {, INPUT}) 5395 5396 OUTPUT ::= NAME | FUNCTION_RESULT 5397 INPUT ::= NAME 5398 5399 where FUNCTION_RESULT is a function Result attribute_reference 5400 5401For the semantics of this pragma, see the entry for aspect ``Refined_Depends`` in 5402the SPARK 2014 Reference Manual, section 6.1.5. 5403 5404.. _Pragma-Refined_Global: 5405 5406Pragma Refined_Global 5407===================== 5408 5409Syntax: 5410 5411.. code-block:: ada 5412 5413 pragma Refined_Global (GLOBAL_SPECIFICATION); 5414 5415 GLOBAL_SPECIFICATION ::= 5416 null 5417 | (GLOBAL_LIST) 5418 | (MODED_GLOBAL_LIST {, MODED_GLOBAL_LIST}) 5419 5420 MODED_GLOBAL_LIST ::= MODE_SELECTOR => GLOBAL_LIST 5421 5422 MODE_SELECTOR ::= In_Out | Input | Output | Proof_In 5423 GLOBAL_LIST ::= GLOBAL_ITEM | (GLOBAL_ITEM {, GLOBAL_ITEM}) 5424 GLOBAL_ITEM ::= NAME 5425 5426For the semantics of this pragma, see the entry for aspect ``Refined_Global`` in 5427the SPARK 2014 Reference Manual, section 6.1.4. 5428 5429.. _Pragma-Refined_Post: 5430 5431Pragma Refined_Post 5432=================== 5433 5434Syntax: 5435 5436.. code-block:: ada 5437 5438 pragma Refined_Post (boolean_EXPRESSION); 5439 5440For the semantics of this pragma, see the entry for aspect ``Refined_Post`` in 5441the SPARK 2014 Reference Manual, section 7.2.7. 5442 5443.. _Pragma-Refined_State: 5444 5445Pragma Refined_State 5446==================== 5447 5448Syntax: 5449 5450.. code-block:: ada 5451 5452 pragma Refined_State (REFINEMENT_LIST); 5453 5454 REFINEMENT_LIST ::= 5455 (REFINEMENT_CLAUSE {, REFINEMENT_CLAUSE}) 5456 5457 REFINEMENT_CLAUSE ::= state_NAME => CONSTITUENT_LIST 5458 5459 CONSTITUENT_LIST ::= 5460 null 5461 | CONSTITUENT 5462 | (CONSTITUENT {, CONSTITUENT}) 5463 5464 CONSTITUENT ::= object_NAME | state_NAME 5465 5466For the semantics of this pragma, see the entry for aspect ``Refined_State`` in 5467the SPARK 2014 Reference Manual, section 7.2.2. 5468 5469Pragma Relative_Deadline 5470======================== 5471 5472Syntax: 5473 5474 5475.. code-block:: ada 5476 5477 pragma Relative_Deadline (time_span_EXPRESSION); 5478 5479 5480This pragma is standard in Ada 2005, but is available in all earlier 5481versions of Ada as an implementation-defined pragma. 5482See Ada 2012 Reference Manual for details. 5483 5484.. _Pragma-Remote_Access_Type: 5485 5486Pragma Remote_Access_Type 5487========================= 5488 5489Syntax: 5490 5491 5492:: 5493 5494 pragma Remote_Access_Type ([Entity =>] formal_access_type_LOCAL_NAME); 5495 5496 5497This pragma appears in the formal part of a generic declaration. 5498It specifies an exception to the RM rule from E.2.2(17/2), which forbids 5499the use of a remote access to class-wide type as actual for a formal 5500access type. 5501 5502When this pragma applies to a formal access type ``Entity``, that 5503type is treated as a remote access to class-wide type in the generic. 5504It must be a formal general access type, and its designated type must 5505be the class-wide type of a formal tagged limited private type from the 5506same generic declaration. 5507 5508In the generic unit, the formal type is subject to all restrictions 5509pertaining to remote access to class-wide types. At instantiation, the 5510actual type must be a remote access to class-wide type. 5511 5512Pragma Restricted_Run_Time 5513========================== 5514 5515Syntax: 5516 5517 5518.. code-block:: ada 5519 5520 pragma Restricted_Run_Time; 5521 5522 5523This pragma is considered obsolescent, but is retained for 5524compatibility purposes. It is equivalent to: 5525 5526 5527.. code-block:: ada 5528 5529 pragma Profile (Restricted); 5530 5531 5532which is the preferred method of setting the restricted run time 5533profile. 5534 5535Pragma Restriction_Warnings 5536=========================== 5537 5538Syntax: 5539 5540 5541:: 5542 5543 pragma Restriction_Warnings 5544 (restriction_IDENTIFIER {, restriction_IDENTIFIER}); 5545 5546 5547This pragma allows a series of restriction identifiers to be 5548specified (the list of allowed identifiers is the same as for 5549pragma ``Restrictions``). For each of these identifiers 5550the compiler checks for violations of the restriction, but 5551generates a warning message rather than an error message 5552if the restriction is violated. 5553 5554One use of this is in situations where you want to know 5555about violations of a restriction, but you want to ignore some of 5556these violations. Consider this example, where you want to set 5557Ada_95 mode and enable style checks, but you want to know about 5558any other use of implementation pragmas: 5559 5560 5561.. code-block:: ada 5562 5563 pragma Restriction_Warnings (No_Implementation_Pragmas); 5564 pragma Warnings (Off, "violation of No_Implementation_Pragmas"); 5565 pragma Ada_95; 5566 pragma Style_Checks ("2bfhkM160"); 5567 pragma Warnings (On, "violation of No_Implementation_Pragmas"); 5568 5569 5570By including the above lines in a configuration pragmas file, 5571the Ada_95 and Style_Checks pragmas are accepted without 5572generating a warning, but any other use of implementation 5573defined pragmas will cause a warning to be generated. 5574 5575Pragma Reviewable 5576================= 5577 5578Syntax: 5579 5580 5581.. code-block:: ada 5582 5583 pragma Reviewable; 5584 5585 5586This pragma is an RM-defined standard pragma, but has no effect on the 5587program being compiled, or on the code generated for the program. 5588 5589To obtain the required output specified in RM H.3.1, the compiler must be 5590run with various special switches as follows: 5591 5592* *Where compiler-generated run-time checks remain* 5593 5594 The switch *-gnatGL* 5595 may be used to list the expanded code in pseudo-Ada form. 5596 Runtime checks show up in the listing either as explicit 5597 checks or operators marked with {} to indicate a check is present. 5598 5599 5600* *An identification of known exceptions at compile time* 5601 5602 If the program is compiled with *-gnatwa*, 5603 the compiler warning messages will indicate all cases where the compiler 5604 detects that an exception is certain to occur at run time. 5605 5606 5607* *Possible reads of uninitialized variables* 5608 5609 The compiler warns of many such cases, but its output is incomplete. 5610 5611.. only:: PRO or GPL 5612 5613 The CodePeer analysis tool 5614 may be used to obtain a comprehensive list of all 5615 possible points at which uninitialized data may be read. 5616 5617.. only:: FSF 5618 5619 A supplemental static analysis tool 5620 may be used to obtain a comprehensive list of all 5621 possible points at which uninitialized data may be read. 5622 5623 5624* *Where run-time support routines are implicitly invoked* 5625 5626 In the output from *-gnatGL*, 5627 run-time calls are explicitly listed as calls to the relevant 5628 run-time routine. 5629 5630 5631* *Object code listing* 5632 5633 This may be obtained either by using the *-S* switch, 5634 or the objdump utility. 5635 5636 5637* *Constructs known to be erroneous at compile time* 5638 5639 These are identified by warnings issued by the compiler (use *-gnatwa*). 5640 5641 5642* *Stack usage information* 5643 5644 Static stack usage data (maximum per-subprogram) can be obtained via the 5645 *-fstack-usage* switch to the compiler. 5646 Dynamic stack usage data (per task) can be obtained via the *-u* switch 5647 to gnatbind 5648 5649.. only:: PRO or GPL 5650 5651 The gnatstack utility 5652 can be used to provide additional information on stack usage. 5653 5654 5655* *Object code listing of entire partition* 5656 5657 This can be obtained by compiling the partition with *-S*, 5658 or by applying objdump 5659 to all the object files that are part of the partition. 5660 5661 5662* *A description of the run-time model* 5663 5664 The full sources of the run-time are available, and the documentation of 5665 these routines describes how these run-time routines interface to the 5666 underlying operating system facilities. 5667 5668 5669* *Control and data-flow information* 5670 5671.. only:: PRO or GPL 5672 5673 The CodePeer tool 5674 may be used to obtain complete control and data-flow information, as well as 5675 comprehensive messages identifying possible problems based on this 5676 information. 5677 5678.. only:: FSF 5679 5680 A supplemental static analysis tool 5681 may be used to obtain complete control and data-flow information, as well as 5682 comprehensive messages identifying possible problems based on this 5683 information. 5684 5685.. _Pragma-Secondary_Stack_Size: 5686 5687Pragma Secondary_Stack_Size 5688=========================== 5689 5690Syntax: 5691 5692.. code-block:: ada 5693 5694 pragma Secondary_Stack_Size (integer_EXPRESSION); 5695 5696This pragma appears within the task definition of a single task declaration 5697or a task type declaration (like pragma ``Storage_Size``) and applies to all 5698task objects of that type. The argument specifies the size of the secondary 5699stack to be used by these task objects, and must be of an integer type. The 5700secondary stack is used to handle functions that return a variable-sized 5701result, for example a function returning an unconstrained String. 5702 5703Note this pragma only applies to targets using fixed secondary stacks, like 5704VxWorks 653 and bare board targets, where a fixed block for the 5705secondary stack is allocated from the primary stack of the task. By default, 5706these targets assign a percentage of the primary stack for the secondary stack, 5707as defined by ``System.Parameter.Sec_Stack_Percentage``. With this pragma, 5708an ``integer_EXPRESSION`` of bytes is assigned from the primary stack instead. 5709 5710For most targets, the pragma does not apply as the secondary stack grows on 5711demand: allocated as a chain of blocks in the heap. The default size of these 5712blocks can be modified via the :switch:`-D` binder option as described in 5713:title:`GNAT User's Guide`. 5714 5715Note that no check is made to see if the secondary stack can fit inside the 5716primary stack. 5717 5718Note the pragma cannot appear when the restriction ``No_Secondary_Stack`` 5719is in effect. 5720 5721Pragma Share_Generic 5722==================== 5723 5724Syntax: 5725 5726 5727:: 5728 5729 pragma Share_Generic (GNAME {, GNAME}); 5730 5731 GNAME ::= generic_unit_NAME | generic_instance_NAME 5732 5733 5734This pragma is provided for compatibility with Dec Ada 83. It has 5735no effect in GNAT (which does not implement shared generics), other 5736than to check that the given names are all names of generic units or 5737generic instances. 5738 5739.. _Pragma-Shared: 5740 5741Pragma Shared 5742============= 5743 5744This pragma is provided for compatibility with Ada 83. The syntax and 5745semantics are identical to pragma Atomic. 5746 5747Pragma Short_Circuit_And_Or 5748=========================== 5749 5750Syntax: 5751 5752 5753.. code-block:: ada 5754 5755 pragma Short_Circuit_And_Or; 5756 5757 5758This configuration pragma causes any occurrence of the AND operator applied to 5759operands of type Standard.Boolean to be short-circuited (i.e. the AND operator 5760is treated as if it were AND THEN). Or is similarly treated as OR ELSE. This 5761may be useful in the context of certification protocols requiring the use of 5762short-circuited logical operators. If this configuration pragma occurs locally 5763within the file being compiled, it applies only to the file being compiled. 5764There is no requirement that all units in a partition use this option. 5765 5766Pragma Short_Descriptors 5767======================== 5768 5769Syntax: 5770 5771 5772.. code-block:: ada 5773 5774 pragma Short_Descriptors 5775 5776 5777This pragma is provided for compatibility with other Ada implementations. It 5778is recognized but ignored by all current versions of GNAT. 5779 5780.. _Pragma-Simple_Storage_Pool_Type: 5781 5782Pragma Simple_Storage_Pool_Type 5783=============================== 5784.. index:: Storage pool, simple 5785 5786.. index:: Simple storage pool 5787 5788Syntax: 5789 5790 5791.. code-block:: ada 5792 5793 pragma Simple_Storage_Pool_Type (type_LOCAL_NAME); 5794 5795 5796A type can be established as a 'simple storage pool type' by applying 5797the representation pragma ``Simple_Storage_Pool_Type`` to the type. 5798A type named in the pragma must be a library-level immutably limited record 5799type or limited tagged type declared immediately within a package declaration. 5800The type can also be a limited private type whose full type is allowed as 5801a simple storage pool type. 5802 5803For a simple storage pool type ``SSP``, nonabstract primitive subprograms 5804``Allocate``, ``Deallocate``, and ``Storage_Size`` can be declared that 5805are subtype conformant with the following subprogram declarations: 5806 5807 5808.. code-block:: ada 5809 5810 procedure Allocate 5811 (Pool : in out SSP; 5812 Storage_Address : out System.Address; 5813 Size_In_Storage_Elements : System.Storage_Elements.Storage_Count; 5814 Alignment : System.Storage_Elements.Storage_Count); 5815 5816 procedure Deallocate 5817 (Pool : in out SSP; 5818 Storage_Address : System.Address; 5819 Size_In_Storage_Elements : System.Storage_Elements.Storage_Count; 5820 Alignment : System.Storage_Elements.Storage_Count); 5821 5822 function Storage_Size (Pool : SSP) 5823 return System.Storage_Elements.Storage_Count; 5824 5825 5826Procedure ``Allocate`` must be declared, whereas ``Deallocate`` and 5827``Storage_Size`` are optional. If ``Deallocate`` is not declared, then 5828applying an unchecked deallocation has no effect other than to set its actual 5829parameter to null. If ``Storage_Size`` is not declared, then the 5830``Storage_Size`` attribute applied to an access type associated with 5831a pool object of type SSP returns zero. Additional operations can be declared 5832for a simple storage pool type (such as for supporting a mark/release 5833storage-management discipline). 5834 5835An object of a simple storage pool type can be associated with an access 5836type by specifying the attribute 5837:ref:`Simple_Storage_Pool <Attribute_Simple_Storage_Pool>`. For example: 5838 5839 5840.. code-block:: ada 5841 5842 My_Pool : My_Simple_Storage_Pool_Type; 5843 5844 type Acc is access My_Data_Type; 5845 5846 for Acc'Simple_Storage_Pool use My_Pool; 5847 5848 5849 5850See attribute :ref:`Simple_Storage_Pool <Attribute_Simple_Storage_Pool>` 5851for further details. 5852 5853.. _Pragma_Source_File_Name: 5854 5855Pragma Source_File_Name 5856======================= 5857 5858Syntax: 5859 5860 5861:: 5862 5863 pragma Source_File_Name ( 5864 [Unit_Name =>] unit_NAME, 5865 Spec_File_Name => STRING_LITERAL, 5866 [Index => INTEGER_LITERAL]); 5867 5868 pragma Source_File_Name ( 5869 [Unit_Name =>] unit_NAME, 5870 Body_File_Name => STRING_LITERAL, 5871 [Index => INTEGER_LITERAL]); 5872 5873 5874Use this to override the normal naming convention. It is a configuration 5875pragma, and so has the usual applicability of configuration pragmas 5876(i.e., it applies to either an entire partition, or to all units in a 5877compilation, or to a single unit, depending on how it is used. 5878``unit_name`` is mapped to ``file_name_literal``. The identifier for 5879the second argument is required, and indicates whether this is the file 5880name for the spec or for the body. 5881 5882The optional Index argument should be used when a file contains multiple 5883units, and when you do not want to use ``gnatchop`` to separate then 5884into multiple files (which is the recommended procedure to limit the 5885number of recompilations that are needed when some sources change). 5886For instance, if the source file :file:`source.ada` contains 5887 5888 5889.. code-block:: ada 5890 5891 package B is 5892 ... 5893 end B; 5894 5895 with B; 5896 procedure A is 5897 begin 5898 .. 5899 end A; 5900 5901 5902you could use the following configuration pragmas: 5903 5904 5905.. code-block:: ada 5906 5907 pragma Source_File_Name 5908 (B, Spec_File_Name => "source.ada", Index => 1); 5909 pragma Source_File_Name 5910 (A, Body_File_Name => "source.ada", Index => 2); 5911 5912 5913Note that the ``gnatname`` utility can also be used to generate those 5914configuration pragmas. 5915 5916Another form of the ``Source_File_Name`` pragma allows 5917the specification of patterns defining alternative file naming schemes 5918to apply to all files. 5919 5920 5921:: 5922 5923 pragma Source_File_Name 5924 ( [Spec_File_Name =>] STRING_LITERAL 5925 [,[Casing =>] CASING_SPEC] 5926 [,[Dot_Replacement =>] STRING_LITERAL]); 5927 5928 pragma Source_File_Name 5929 ( [Body_File_Name =>] STRING_LITERAL 5930 [,[Casing =>] CASING_SPEC] 5931 [,[Dot_Replacement =>] STRING_LITERAL]); 5932 5933 pragma Source_File_Name 5934 ( [Subunit_File_Name =>] STRING_LITERAL 5935 [,[Casing =>] CASING_SPEC] 5936 [,[Dot_Replacement =>] STRING_LITERAL]); 5937 5938 CASING_SPEC ::= Lowercase | Uppercase | Mixedcase 5939 5940 5941The first argument is a pattern that contains a single asterisk indicating 5942the point at which the unit name is to be inserted in the pattern string 5943to form the file name. The second argument is optional. If present it 5944specifies the casing of the unit name in the resulting file name string. 5945The default is lower case. Finally the third argument allows for systematic 5946replacement of any dots in the unit name by the specified string literal. 5947 5948Note that Source_File_Name pragmas should not be used if you are using 5949project files. The reason for this rule is that the project manager is not 5950aware of these pragmas, and so other tools that use the projet file would not 5951be aware of the intended naming conventions. If you are using project files, 5952file naming is controlled by Source_File_Name_Project pragmas, which are 5953usually supplied automatically by the project manager. A pragma 5954Source_File_Name cannot appear after a :ref:`Pragma_Source_File_Name_Project`. 5955 5956For more details on the use of the ``Source_File_Name`` pragma, see the 5957sections on ``Using Other File Names`` and `Alternative File Naming Schemes' 5958in the :title:`GNAT User's Guide`. 5959 5960.. _Pragma_Source_File_Name_Project: 5961 5962Pragma Source_File_Name_Project 5963=============================== 5964 5965This pragma has the same syntax and semantics as pragma Source_File_Name. 5966It is only allowed as a stand-alone configuration pragma. 5967It cannot appear after a :ref:`Pragma_Source_File_Name`, and 5968most importantly, once pragma Source_File_Name_Project appears, 5969no further Source_File_Name pragmas are allowed. 5970 5971The intention is that Source_File_Name_Project pragmas are always 5972generated by the Project Manager in a manner consistent with the naming 5973specified in a project file, and when naming is controlled in this manner, 5974it is not permissible to attempt to modify this naming scheme using 5975Source_File_Name or Source_File_Name_Project pragmas (which would not be 5976known to the project manager). 5977 5978Pragma Source_Reference 5979======================= 5980 5981Syntax: 5982 5983 5984.. code-block:: ada 5985 5986 pragma Source_Reference (INTEGER_LITERAL, STRING_LITERAL); 5987 5988 5989This pragma must appear as the first line of a source file. 5990``integer_literal`` is the logical line number of the line following 5991the pragma line (for use in error messages and debugging 5992information). ``string_literal`` is a static string constant that 5993specifies the file name to be used in error messages and debugging 5994information. This is most notably used for the output of ``gnatchop`` 5995with the *-r* switch, to make sure that the original unchopped 5996source file is the one referred to. 5997 5998The second argument must be a string literal, it cannot be a static 5999string expression other than a string literal. This is because its value 6000is needed for error messages issued by all phases of the compiler. 6001 6002.. _Pragma-SPARK_Mode: 6003 6004Pragma SPARK_Mode 6005================= 6006 6007Syntax: 6008 6009 6010:: 6011 6012 pragma SPARK_Mode [(On | Off)] ; 6013 6014 6015In general a program can have some parts that are in SPARK 2014 (and 6016follow all the rules in the SPARK Reference Manual), and some parts 6017that are full Ada 2012. 6018 6019The SPARK_Mode pragma is used to identify which parts are in SPARK 60202014 (by default programs are in full Ada). The SPARK_Mode pragma can 6021be used in the following places: 6022 6023 6024* 6025 As a configuration pragma, in which case it sets the default mode for 6026 all units compiled with this pragma. 6027 6028* 6029 Immediately following a library-level subprogram spec 6030 6031* 6032 Immediately within a library-level package body 6033 6034* 6035 Immediately following the ``private`` keyword of a library-level 6036 package spec 6037 6038* 6039 Immediately following the ``begin`` keyword of a library-level 6040 package body 6041 6042* 6043 Immediately within a library-level subprogram body 6044 6045 6046Normally a subprogram or package spec/body inherits the current mode 6047that is active at the point it is declared. But this can be overridden 6048by pragma within the spec or body as above. 6049 6050The basic consistency rule is that you can't turn SPARK_Mode back 6051``On``, once you have explicitly (with a pragma) turned if 6052``Off``. So the following rules apply: 6053 6054If a subprogram spec has SPARK_Mode ``Off``, then the body must 6055also have SPARK_Mode ``Off``. 6056 6057For a package, we have four parts: 6058 6059* 6060 the package public declarations 6061* 6062 the package private part 6063* 6064 the body of the package 6065* 6066 the elaboration code after ``begin`` 6067 6068For a package, the rule is that if you explicitly turn SPARK_Mode 6069``Off`` for any part, then all the following parts must have 6070SPARK_Mode ``Off``. Note that this may require repeating a pragma 6071SPARK_Mode (``Off``) in the body. For example, if we have a 6072configuration pragma SPARK_Mode (``On``) that turns the mode on by 6073default everywhere, and one particular package spec has pragma 6074SPARK_Mode (``Off``), then that pragma will need to be repeated in 6075the package body. 6076 6077Pragma Static_Elaboration_Desired 6078================================= 6079 6080Syntax: 6081 6082 6083.. code-block:: ada 6084 6085 pragma Static_Elaboration_Desired; 6086 6087 6088This pragma is used to indicate that the compiler should attempt to initialize 6089statically the objects declared in the library unit to which the pragma applies, 6090when these objects are initialized (explicitly or implicitly) by an aggregate. 6091In the absence of this pragma, aggregates in object declarations are expanded 6092into assignments and loops, even when the aggregate components are static 6093constants. When the aggregate is present the compiler builds a static expression 6094that requires no run-time code, so that the initialized object can be placed in 6095read-only data space. If the components are not static, or the aggregate has 6096more that 100 components, the compiler emits a warning that the pragma cannot 6097be obeyed. (See also the restriction No_Implicit_Loops, which supports static 6098construction of larger aggregates with static components that include an others 6099choice.) 6100 6101Pragma Stream_Convert 6102===================== 6103 6104Syntax: 6105 6106 6107:: 6108 6109 pragma Stream_Convert ( 6110 [Entity =>] type_LOCAL_NAME, 6111 [Read =>] function_NAME, 6112 [Write =>] function_NAME); 6113 6114 6115This pragma provides an efficient way of providing user-defined stream 6116attributes. Not only is it simpler to use than specifying the attributes 6117directly, but more importantly, it allows the specification to be made in such 6118a way that the predefined unit Ada.Streams is not loaded unless it is actually 6119needed (i.e. unless the stream attributes are actually used); the use of 6120the Stream_Convert pragma adds no overhead at all, unless the stream 6121attributes are actually used on the designated type. 6122 6123The first argument specifies the type for which stream functions are 6124provided. The second parameter provides a function used to read values 6125of this type. It must name a function whose argument type may be any 6126subtype, and whose returned type must be the type given as the first 6127argument to the pragma. 6128 6129The meaning of the ``Read`` parameter is that if a stream attribute directly 6130or indirectly specifies reading of the type given as the first parameter, 6131then a value of the type given as the argument to the Read function is 6132read from the stream, and then the Read function is used to convert this 6133to the required target type. 6134 6135Similarly the ``Write`` parameter specifies how to treat write attributes 6136that directly or indirectly apply to the type given as the first parameter. 6137It must have an input parameter of the type specified by the first parameter, 6138and the return type must be the same as the input type of the Read function. 6139The effect is to first call the Write function to convert to the given stream 6140type, and then write the result type to the stream. 6141 6142The Read and Write functions must not be overloaded subprograms. If necessary 6143renamings can be supplied to meet this requirement. 6144The usage of this attribute is best illustrated by a simple example, taken 6145from the GNAT implementation of package Ada.Strings.Unbounded: 6146 6147 6148.. code-block:: ada 6149 6150 function To_Unbounded (S : String) return Unbounded_String 6151 renames To_Unbounded_String; 6152 6153 pragma Stream_Convert 6154 (Unbounded_String, To_Unbounded, To_String); 6155 6156 6157The specifications of the referenced functions, as given in the Ada 6158Reference Manual are: 6159 6160 6161.. code-block:: ada 6162 6163 function To_Unbounded_String (Source : String) 6164 return Unbounded_String; 6165 6166 function To_String (Source : Unbounded_String) 6167 return String; 6168 6169 6170The effect is that if the value of an unbounded string is written to a stream, 6171then the representation of the item in the stream is in the same format that 6172would be used for ``Standard.String'Output``, and this same representation 6173is expected when a value of this type is read from the stream. Note that the 6174value written always includes the bounds, even for Unbounded_String'Write, 6175since Unbounded_String is not an array type. 6176 6177Note that the ``Stream_Convert`` pragma is not effective in the case of 6178a derived type of a non-limited tagged type. If such a type is specified then 6179the pragma is silently ignored, and the default implementation of the stream 6180attributes is used instead. 6181 6182Pragma Style_Checks 6183=================== 6184 6185Syntax: 6186 6187 6188:: 6189 6190 pragma Style_Checks (string_LITERAL | ALL_CHECKS | 6191 On | Off [, LOCAL_NAME]); 6192 6193 6194This pragma is used in conjunction with compiler switches to control the 6195built in style checking provided by GNAT. The compiler switches, if set, 6196provide an initial setting for the switches, and this pragma may be used 6197to modify these settings, or the settings may be provided entirely by 6198the use of the pragma. This pragma can be used anywhere that a pragma 6199is legal, including use as a configuration pragma (including use in 6200the :file:`gnat.adc` file). 6201 6202The form with a string literal specifies which style options are to be 6203activated. These are additive, so they apply in addition to any previously 6204set style check options. The codes for the options are the same as those 6205used in the *-gnaty* switch to *gcc* or *gnatmake*. 6206For example the following two methods can be used to enable 6207layout checking: 6208 6209* 6210 6211 :: 6212 6213 pragma Style_Checks ("l"); 6214 6215 6216* 6217 6218 :: 6219 6220 gcc -c -gnatyl ... 6221 6222 6223The form ``ALL_CHECKS`` activates all standard checks (its use is equivalent 6224to the use of the :switch:`gnaty` switch with no options. 6225See the :title:`GNAT User's Guide` for details.) 6226 6227Note: the behavior is slightly different in GNAT mode (:switch:`-gnatg` used). 6228In this case, ``ALL_CHECKS`` implies the standard set of GNAT mode style check 6229options (i.e. equivalent to :switch:`-gnatyg`). 6230 6231The forms with ``Off`` and ``On`` 6232can be used to temporarily disable style checks 6233as shown in the following example: 6234 6235 6236.. code-block:: ada 6237 6238 pragma Style_Checks ("k"); -- requires keywords in lower case 6239 pragma Style_Checks (Off); -- turn off style checks 6240 NULL; -- this will not generate an error message 6241 pragma Style_Checks (On); -- turn style checks back on 6242 NULL; -- this will generate an error message 6243 6244 6245Finally the two argument form is allowed only if the first argument is 6246``On`` or ``Off``. The effect is to turn of semantic style checks 6247for the specified entity, as shown in the following example: 6248 6249 6250.. code-block:: ada 6251 6252 pragma Style_Checks ("r"); -- require consistency of identifier casing 6253 Arg : Integer; 6254 Rf1 : Integer := ARG; -- incorrect, wrong case 6255 pragma Style_Checks (Off, Arg); 6256 Rf2 : Integer := ARG; -- OK, no error 6257 6258 6259Pragma Subtitle 6260=============== 6261 6262Syntax: 6263 6264 6265:: 6266 6267 pragma Subtitle ([Subtitle =>] STRING_LITERAL); 6268 6269 6270This pragma is recognized for compatibility with other Ada compilers 6271but is ignored by GNAT. 6272 6273Pragma Suppress 6274=============== 6275 6276Syntax: 6277 6278 6279:: 6280 6281 pragma Suppress (Identifier [, [On =>] Name]); 6282 6283 6284This is a standard pragma, and supports all the check names required in 6285the RM. It is included here because GNAT recognizes some additional check 6286names that are implementation defined (as permitted by the RM): 6287 6288 6289* 6290 ``Alignment_Check`` can be used to suppress alignment checks 6291 on addresses used in address clauses. Such checks can also be suppressed 6292 by suppressing range checks, but the specific use of ``Alignment_Check`` 6293 allows suppression of alignment checks without suppressing other range checks. 6294 Note that ``Alignment_Check`` is suppressed by default on machines (such as 6295 the x86) with non-strict alignment. 6296 6297* 6298 ``Atomic_Synchronization`` can be used to suppress the special memory 6299 synchronization instructions that are normally generated for access to 6300 ``Atomic`` variables to ensure correct synchronization between tasks 6301 that use such variables for synchronization purposes. 6302 6303* 6304 ``Duplicated_Tag_Check`` Can be used to suppress the check that is generated 6305 for a duplicated tag value when a tagged type is declared. 6306 6307* 6308 ``Container_Checks`` Can be used to suppress all checks within Ada.Containers 6309 and instances of its children, including Tampering_Check. 6310 6311* 6312 ``Tampering_Check`` Can be used to suppress tampering check in the containers. 6313 6314* 6315 ``Predicate_Check`` can be used to control whether predicate checks are 6316 active. It is applicable only to predicates for which the policy is 6317 ``Check``. Unlike ``Assertion_Policy``, which determines if a given 6318 predicate is ignored or checked for the whole program, the use of 6319 ``Suppress`` and ``Unsuppress`` with this check name allows a given 6320 predicate to be turned on and off at specific points in the program. 6321 6322* 6323 ``Validity_Check`` can be used specifically to control validity checks. 6324 If ``Suppress`` is used to suppress validity checks, then no validity 6325 checks are performed, including those specified by the appropriate compiler 6326 switch or the ``Validity_Checks`` pragma. 6327 6328* 6329 Additional check names previously introduced by use of the ``Check_Name`` 6330 pragma are also allowed. 6331 6332 6333Note that pragma Suppress gives the compiler permission to omit 6334checks, but does not require the compiler to omit checks. The compiler 6335will generate checks if they are essentially free, even when they are 6336suppressed. In particular, if the compiler can prove that a certain 6337check will necessarily fail, it will generate code to do an 6338unconditional 'raise', even if checks are suppressed. The compiler 6339warns in this case. 6340 6341Of course, run-time checks are omitted whenever the compiler can prove 6342that they will not fail, whether or not checks are suppressed. 6343 6344Pragma Suppress_All 6345=================== 6346 6347Syntax: 6348 6349 6350.. code-block:: ada 6351 6352 pragma Suppress_All; 6353 6354 6355This pragma can appear anywhere within a unit. 6356The effect is to apply ``Suppress (All_Checks)`` to the unit 6357in which it appears. This pragma is implemented for compatibility with DEC 6358Ada 83 usage where it appears at the end of a unit, and for compatibility 6359with Rational Ada, where it appears as a program unit pragma. 6360The use of the standard Ada pragma ``Suppress (All_Checks)`` 6361as a normal configuration pragma is the preferred usage in GNAT. 6362 6363.. _Pragma-Suppress_Debug_Info: 6364 6365Pragma Suppress_Debug_Info 6366========================== 6367 6368Syntax: 6369 6370 6371:: 6372 6373 pragma Suppress_Debug_Info ([Entity =>] LOCAL_NAME); 6374 6375 6376This pragma can be used to suppress generation of debug information 6377for the specified entity. It is intended primarily for use in debugging 6378the debugger, and navigating around debugger problems. 6379 6380Pragma Suppress_Exception_Locations 6381=================================== 6382 6383Syntax: 6384 6385 6386.. code-block:: ada 6387 6388 pragma Suppress_Exception_Locations; 6389 6390 6391In normal mode, a raise statement for an exception by default generates 6392an exception message giving the file name and line number for the location 6393of the raise. This is useful for debugging and logging purposes, but this 6394entails extra space for the strings for the messages. The configuration 6395pragma ``Suppress_Exception_Locations`` can be used to suppress the 6396generation of these strings, with the result that space is saved, but the 6397exception message for such raises is null. This configuration pragma may 6398appear in a global configuration pragma file, or in a specific unit as 6399usual. It is not required that this pragma be used consistently within 6400a partition, so it is fine to have some units within a partition compiled 6401with this pragma and others compiled in normal mode without it. 6402 6403.. _Pragma-Suppress_Initialization: 6404 6405Pragma Suppress_Initialization 6406============================== 6407.. index:: Suppressing initialization 6408 6409.. index:: Initialization, suppression of 6410 6411Syntax: 6412 6413 6414:: 6415 6416 pragma Suppress_Initialization ([Entity =>] variable_or_subtype_Name); 6417 6418 6419Here variable_or_subtype_Name is the name introduced by a type declaration 6420or subtype declaration or the name of a variable introduced by an 6421object declaration. 6422 6423In the case of a type or subtype 6424this pragma suppresses any implicit or explicit initialization 6425for all variables of the given type or subtype, 6426including initialization resulting from the use of pragmas 6427Normalize_Scalars or Initialize_Scalars. 6428 6429This is considered a representation item, so it cannot be given after 6430the type is frozen. It applies to all subsequent object declarations, 6431and also any allocator that creates objects of the type. 6432 6433If the pragma is given for the first subtype, then it is considered 6434to apply to the base type and all its subtypes. If the pragma is given 6435for other than a first subtype, then it applies only to the given subtype. 6436The pragma may not be given after the type is frozen. 6437 6438Note that this includes eliminating initialization of discriminants 6439for discriminated types, and tags for tagged types. In these cases, 6440you will have to use some non-portable mechanism (e.g. address 6441overlays or unchecked conversion) to achieve required initialization 6442of these fields before accessing any object of the corresponding type. 6443 6444For the variable case, implicit initialization for the named variable 6445is suppressed, just as though its subtype had been given in a pragma 6446Suppress_Initialization, as described above. 6447 6448Pragma Task_Name 6449================ 6450 6451Syntax 6452 6453 6454.. code-block:: ada 6455 6456 pragma Task_Name (string_EXPRESSION); 6457 6458 6459This pragma appears within a task definition (like pragma 6460``Priority``) and applies to the task in which it appears. The 6461argument must be of type String, and provides a name to be used for 6462the task instance when the task is created. Note that this expression 6463is not required to be static, and in particular, it can contain 6464references to task discriminants. This facility can be used to 6465provide different names for different tasks as they are created, 6466as illustrated in the example below. 6467 6468The task name is recorded internally in the run-time structures 6469and is accessible to tools like the debugger. In addition the 6470routine ``Ada.Task_Identification.Image`` will return this 6471string, with a unique task address appended. 6472 6473 6474.. code-block:: ada 6475 6476 -- Example of the use of pragma Task_Name 6477 6478 with Ada.Task_Identification; 6479 use Ada.Task_Identification; 6480 with Text_IO; use Text_IO; 6481 procedure t3 is 6482 6483 type Astring is access String; 6484 6485 task type Task_Typ (Name : access String) is 6486 pragma Task_Name (Name.all); 6487 end Task_Typ; 6488 6489 task body Task_Typ is 6490 Nam : constant String := Image (Current_Task); 6491 begin 6492 Put_Line ("-->" & Nam (1 .. 14) & "<--"); 6493 end Task_Typ; 6494 6495 type Ptr_Task is access Task_Typ; 6496 Task_Var : Ptr_Task; 6497 6498 begin 6499 Task_Var := 6500 new Task_Typ (new String'("This is task 1")); 6501 Task_Var := 6502 new Task_Typ (new String'("This is task 2")); 6503 end; 6504 6505 6506Pragma Task_Storage 6507=================== 6508Syntax: 6509 6510 6511:: 6512 6513 pragma Task_Storage ( 6514 [Task_Type =>] LOCAL_NAME, 6515 [Top_Guard =>] static_integer_EXPRESSION); 6516 6517 6518This pragma specifies the length of the guard area for tasks. The guard 6519area is an additional storage area allocated to a task. A value of zero 6520means that either no guard area is created or a minimal guard area is 6521created, depending on the target. This pragma can appear anywhere a 6522``Storage_Size`` attribute definition clause is allowed for a task 6523type. 6524 6525.. _Pragma-Test_Case: 6526 6527Pragma Test_Case 6528================ 6529.. index:: Test cases 6530 6531 6532Syntax: 6533 6534 6535:: 6536 6537 pragma Test_Case ( 6538 [Name =>] static_string_Expression 6539 ,[Mode =>] (Nominal | Robustness) 6540 [, Requires => Boolean_Expression] 6541 [, Ensures => Boolean_Expression]); 6542 6543 6544The ``Test_Case`` pragma allows defining fine-grain specifications 6545for use by testing tools. 6546The compiler checks the validity of the ``Test_Case`` pragma, but its 6547presence does not lead to any modification of the code generated by the 6548compiler. 6549 6550``Test_Case`` pragmas may only appear immediately following the 6551(separate) declaration of a subprogram in a package declaration, inside 6552a package spec unit. Only other pragmas may intervene (that is appear 6553between the subprogram declaration and a test case). 6554 6555The compiler checks that boolean expressions given in ``Requires`` and 6556``Ensures`` are valid, where the rules for ``Requires`` are the 6557same as the rule for an expression in ``Precondition`` and the rules 6558for ``Ensures`` are the same as the rule for an expression in 6559``Postcondition``. In particular, attributes ``'Old`` and 6560``'Result`` can only be used within the ``Ensures`` 6561expression. The following is an example of use within a package spec: 6562 6563 6564.. code-block:: ada 6565 6566 package Math_Functions is 6567 ... 6568 function Sqrt (Arg : Float) return Float; 6569 pragma Test_Case (Name => "Test 1", 6570 Mode => Nominal, 6571 Requires => Arg < 10000, 6572 Ensures => Sqrt'Result < 10); 6573 ... 6574 end Math_Functions; 6575 6576 6577The meaning of a test case is that there is at least one context where 6578``Requires`` holds such that, if the associated subprogram is executed in 6579that context, then ``Ensures`` holds when the subprogram returns. 6580Mode ``Nominal`` indicates that the input context should also satisfy the 6581precondition of the subprogram, and the output context should also satisfy its 6582postcondition. Mode ``Robustness`` indicates that the precondition and 6583postcondition of the subprogram should be ignored for this test case. 6584 6585.. _Pragma-Thread_Local_Storage: 6586 6587Pragma Thread_Local_Storage 6588=========================== 6589.. index:: Task specific storage 6590 6591.. index:: TLS (Thread Local Storage) 6592 6593.. index:: Task_Attributes 6594 6595Syntax: 6596 6597 6598:: 6599 6600 pragma Thread_Local_Storage ([Entity =>] LOCAL_NAME); 6601 6602 6603This pragma specifies that the specified entity, which must be 6604a variable declared in a library-level package, is to be marked as 6605"Thread Local Storage" (``TLS``). On systems supporting this (which 6606include Windows, Solaris, GNU/Linux and VxWorks 6), this causes each 6607thread (and hence each Ada task) to see a distinct copy of the variable. 6608 6609The variable may not have default initialization, and if there is 6610an explicit initialization, it must be either ``null`` for an 6611access variable, or a static expression for a scalar variable. 6612This provides a low level mechanism similar to that provided by 6613the ``Ada.Task_Attributes`` package, but much more efficient 6614and is also useful in writing interface code that will interact 6615with foreign threads. 6616 6617If this pragma is used on a system where ``TLS`` is not supported, 6618then an error message will be generated and the program will be rejected. 6619 6620Pragma Time_Slice 6621================= 6622 6623Syntax: 6624 6625 6626.. code-block:: ada 6627 6628 pragma Time_Slice (static_duration_EXPRESSION); 6629 6630 6631For implementations of GNAT on operating systems where it is possible 6632to supply a time slice value, this pragma may be used for this purpose. 6633It is ignored if it is used in a system that does not allow this control, 6634or if it appears in other than the main program unit. 6635 6636Pragma Title 6637============ 6638 6639Syntax: 6640 6641 6642:: 6643 6644 pragma Title (TITLING_OPTION [, TITLING OPTION]); 6645 6646 TITLING_OPTION ::= 6647 [Title =>] STRING_LITERAL, 6648 | [Subtitle =>] STRING_LITERAL 6649 6650 6651Syntax checked but otherwise ignored by GNAT. This is a listing control 6652pragma used in DEC Ada 83 implementations to provide a title and/or 6653subtitle for the program listing. The program listing generated by GNAT 6654does not have titles or subtitles. 6655 6656Unlike other pragmas, the full flexibility of named notation is allowed 6657for this pragma, i.e., the parameters may be given in any order if named 6658notation is used, and named and positional notation can be mixed 6659following the normal rules for procedure calls in Ada. 6660 6661Pragma Type_Invariant 6662===================== 6663 6664Syntax: 6665 6666 6667:: 6668 6669 pragma Type_Invariant 6670 ([Entity =>] type_LOCAL_NAME, 6671 [Check =>] EXPRESSION); 6672 6673 6674The ``Type_Invariant`` pragma is intended to be an exact 6675replacement for the language-defined ``Type_Invariant`` 6676aspect, and shares its restrictions and semantics. It differs 6677from the language defined ``Invariant`` pragma in that it 6678does not permit a string parameter, and it is 6679controlled by the assertion identifier ``Type_Invariant`` 6680rather than ``Invariant``. 6681 6682.. _Pragma-Type_Invariant_Class: 6683 6684Pragma Type_Invariant_Class 6685=========================== 6686 6687Syntax: 6688 6689 6690:: 6691 6692 pragma Type_Invariant_Class 6693 ([Entity =>] type_LOCAL_NAME, 6694 [Check =>] EXPRESSION); 6695 6696 6697The ``Type_Invariant_Class`` pragma is intended to be an exact 6698replacement for the language-defined ``Type_Invariant'Class`` 6699aspect, and shares its restrictions and semantics. 6700 6701Note: This pragma is called ``Type_Invariant_Class`` rather than 6702``Type_Invariant'Class`` because the latter would not be strictly 6703conforming to the allowed syntax for pragmas. The motivation 6704for providing pragmas equivalent to the aspects is to allow a program 6705to be written using the pragmas, and then compiled if necessary 6706using an Ada compiler that does not recognize the pragmas or 6707aspects, but is prepared to ignore the pragmas. The assertion 6708policy that controls this pragma is ``Type_Invariant'Class``, 6709not ``Type_Invariant_Class``. 6710 6711Pragma Unchecked_Union 6712====================== 6713.. index:: Unions in C 6714 6715 6716Syntax: 6717 6718 6719.. code-block:: ada 6720 6721 pragma Unchecked_Union (first_subtype_LOCAL_NAME); 6722 6723 6724This pragma is used to specify a representation of a record type that is 6725equivalent to a C union. It was introduced as a GNAT implementation defined 6726pragma in the GNAT Ada 95 mode. Ada 2005 includes an extended version of this 6727pragma, making it language defined, and GNAT fully implements this extended 6728version in all language modes (Ada 83, Ada 95, and Ada 2005). For full 6729details, consult the Ada 2012 Reference Manual, section B.3.3. 6730 6731Pragma Unevaluated_Use_Of_Old 6732============================= 6733.. index:: Attribute Old 6734 6735.. index:: Attribute Loop_Entry 6736 6737.. index:: Unevaluated_Use_Of_Old 6738 6739 6740Syntax: 6741 6742 6743.. code-block:: ada 6744 6745 pragma Unevaluated_Use_Of_Old (Error | Warn | Allow); 6746 6747 6748This pragma controls the processing of attributes Old and Loop_Entry. 6749If either of these attributes is used in a potentially unevaluated 6750expression (e.g. the then or else parts of an if expression), then 6751normally this usage is considered illegal if the prefix of the attribute 6752is other than an entity name. The language requires this 6753behavior for Old, and GNAT copies the same rule for Loop_Entry. 6754 6755The reason for this rule is that otherwise, we can have a situation 6756where we save the Old value, and this results in an exception, even 6757though we might not evaluate the attribute. Consider this example: 6758 6759 6760.. code-block:: ada 6761 6762 package UnevalOld is 6763 K : Character; 6764 procedure U (A : String; C : Boolean) -- ERROR 6765 with Post => (if C then A(1)'Old = K else True); 6766 end; 6767 6768 6769If procedure U is called with a string with a lower bound of 2, and 6770C false, then an exception would be raised trying to evaluate A(1) 6771on entry even though the value would not be actually used. 6772 6773Although the rule guarantees against this possibility, it is sometimes 6774too restrictive. For example if we know that the string has a lower 6775bound of 1, then we will never raise an exception. 6776The pragma ``Unevaluated_Use_Of_Old`` can be 6777used to modify this behavior. If the argument is ``Error`` then an 6778error is given (this is the default RM behavior). If the argument is 6779``Warn`` then the usage is allowed as legal but with a warning 6780that an exception might be raised. If the argument is ``Allow`` 6781then the usage is allowed as legal without generating a warning. 6782 6783This pragma may appear as a configuration pragma, or in a declarative 6784part or package specification. In the latter case it applies to 6785uses up to the end of the corresponding statement sequence or 6786sequence of package declarations. 6787 6788Pragma Unimplemented_Unit 6789========================= 6790 6791Syntax: 6792 6793 6794.. code-block:: ada 6795 6796 pragma Unimplemented_Unit; 6797 6798 6799If this pragma occurs in a unit that is processed by the compiler, GNAT 6800aborts with the message :samp:`xxx not implemented`, where 6801``xxx`` is the name of the current compilation unit. This pragma is 6802intended to allow the compiler to handle unimplemented library units in 6803a clean manner. 6804 6805The abort only happens if code is being generated. Thus you can use 6806specs of unimplemented packages in syntax or semantic checking mode. 6807 6808.. _Pragma-Universal_Aliasing: 6809 6810Pragma Universal_Aliasing 6811========================= 6812 6813Syntax: 6814 6815 6816:: 6817 6818 pragma Universal_Aliasing [([Entity =>] type_LOCAL_NAME)]; 6819 6820 6821``type_LOCAL_NAME`` must refer to a type declaration in the current 6822declarative part. The effect is to inhibit strict type-based aliasing 6823optimization for the given type. In other words, the effect is as though 6824access types designating this type were subject to pragma No_Strict_Aliasing. 6825For a detailed description of the strict aliasing optimization, and the 6826situations in which it must be suppressed, see the section on 6827``Optimization and Strict Aliasing`` in the :title:`GNAT User's Guide`. 6828 6829.. _Pragma-Universal_Data: 6830 6831Pragma Universal_Data 6832===================== 6833 6834Syntax: 6835 6836 6837:: 6838 6839 pragma Universal_Data [(library_unit_Name)]; 6840 6841 6842This pragma is supported only for the AAMP target and is ignored for 6843other targets. The pragma specifies that all library-level objects 6844(Counter 0 data) associated with the library unit are to be accessed 6845and updated using universal addressing (24-bit addresses for AAMP5) 6846rather than the default of 16-bit Data Environment (DENV) addressing. 6847Use of this pragma will generally result in less efficient code for 6848references to global data associated with the library unit, but 6849allows such data to be located anywhere in memory. This pragma is 6850a library unit pragma, but can also be used as a configuration pragma 6851(including use in the :file:`gnat.adc` file). The functionality 6852of this pragma is also available by applying the -univ switch on the 6853compilations of units where universal addressing of the data is desired. 6854 6855.. _Pragma-Unmodified: 6856 6857Pragma Unmodified 6858================= 6859.. index:: Warnings, unmodified 6860 6861Syntax: 6862 6863 6864:: 6865 6866 pragma Unmodified (LOCAL_NAME {, LOCAL_NAME}); 6867 6868 6869This pragma signals that the assignable entities (variables, 6870``out`` parameters, ``in out`` parameters) whose names are listed are 6871deliberately not assigned in the current source unit. This 6872suppresses warnings about the 6873entities being referenced but not assigned, and in addition a warning will be 6874generated if one of these entities is in fact assigned in the 6875same unit as the pragma (or in the corresponding body, or one 6876of its subunits). 6877 6878This is particularly useful for clearly signaling that a particular 6879parameter is not modified, even though the spec suggests that it might 6880be. 6881 6882For the variable case, warnings are never given for unreferenced variables 6883whose name contains one of the substrings 6884``DISCARD, DUMMY, IGNORE, JUNK, UNUSED`` in any casing. Such names 6885are typically to be used in cases where such warnings are expected. 6886Thus it is never necessary to use ``pragma Unmodified`` for such 6887variables, though it is harmless to do so. 6888 6889.. _Pragma-Unreferenced: 6890 6891Pragma Unreferenced 6892=================== 6893.. index:: Warnings, unreferenced 6894 6895Syntax: 6896 6897 6898:: 6899 6900 pragma Unreferenced (LOCAL_NAME {, LOCAL_NAME}); 6901 pragma Unreferenced (library_unit_NAME {, library_unit_NAME}); 6902 6903 6904This pragma signals that the entities whose names are listed are 6905deliberately not referenced in the current source unit after the 6906occurrence of the pragma. This 6907suppresses warnings about the 6908entities being unreferenced, and in addition a warning will be 6909generated if one of these entities is in fact subsequently referenced in the 6910same unit as the pragma (or in the corresponding body, or one 6911of its subunits). 6912 6913This is particularly useful for clearly signaling that a particular 6914parameter is not referenced in some particular subprogram implementation 6915and that this is deliberate. It can also be useful in the case of 6916objects declared only for their initialization or finalization side 6917effects. 6918 6919If ``LOCAL_NAME`` identifies more than one matching homonym in the 6920current scope, then the entity most recently declared is the one to which 6921the pragma applies. Note that in the case of accept formals, the pragma 6922Unreferenced may appear immediately after the keyword ``do`` which 6923allows the indication of whether or not accept formals are referenced 6924or not to be given individually for each accept statement. 6925 6926The left hand side of an assignment does not count as a reference for the 6927purpose of this pragma. Thus it is fine to assign to an entity for which 6928pragma Unreferenced is given. 6929 6930Note that if a warning is desired for all calls to a given subprogram, 6931regardless of whether they occur in the same unit as the subprogram 6932declaration, then this pragma should not be used (calls from another 6933unit would not be flagged); pragma Obsolescent can be used instead 6934for this purpose, see :ref:`Pragma_Obsolescent`. 6935 6936The second form of pragma ``Unreferenced`` is used within a context 6937clause. In this case the arguments must be unit names of units previously 6938mentioned in ``with`` clauses (similar to the usage of pragma 6939``Elaborate_All``. The effect is to suppress warnings about unreferenced 6940units and unreferenced entities within these units. 6941 6942For the variable case, warnings are never given for unreferenced variables 6943whose name contains one of the substrings 6944``DISCARD, DUMMY, IGNORE, JUNK, UNUSED`` in any casing. Such names 6945are typically to be used in cases where such warnings are expected. 6946Thus it is never necessary to use ``pragma Unreferenced`` for such 6947variables, though it is harmless to do so. 6948 6949.. _Pragma-Unreferenced_Objects: 6950 6951Pragma Unreferenced_Objects 6952=========================== 6953.. index:: Warnings, unreferenced 6954 6955Syntax: 6956 6957 6958:: 6959 6960 pragma Unreferenced_Objects (local_subtype_NAME {, local_subtype_NAME}); 6961 6962 6963This pragma signals that for the types or subtypes whose names are 6964listed, objects which are declared with one of these types or subtypes may 6965not be referenced, and if no references appear, no warnings are given. 6966 6967This is particularly useful for objects which are declared solely for their 6968initialization and finalization effect. Such variables are sometimes referred 6969to as RAII variables (Resource Acquisition Is Initialization). Using this 6970pragma on the relevant type (most typically a limited controlled type), the 6971compiler will automatically suppress unwanted warnings about these variables 6972not being referenced. 6973 6974Pragma Unreserve_All_Interrupts 6975=============================== 6976 6977Syntax: 6978 6979 6980.. code-block:: ada 6981 6982 pragma Unreserve_All_Interrupts; 6983 6984 6985Normally certain interrupts are reserved to the implementation. Any attempt 6986to attach an interrupt causes Program_Error to be raised, as described in 6987RM C.3.2(22). A typical example is the ``SIGINT`` interrupt used in 6988many systems for a :kbd:`Ctrl-C` interrupt. Normally this interrupt is 6989reserved to the implementation, so that :kbd:`Ctrl-C` can be used to 6990interrupt execution. 6991 6992If the pragma ``Unreserve_All_Interrupts`` appears anywhere in any unit in 6993a program, then all such interrupts are unreserved. This allows the 6994program to handle these interrupts, but disables their standard 6995functions. For example, if this pragma is used, then pressing 6996:kbd:`Ctrl-C` will not automatically interrupt execution. However, 6997a program can then handle the ``SIGINT`` interrupt as it chooses. 6998 6999For a full list of the interrupts handled in a specific implementation, 7000see the source code for the spec of ``Ada.Interrupts.Names`` in 7001file :file:`a-intnam.ads`. This is a target dependent file that contains the 7002list of interrupts recognized for a given target. The documentation in 7003this file also specifies what interrupts are affected by the use of 7004the ``Unreserve_All_Interrupts`` pragma. 7005 7006For a more general facility for controlling what interrupts can be 7007handled, see pragma ``Interrupt_State``, which subsumes the functionality 7008of the ``Unreserve_All_Interrupts`` pragma. 7009 7010Pragma Unsuppress 7011================= 7012 7013Syntax: 7014 7015 7016:: 7017 7018 pragma Unsuppress (IDENTIFIER [, [On =>] NAME]); 7019 7020 7021This pragma undoes the effect of a previous pragma ``Suppress``. If 7022there is no corresponding pragma ``Suppress`` in effect, it has no 7023effect. The range of the effect is the same as for pragma 7024``Suppress``. The meaning of the arguments is identical to that used 7025in pragma ``Suppress``. 7026 7027One important application is to ensure that checks are on in cases where 7028code depends on the checks for its correct functioning, so that the code 7029will compile correctly even if the compiler switches are set to suppress 7030checks. For example, in a program that depends on external names of tagged 7031types and wants to ensure that the duplicated tag check occurs even if all 7032run-time checks are suppressed by a compiler switch, the following 7033configuration pragma will ensure this test is not suppressed: 7034 7035 7036.. code-block:: ada 7037 7038 pragma Unsuppress (Duplicated_Tag_Check); 7039 7040 7041This pragma is standard in Ada 2005. It is available in all earlier versions 7042of Ada as an implementation-defined pragma. 7043 7044Note that in addition to the checks defined in the Ada RM, GNAT recogizes a 7045number of implementation-defined check names. See the description of pragma 7046``Suppress`` for full details. 7047 7048Pragma Use_VADS_Size 7049==================== 7050.. index:: Size, VADS compatibility 7051 7052.. index:: Rational profile 7053 7054 7055Syntax: 7056 7057 7058.. code-block:: ada 7059 7060 pragma Use_VADS_Size; 7061 7062 7063This is a configuration pragma. In a unit to which it applies, any use 7064of the 'Size attribute is automatically interpreted as a use of the 7065'VADS_Size attribute. Note that this may result in incorrect semantic 7066processing of valid Ada 95 or Ada 2005 programs. This is intended to aid in 7067the handling of existing code which depends on the interpretation of Size 7068as implemented in the VADS compiler. See description of the VADS_Size 7069attribute for further details. 7070 7071.. _Pragma-Unused: 7072 7073Pragma Unused 7074============= 7075.. index:: Warnings, unused 7076 7077Syntax: 7078 7079 7080:: 7081 7082 pragma Unused (LOCAL_NAME {, LOCAL_NAME}); 7083 7084 7085This pragma signals that the assignable entities (variables, 7086``out`` parameters, and ``in out`` parameters) whose names are listed 7087deliberately do not get assigned or referenced in the current source unit 7088after the occurrence of the pragma in the current source unit. This 7089suppresses warnings about the entities that are unreferenced and/or not 7090assigned, and, in addition, a warning will be generated if one of these 7091entities gets assigned or subsequently referenced in the same unit as the 7092pragma (in the corresponding body or one of its subunits). 7093 7094This is particularly useful for clearly signaling that a particular 7095parameter is not modified or referenced, even though the spec suggests 7096that it might be. 7097 7098For the variable case, warnings are never given for unreferenced 7099variables whose name contains one of the substrings 7100``DISCARD, DUMMY, IGNORE, JUNK, UNUSED`` in any casing. Such names 7101are typically to be used in cases where such warnings are expected. 7102Thus it is never necessary to use ``pragma Unmodified`` for such 7103variables, though it is harmless to do so. 7104 7105Pragma Validity_Checks 7106====================== 7107 7108Syntax: 7109 7110 7111.. code-block:: ada 7112 7113 pragma Validity_Checks (string_LITERAL | ALL_CHECKS | On | Off); 7114 7115 7116This pragma is used in conjunction with compiler switches to control the 7117built-in validity checking provided by GNAT. The compiler switches, if set 7118provide an initial setting for the switches, and this pragma may be used 7119to modify these settings, or the settings may be provided entirely by 7120the use of the pragma. This pragma can be used anywhere that a pragma 7121is legal, including use as a configuration pragma (including use in 7122the :file:`gnat.adc` file). 7123 7124The form with a string literal specifies which validity options are to be 7125activated. The validity checks are first set to include only the default 7126reference manual settings, and then a string of letters in the string 7127specifies the exact set of options required. The form of this string 7128is exactly as described for the *-gnatVx* compiler switch (see the 7129GNAT User's Guide for details). For example the following two 7130methods can be used to enable validity checking for mode ``in`` and 7131``in out`` subprogram parameters: 7132 7133* 7134 7135 .. code-block:: ada 7136 7137 pragma Validity_Checks ("im"); 7138 7139 7140* 7141 7142 .. code-block:: sh 7143 7144 $ gcc -c -gnatVim ... 7145 7146 7147The form ALL_CHECKS activates all standard checks (its use is equivalent 7148to the use of the :switch:`gnatva` switch. 7149 7150The forms with ``Off`` and ``On`` 7151can be used to temporarily disable validity checks 7152as shown in the following example: 7153 7154 7155.. code-block:: ada 7156 7157 pragma Validity_Checks ("c"); -- validity checks for copies 7158 pragma Validity_Checks (Off); -- turn off validity checks 7159 A := B; -- B will not be validity checked 7160 pragma Validity_Checks (On); -- turn validity checks back on 7161 A := C; -- C will be validity checked 7162 7163 7164Pragma Volatile 7165=============== 7166 7167Syntax: 7168 7169 7170.. code-block:: ada 7171 7172 pragma Volatile (LOCAL_NAME); 7173 7174 7175This pragma is defined by the Ada Reference Manual, and the GNAT 7176implementation is fully conformant with this definition. The reason it 7177is mentioned in this section is that a pragma of the same name was supplied 7178in some Ada 83 compilers, including DEC Ada 83. The Ada 95 / Ada 2005 7179implementation of pragma Volatile is upwards compatible with the 7180implementation in DEC Ada 83. 7181 7182.. _Pragma-Volatile_Full_Access: 7183 7184Pragma Volatile_Full_Access 7185=========================== 7186 7187Syntax: 7188 7189 7190.. code-block:: ada 7191 7192 pragma Volatile_Full_Access (LOCAL_NAME); 7193 7194 7195This is similar in effect to pragma Volatile, except that any reference to the 7196object is guaranteed to be done only with instructions that read or write all 7197the bits of the object. Furthermore, if the object is of a composite type, 7198then any reference to a component of the object is guaranteed to read and/or 7199write all the bits of the object. 7200 7201The intention is that this be suitable for use with memory-mapped I/O devices 7202on some machines. Note that there are two important respects in which this is 7203different from ``pragma Atomic``. First a reference to a ``Volatile_Full_Access`` 7204object is not a sequential action in the RM 9.10 sense and, therefore, does 7205not create a synchronization point. Second, in the case of ``pragma Atomic``, 7206there is no guarantee that all the bits will be accessed if the reference 7207is not to the whole object; the compiler is allowed (and generally will) 7208access only part of the object in this case. 7209 7210It is not permissible to specify ``Atomic`` and ``Volatile_Full_Access`` for 7211the same object. 7212 7213It is not permissible to specify ``Volatile_Full_Access`` for a composite 7214(record or array) type or object that has at least one ``Aliased`` component. 7215 7216.. _Pragma-Volatile_Function: 7217 7218Pragma Volatile_Function 7219======================== 7220 7221Syntax: 7222 7223.. code-block:: ada 7224 7225 pragma Volatile_Function [ (boolean_EXPRESSION) ]; 7226 7227For the semantics of this pragma, see the entry for aspect ``Volatile_Function`` 7228in the SPARK 2014 Reference Manual, section 7.1.2. 7229 7230Pragma Warning_As_Error 7231======================= 7232 7233Syntax: 7234 7235 7236.. code-block:: ada 7237 7238 pragma Warning_As_Error (static_string_EXPRESSION); 7239 7240 7241This configuration pragma allows the programmer to specify a set 7242of warnings that will be treated as errors. Any warning which 7243matches the pattern given by the pragma argument will be treated 7244as an error. This gives much more precise control that -gnatwe 7245which treats all warnings as errors. 7246 7247The pattern may contain asterisks, which match zero or more characters in 7248the message. For example, you can use 7249``pragma Warning_As_Error ("bits of*unused")`` to treat the warning 7250message ``warning: 960 bits of "a" unused`` as an error. No other regular 7251expression notations are permitted. All characters other than asterisk in 7252these three specific cases are treated as literal characters in the match. 7253The match is case insensitive, for example XYZ matches xyz. 7254 7255Note that the pattern matches if it occurs anywhere within the warning 7256message string (it is not necessary to put an asterisk at the start and 7257the end of the message, since this is implied). 7258 7259Another possibility for the static_string_EXPRESSION which works whether 7260or not error tags are enabled (*-gnatw.d*) is to use the 7261*-gnatw* tag string, enclosed in brackets, 7262as shown in the example below, to treat a class of warnings as errors. 7263 7264The above use of patterns to match the message applies only to warning 7265messages generated by the front end. This pragma can also be applied to 7266warnings provided by the back end and mentioned in :ref:`Pragma_Warnings`. 7267By using a single full *-Wxxx* switch in the pragma, such warnings 7268can also be treated as errors. 7269 7270The pragma can appear either in a global configuration pragma file 7271(e.g. :file:`gnat.adc`), or at the start of a file. Given a global 7272configuration pragma file containing: 7273 7274 7275.. code-block:: ada 7276 7277 pragma Warning_As_Error ("[-gnatwj]"); 7278 7279 7280which will treat all obsolescent feature warnings as errors, the 7281following program compiles as shown (compile options here are 7282*-gnatwa.d -gnatl -gnatj55*). 7283 7284 7285:: 7286 7287 1. pragma Warning_As_Error ("*never assigned*"); 7288 2. function Warnerr return String is 7289 3. X : Integer; 7290 | 7291 >>> error: variable "X" is never read and 7292 never assigned [-gnatwv] [warning-as-error] 7293 7294 4. Y : Integer; 7295 | 7296 >>> warning: variable "Y" is assigned but 7297 never read [-gnatwu] 7298 7299 5. begin 7300 6. Y := 0; 7301 7. return %ABC%; 7302 | 7303 >>> error: use of "%" is an obsolescent 7304 feature (RM J.2(4)), use """ instead 7305 [-gnatwj] [warning-as-error] 7306 7307 8. end; 7308 7309 8 lines: No errors, 3 warnings (2 treated as errors) 7310 7311 7312Note that this pragma does not affect the set of warnings issued in 7313any way, it merely changes the effect of a matching warning if one 7314is produced as a result of other warnings options. As shown in this 7315example, if the pragma results in a warning being treated as an error, 7316the tag is changed from "warning:" to "error:" and the string 7317"[warning-as-error]" is appended to the end of the message. 7318 7319.. _Pragma_Warnings: 7320 7321Pragma Warnings 7322=============== 7323 7324Syntax: 7325 7326 7327.. code-block:: ada 7328 7329 pragma Warnings ([TOOL_NAME,] DETAILS [, REASON]); 7330 7331 DETAILS ::= On | Off 7332 DETAILS ::= On | Off, local_NAME 7333 DETAILS ::= static_string_EXPRESSION 7334 DETAILS ::= On | Off, static_string_EXPRESSION 7335 7336 TOOL_NAME ::= GNAT | GNATProve 7337 7338 REASON ::= Reason => STRING_LITERAL {& STRING_LITERAL} 7339 7340Note: in Ada 83 mode, a string literal may be used in place of a static string 7341expression (which does not exist in Ada 83). 7342 7343Note if the second argument of ``DETAILS`` is a ``local_NAME`` then the 7344second form is always understood. If the intention is to use 7345the fourth form, then you can write ``NAME & ""`` to force the 7346intepretation as a *static_string_EXPRESSION*. 7347 7348Note: if the first argument is a valid ``TOOL_NAME``, it will be interpreted 7349that way. The use of the ``TOOL_NAME`` argument is relevant only to users 7350of SPARK and GNATprove, see last part of this section for details. 7351 7352Normally warnings are enabled, with the output being controlled by 7353the command line switch. Warnings (``Off``) turns off generation of 7354warnings until a Warnings (``On``) is encountered or the end of the 7355current unit. If generation of warnings is turned off using this 7356pragma, then some or all of the warning messages are suppressed, 7357regardless of the setting of the command line switches. 7358 7359The ``Reason`` parameter may optionally appear as the last argument 7360in any of the forms of this pragma. It is intended purely for the 7361purposes of documenting the reason for the ``Warnings`` pragma. 7362The compiler will check that the argument is a static string but 7363otherwise ignore this argument. Other tools may provide specialized 7364processing for this string. 7365 7366The form with a single argument (or two arguments if Reason present), 7367where the first argument is ``ON`` or ``OFF`` 7368may be used as a configuration pragma. 7369 7370If the ``LOCAL_NAME`` parameter is present, warnings are suppressed for 7371the specified entity. This suppression is effective from the point where 7372it occurs till the end of the extended scope of the variable (similar to 7373the scope of ``Suppress``). This form cannot be used as a configuration 7374pragma. 7375 7376In the case where the first argument is other than ``ON`` or 7377``OFF``, 7378the third form with a single static_string_EXPRESSION argument (and possible 7379reason) provides more precise 7380control over which warnings are active. The string is a list of letters 7381specifying which warnings are to be activated and which deactivated. The 7382code for these letters is the same as the string used in the command 7383line switch controlling warnings. For a brief summary, use the gnatmake 7384command with no arguments, which will generate usage information containing 7385the list of warnings switches supported. For 7386full details see the section on ``Warning Message Control`` in the 7387:title:`GNAT User's Guide`. 7388This form can also be used as a configuration pragma. 7389 7390The warnings controlled by the :switch:`-gnatw` switch are generated by the 7391front end of the compiler. The GCC back end can provide additional warnings 7392and they are controlled by the :switch:`-W` switch. Such warnings can be 7393identified by the appearance of a string of the form ``[-W{xxx}]`` in the 7394message which designates the :switch:`-W{xxx}` switch that controls the message. 7395The form with a single *static_string_EXPRESSION* argument also works for these 7396warnings, but the string must be a single full :switch:`-W{xxx}` switch in this 7397case. The above reference lists a few examples of these additional warnings. 7398 7399The specified warnings will be in effect until the end of the program 7400or another pragma ``Warnings`` is encountered. The effect of the pragma is 7401cumulative. Initially the set of warnings is the standard default set 7402as possibly modified by compiler switches. Then each pragma Warning 7403modifies this set of warnings as specified. This form of the pragma may 7404also be used as a configuration pragma. 7405 7406The fourth form, with an ``On|Off`` parameter and a string, is used to 7407control individual messages, based on their text. The string argument 7408is a pattern that is used to match against the text of individual 7409warning messages (not including the initial "warning: " tag). 7410 7411The pattern may contain asterisks, which match zero or more characters in 7412the message. For example, you can use 7413``pragma Warnings (Off, "bits of*unused")`` to suppress the warning 7414message ``warning: 960 bits of "a" unused``. No other regular 7415expression notations are permitted. All characters other than asterisk in 7416these three specific cases are treated as literal characters in the match. 7417The match is case insensitive, for example XYZ matches xyz. 7418 7419Note that the pattern matches if it occurs anywhere within the warning 7420message string (it is not necessary to put an asterisk at the start and 7421the end of the message, since this is implied). 7422 7423The above use of patterns to match the message applies only to warning 7424messages generated by the front end. This form of the pragma with a string 7425argument can also be used to control warnings provided by the back end and 7426mentioned above. By using a single full :switch:`-W{xxx}` switch in the pragma, 7427such warnings can be turned on and off. 7428 7429There are two ways to use the pragma in this form. The OFF form can be used 7430as a configuration pragma. The effect is to suppress all warnings (if any) 7431that match the pattern string throughout the compilation (or match the 7432-W switch in the back end case). 7433 7434The second usage is to suppress a warning locally, and in this case, two 7435pragmas must appear in sequence: 7436 7437 7438.. code-block:: ada 7439 7440 pragma Warnings (Off, Pattern); 7441 ... code where given warning is to be suppressed 7442 pragma Warnings (On, Pattern); 7443 7444 7445In this usage, the pattern string must match in the Off and On 7446pragmas, and (if *-gnatw.w* is given) at least one matching 7447warning must be suppressed. 7448 7449Note: to write a string that will match any warning, use the string 7450``"***"``. It will not work to use a single asterisk or two 7451asterisks since this looks like an operator name. This form with three 7452asterisks is similar in effect to specifying ``pragma Warnings (Off)`` except (if :switch:`-gnatw.w` is given) that a matching 7453``pragma Warnings (On, "***")`` will be required. This can be 7454helpful in avoiding forgetting to turn warnings back on. 7455 7456Note: the debug flag :switch:`-gnatd.i` (``/NOWARNINGS_PRAGMAS`` in VMS) can be 7457used to cause the compiler to entirely ignore all WARNINGS pragmas. This can 7458be useful in checking whether obsolete pragmas in existing programs are hiding 7459real problems. 7460 7461Note: pragma Warnings does not affect the processing of style messages. See 7462separate entry for pragma Style_Checks for control of style messages. 7463 7464Users of the formal verification tool GNATprove for the SPARK subset of Ada may 7465use the version of the pragma with a ``TOOL_NAME`` parameter. 7466 7467If present, ``TOOL_NAME`` is the name of a tool, currently either ``GNAT`` for the 7468compiler or ``GNATprove`` for the formal verification tool. A given tool only 7469takes into account pragma Warnings that do not specify a tool name, or that 7470specify the matching tool name. This makes it possible to disable warnings 7471selectively for each tool, and as a consequence to detect useless pragma 7472Warnings with switch :switch:`-gnatw.w`. 7473 7474Pragma Weak_External 7475==================== 7476 7477Syntax: 7478 7479 7480.. code-block:: ada 7481 7482 pragma Weak_External ([Entity =>] LOCAL_NAME); 7483 7484 7485``LOCAL_NAME`` must refer to an object that is declared at the library 7486level. This pragma specifies that the given entity should be marked as a 7487weak symbol for the linker. It is equivalent to ``__attribute__((weak))`` 7488in GNU C and causes ``LOCAL_NAME`` to be emitted as a weak symbol instead 7489of a regular symbol, that is to say a symbol that does not have to be 7490resolved by the linker if used in conjunction with a pragma Import. 7491 7492When a weak symbol is not resolved by the linker, its address is set to 7493zero. This is useful in writing interfaces to external modules that may 7494or may not be linked in the final executable, for example depending on 7495configuration settings. 7496 7497If a program references at run time an entity to which this pragma has been 7498applied, and the corresponding symbol was not resolved at link time, then 7499the execution of the program is erroneous. It is not erroneous to take the 7500Address of such an entity, for example to guard potential references, 7501as shown in the example below. 7502 7503Some file formats do not support weak symbols so not all target machines 7504support this pragma. 7505 7506 7507.. code-block:: ada 7508 7509 -- Example of the use of pragma Weak_External 7510 7511 package External_Module is 7512 key : Integer; 7513 pragma Import (C, key); 7514 pragma Weak_External (key); 7515 function Present return boolean; 7516 end External_Module; 7517 7518 with System; use System; 7519 package body External_Module is 7520 function Present return boolean is 7521 begin 7522 return key'Address /= System.Null_Address; 7523 end Present; 7524 end External_Module; 7525 7526 7527Pragma Wide_Character_Encoding 7528============================== 7529 7530Syntax: 7531 7532 7533.. code-block:: ada 7534 7535 pragma Wide_Character_Encoding (IDENTIFIER | CHARACTER_LITERAL); 7536 7537 7538This pragma specifies the wide character encoding to be used in program 7539source text appearing subsequently. It is a configuration pragma, but may 7540also be used at any point that a pragma is allowed, and it is permissible 7541to have more than one such pragma in a file, allowing multiple encodings 7542to appear within the same file. 7543 7544However, note that the pragma cannot immediately precede the relevant 7545wide character, because then the previous encoding will still be in 7546effect, causing "illegal character" errors. 7547 7548The argument can be an identifier or a character literal. In the identifier 7549case, it is one of ``HEX``, ``UPPER``, ``SHIFT_JIS``, 7550``EUC``, ``UTF8``, or ``BRACKETS``. In the character literal 7551case it is correspondingly one of the characters :kbd:`h`, :kbd:`u`, 7552:kbd:`s`, :kbd:`e`, :kbd:`8`, or :kbd:`b`. 7553 7554Note that when the pragma is used within a file, it affects only the 7555encoding within that file, and does not affect withed units, specs, 7556or subunits. 7557