1.. _Implementation_Defined_Characteristics: 2 3************************************** 4Implementation Defined Characteristics 5************************************** 6 7In addition to the implementation dependent pragmas and attributes, and the 8implementation advice, there are a number of other Ada features that are 9potentially implementation dependent and are designated as 10implementation-defined. These are mentioned throughout the Ada Reference 11Manual, and are summarized in Annex M. 12 13A requirement for conforming Ada compilers is that they provide 14documentation describing how the implementation deals with each of these 15issues. In this chapter you will find each point in Annex M listed, 16followed by a description of how GNAT 17handles the implementation dependence. 18 19You can use this chapter as a guide to minimizing implementation 20dependent features in your programs if portability to other compilers 21and other operating systems is an important consideration. The numbers 22in each entry below correspond to the paragraph numbers in the Ada 23Reference Manual. 24 25* 26 "Whether or not each recommendation given in Implementation 27 Advice is followed. See 1.1.2(37)." 28 29See :ref:`Implementation_Advice`. 30 31* 32 "Capacity limitations of the implementation. See 1.1.3(3)." 33 34The complexity of programs that can be processed is limited only by the 35total amount of available virtual memory, and disk space for the 36generated object files. 37 38* 39 "Variations from the standard that are impractical to avoid 40 given the implementation's execution environment. See 1.1.3(6)." 41 42There are no variations from the standard. 43 44* 45 "Which code_statements cause external 46 interactions. See 1.1.3(10)." 47 48Any *code_statement* can potentially cause external interactions. 49 50* 51 "The coded representation for the text of an Ada 52 program. See 2.1(4)." 53 54See separate section on source representation. 55 56* 57 "The control functions allowed in comments. See 2.1(14)." 58 59See separate section on source representation. 60 61* 62 "The representation for an end of line. See 2.2(2)." 63 64See separate section on source representation. 65 66* 67 "Maximum supported line length and lexical element 68 length. See 2.2(15)." 69 70The maximum line length is 255 characters and the maximum length of 71a lexical element is also 255 characters. This is the default setting 72if not overridden by the use of compiler switch *-gnaty* (which 73sets the maximum to 79) or *-gnatyMnn* which allows the maximum 74line length to be specified to be any value up to 32767. The maximum 75length of a lexical element is the same as the maximum line length. 76 77* 78 "Implementation defined pragmas. See 2.8(14)." 79 80See :ref:`Implementation_Defined_Pragmas`. 81 82* 83 "Effect of pragma ``Optimize``. See 2.8(27)." 84 85Pragma ``Optimize``, if given with a ``Time`` or ``Space`` 86parameter, checks that the optimization flag is set, and aborts if it is 87not. 88 89* 90 "The sequence of characters of the value returned by 91 ``S'Image`` when some of the graphic characters of 92 ``S'Wide_Image`` are not defined in ``Character``. See 93 3.5(37)." 94 95The sequence of characters is as defined by the wide character encoding 96method used for the source. See section on source representation for 97further details. 98 99* 100 "The predefined integer types declared in 101 ``Standard``. See 3.5.4(25)." 102 103====================== ======================================= 104Type Representation 105====================== ======================================= 106*Short_Short_Integer* 8 bit signed 107*Short_Integer* (Short) 16 bit signed 108*Integer* 32 bit signed 109*Long_Integer* 64 bit signed (on most 64 bit targets, 110 depending on the C definition of long). 111 32 bit signed (all other targets) 112*Long_Long_Integer* 64 bit signed 113====================== ======================================= 114 115* 116 "Any nonstandard integer types and the operators defined 117 for them. See 3.5.4(26)." 118 119There are no nonstandard integer types. 120 121* 122 "Any nonstandard real types and the operators defined for 123 them. See 3.5.6(8)." 124 125There are no nonstandard real types. 126 127* 128 "What combinations of requested decimal precision and range 129 are supported for floating point types. See 3.5.7(7)." 130 131The precision and range is as defined by the IEEE standard. 132 133* 134 "The predefined floating point types declared in 135 ``Standard``. See 3.5.7(16)." 136 137====================== ==================================================== 138Type Representation 139====================== ==================================================== 140*Short_Float* 32 bit IEEE short 141*Float* (Short) 32 bit IEEE short 142*Long_Float* 64 bit IEEE long 143*Long_Long_Float* 64 bit IEEE long (80 bit IEEE long on x86 processors) 144====================== ==================================================== 145 146* 147 "The small of an ordinary fixed point type. See 3.5.9(8)." 148 149``Fine_Delta`` is 2**(-63) 150 151* 152 "What combinations of small, range, and digits are 153 supported for fixed point types. See 3.5.9(10)." 154 155Any combinations are permitted that do not result in a small less than 156``Fine_Delta`` and do not result in a mantissa larger than 63 bits. 157If the mantissa is larger than 53 bits on machines where Long_Long_Float 158is 64 bits (true of all architectures except ia32), then the output from 159Text_IO is accurate to only 53 bits, rather than the full mantissa. This 160is because floating-point conversions are used to convert fixed point. 161 162 163* 164 "The result of ``Tags.Expanded_Name`` for types declared 165 within an unnamed *block_statement*. See 3.9(10)." 166 167Block numbers of the form :samp:`B{nnn}`, where *nnn* is a 168decimal integer are allocated. 169 170* 171 "Implementation-defined attributes. See 4.1.4(12)." 172 173See :ref:`Implementation_Defined_Attributes`. 174 175* 176 "Any implementation-defined time types. See 9.6(6)." 177 178There are no implementation-defined time types. 179 180* 181 "The time base associated with relative delays." 182 183See 9.6(20). The time base used is that provided by the C library 184function ``gettimeofday``. 185 186* 187 "The time base of the type ``Calendar.Time``. See 188 9.6(23)." 189 190The time base used is that provided by the C library function 191``gettimeofday``. 192 193* 194 "The time zone used for package ``Calendar`` 195 operations. See 9.6(24)." 196 197The time zone used by package ``Calendar`` is the current system time zone 198setting for local time, as accessed by the C library function 199``localtime``. 200 201* 202 "Any limit on *delay_until_statements* of 203 *select_statements*. See 9.6(29)." 204 205There are no such limits. 206 207* 208 "Whether or not two non-overlapping parts of a composite 209 object are independently addressable, in the case where packing, record 210 layout, or ``Component_Size`` is specified for the object. See 211 9.10(1)." 212 213Separate components are independently addressable if they do not share 214overlapping storage units. 215 216* 217 "The representation for a compilation. See 10.1(2)." 218 219A compilation is represented by a sequence of files presented to the 220compiler in a single invocation of the *gcc* command. 221 222* 223 "Any restrictions on compilations that contain multiple 224 compilation_units. See 10.1(4)." 225 226No single file can contain more than one compilation unit, but any 227sequence of files can be presented to the compiler as a single 228compilation. 229 230* 231 "The mechanisms for creating an environment and for adding 232 and replacing compilation units. See 10.1.4(3)." 233 234See separate section on compilation model. 235 236* 237 "The manner of explicitly assigning library units to a 238 partition. See 10.2(2)." 239 240If a unit contains an Ada main program, then the Ada units for the partition 241are determined by recursive application of the rules in the Ada Reference 242Manual section 10.2(2-6). In other words, the Ada units will be those that 243are needed by the main program, and then this definition of need is applied 244recursively to those units, and the partition contains the transitive 245closure determined by this relationship. In short, all the necessary units 246are included, with no need to explicitly specify the list. If additional 247units are required, e.g., by foreign language units, then all units must be 248mentioned in the context clause of one of the needed Ada units. 249 250If the partition contains no main program, or if the main program is in 251a language other than Ada, then GNAT 252provides the binder options *-z* and *-n* respectively, and in 253this case a list of units can be explicitly supplied to the binder for 254inclusion in the partition (all units needed by these units will also 255be included automatically). For full details on the use of these 256options, refer to *GNAT Make Program gnatmake* in the 257:title:`GNAT User's Guide`. 258 259* 260 "The implementation-defined means, if any, of specifying 261 which compilation units are needed by a given compilation unit. See 262 10.2(2)." 263 264The units needed by a given compilation unit are as defined in 265the Ada Reference Manual section 10.2(2-6). There are no 266implementation-defined pragmas or other implementation-defined 267means for specifying needed units. 268 269* 270 "The manner of designating the main subprogram of a 271 partition. See 10.2(7)." 272 273The main program is designated by providing the name of the 274corresponding :file:`ALI` file as the input parameter to the binder. 275 276* 277 "The order of elaboration of *library_items*. See 278 10.2(18)." 279 280The first constraint on ordering is that it meets the requirements of 281Chapter 10 of the Ada Reference Manual. This still leaves some 282implementation dependent choices, which are resolved by first 283elaborating bodies as early as possible (i.e., in preference to specs 284where there is a choice), and second by evaluating the immediate with 285clauses of a unit to determine the probably best choice, and 286third by elaborating in alphabetical order of unit names 287where a choice still remains. 288 289* 290 "Parameter passing and function return for the main 291 subprogram. See 10.2(21)." 292 293The main program has no parameters. It may be a procedure, or a function 294returning an integer type. In the latter case, the returned integer 295value is the return code of the program (overriding any value that 296may have been set by a call to ``Ada.Command_Line.Set_Exit_Status``). 297 298* 299 "The mechanisms for building and running partitions. See 300 10.2(24)." 301 302GNAT itself supports programs with only a single partition. The GNATDIST 303tool provided with the GLADE package (which also includes an implementation 304of the PCS) provides a completely flexible method for building and running 305programs consisting of multiple partitions. See the separate GLADE manual 306for details. 307 308* 309 "The details of program execution, including program 310 termination. See 10.2(25)." 311 312See separate section on compilation model. 313 314* 315 "The semantics of any non-active partitions supported by the 316 implementation. See 10.2(28)." 317 318Passive partitions are supported on targets where shared memory is 319provided by the operating system. See the GLADE reference manual for 320further details. 321 322* 323 "The information returned by ``Exception_Message``. See 324 11.4.1(10)." 325 326Exception message returns the null string unless a specific message has 327been passed by the program. 328 329* 330 "The result of ``Exceptions.Exception_Name`` for types 331 declared within an unnamed *block_statement*. See 11.4.1(12)." 332 333Blocks have implementation defined names of the form :samp:`B{nnn}` 334where *nnn* is an integer. 335 336* 337 "The information returned by 338 ``Exception_Information``. See 11.4.1(13)." 339 340``Exception_Information`` returns a string in the following format:: 341 342 *Exception_Name:* nnnnn 343 *Message:* mmmmm 344 *PID:* ppp 345 *Load address:* 0xhhhh 346 *Call stack traceback locations:* 347 0xhhhh 0xhhhh 0xhhhh ... 0xhhh 348 349where 350 351 * ``nnnn`` is the fully qualified name of the exception in all upper 352 case letters. This line is always present. 353 354 * ``mmmm`` is the message (this line present only if message is non-null) 355 356 * ``ppp`` is the Process Id value as a decimal integer (this line is 357 present only if the Process Id is nonzero). Currently we are 358 not making use of this field. 359 360 * The Load address line, the Call stack traceback locations line and the 361 following values are present only if at least one traceback location was 362 recorded. The Load address indicates the address at which the main executable 363 was loaded; this line may not be present if operating system hasn't relocated 364 the main executable. The values are given in C style format, with lower case 365 letters for a-f, and only as many digits present as are necessary. 366 The line terminator sequence at the end of each line, including 367 the last line is a single ``LF`` character (``16#0A#``). 368 369* 370 "Implementation-defined check names. See 11.5(27)." 371 372The implementation defined check names include Alignment_Check, 373Atomic_Synchronization, Duplicated_Tag_Check, Container_Checks, 374Tampering_Check, Predicate_Check, and Validity_Check. In addition, a user 375program can add implementation-defined check names by means of the pragma 376Check_Name. See the description of pragma ``Suppress`` for full details. 377 378* 379 "The interpretation of each aspect of representation. See 380 13.1(20)." 381 382See separate section on data representations. 383 384* 385 "Any restrictions placed upon representation items. See 386 13.1(20)." 387 388See separate section on data representations. 389 390* 391 "The meaning of ``Size`` for indefinite subtypes. See 392 13.3(48)." 393 394Size for an indefinite subtype is the maximum possible size, except that 395for the case of a subprogram parameter, the size of the parameter object 396is the actual size. 397 398* 399 "The default external representation for a type tag. See 400 13.3(75)." 401 402The default external representation for a type tag is the fully expanded 403name of the type in upper case letters. 404 405* 406 "What determines whether a compilation unit is the same in 407 two different partitions. See 13.3(76)." 408 409A compilation unit is the same in two different partitions if and only 410if it derives from the same source file. 411 412* 413 "Implementation-defined components. See 13.5.1(15)." 414 415The only implementation defined component is the tag for a tagged type, 416which contains a pointer to the dispatching table. 417 418* 419 "If ``Word_Size`` = ``Storage_Unit``, the default bit 420 ordering. See 13.5.3(5)." 421 422``Word_Size`` (32) is not the same as ``Storage_Unit`` (8) for this 423implementation, so no non-default bit ordering is supported. The default 424bit ordering corresponds to the natural endianness of the target architecture. 425 426* 427 "The contents of the visible part of package ``System`` 428 and its language-defined children. See 13.7(2)." 429 430See the definition of these packages in files :file:`system.ads` and 431:file:`s-stoele.ads`. Note that two declarations are added to package 432System. 433 434.. code-block:: ada 435 436 Max_Priority : constant Positive := Priority'Last; 437 Max_Interrupt_Priority : constant Positive := Interrupt_Priority'Last; 438 439* 440 "The contents of the visible part of package 441 ``System.Machine_Code``, and the meaning of 442 *code_statements*. See 13.8(7)." 443 444See the definition and documentation in file :file:`s-maccod.ads`. 445 446* 447 "The effect of unchecked conversion. See 13.9(11)." 448 449Unchecked conversion between types of the same size 450results in an uninterpreted transmission of the bits from one type 451to the other. If the types are of unequal sizes, then in the case of 452discrete types, a shorter source is first zero or sign extended as 453necessary, and a shorter target is simply truncated on the left. 454For all non-discrete types, the source is first copied if necessary 455to ensure that the alignment requirements of the target are met, then 456a pointer is constructed to the source value, and the result is obtained 457by dereferencing this pointer after converting it to be a pointer to the 458target type. Unchecked conversions where the target subtype is an 459unconstrained array are not permitted. If the target alignment is 460greater than the source alignment, then a copy of the result is 461made with appropriate alignment 462 463* 464 "The semantics of operations on invalid representations. 465 See 13.9.2(10-11)." 466 467For assignments and other operations where the use of invalid values cannot 468result in erroneous behavior, the compiler ignores the possibility of invalid 469values. An exception is raised at the point where an invalid value would 470result in erroneous behavior. For example executing: 471 472.. code-block:: ada 473 474 procedure invalidvals is 475 X : Integer := -1; 476 Y : Natural range 1 .. 10; 477 for Y'Address use X'Address; 478 Z : Natural range 1 .. 10; 479 A : array (Natural range 1 .. 10) of Integer; 480 begin 481 Z := Y; -- no exception 482 A (Z) := 3; -- exception raised; 483 end; 484 485As indicated, an exception is raised on the array assignment, but not 486on the simple assignment of the invalid negative value from Y to Z. 487 488* 489 "The manner of choosing a storage pool for an access type 490 when ``Storage_Pool`` is not specified for the type. See 13.11(17)." 491 492There are 3 different standard pools used by the compiler when 493``Storage_Pool`` is not specified depending whether the type is local 494to a subprogram or defined at the library level and whether 495``Storage_Size``is specified or not. See documentation in the runtime 496library units ``System.Pool_Global``, ``System.Pool_Size`` and 497``System.Pool_Local`` in files :file:`s-poosiz.ads`, 498:file:`s-pooglo.ads` and :file:`s-pooloc.ads` for full details on the 499default pools used. 500 501* 502 "Whether or not the implementation provides user-accessible 503 names for the standard pool type(s). See 13.11(17)." 504 505See documentation in the sources of the run time mentioned in the previous 506paragraph. All these pools are accessible by means of `with`\ ing 507these units. 508 509* 510 "The meaning of ``Storage_Size``. See 13.11(18)." 511 512``Storage_Size`` is measured in storage units, and refers to the 513total space available for an access type collection, or to the primary 514stack space for a task. 515 516* 517 "Implementation-defined aspects of storage pools. See 518 13.11(22)." 519 520See documentation in the sources of the run time mentioned in the 521paragraph about standard storage pools above 522for details on GNAT-defined aspects of storage pools. 523 524* 525 "The set of restrictions allowed in a pragma 526 ``Restrictions``. See 13.12(7)." 527 528See :ref:`Standard_and_Implementation_Defined_Restrictions`. 529 530* 531 "The consequences of violating limitations on 532 ``Restrictions`` pragmas. See 13.12(9)." 533 534Restrictions that can be checked at compile time result in illegalities 535if violated. Currently there are no other consequences of violating 536restrictions. 537 538* 539 "The representation used by the ``Read`` and 540 ``Write`` attributes of elementary types in terms of stream 541 elements. See 13.13.2(9)." 542 543The representation is the in-memory representation of the base type of 544the type, using the number of bits corresponding to the 545``type'Size`` value, and the natural ordering of the machine. 546 547* 548 "The names and characteristics of the numeric subtypes 549 declared in the visible part of package ``Standard``. See A.1(3)." 550 551See items describing the integer and floating-point types supported. 552 553* 554 "The string returned by ``Character_Set_Version``. 555 See A.3.5(3)." 556 557``Ada.Wide_Characters.Handling.Character_Set_Version`` returns 558the string "Unicode 4.0", referring to version 4.0 of the 559Unicode specification. 560 561* 562 "The accuracy actually achieved by the elementary 563 functions. See A.5.1(1)." 564 565The elementary functions correspond to the functions available in the C 566library. Only fast math mode is implemented. 567 568* 569 "The sign of a zero result from some of the operators or 570 functions in ``Numerics.Generic_Elementary_Functions``, when 571 ``Float_Type'Signed_Zeros`` is ``True``. See A.5.1(46)." 572 573The sign of zeroes follows the requirements of the IEEE 754 standard on 574floating-point. 575 576* 577 "The value of 578 ``Numerics.Float_Random.Max_Image_Width``. See A.5.2(27)." 579 580Maximum image width is 6864, see library file :file:`s-rannum.ads`. 581 582* 583 "The value of 584 ``Numerics.Discrete_Random.Max_Image_Width``. See A.5.2(27)." 585 586Maximum image width is 6864, see library file :file:`s-rannum.ads`. 587 588* 589 "The algorithms for random number generation. See 590 A.5.2(32)." 591 592The algorithm is the Mersenne Twister, as documented in the source file 593:file:`s-rannum.adb`. This version of the algorithm has a period of 5942**19937-1. 595 596* 597 "The string representation of a random number generator's 598 state. See A.5.2(38)." 599 600The value returned by the Image function is the concatenation of 601the fixed-width decimal representations of the 624 32-bit integers 602of the state vector. 603 604* 605 "The minimum time interval between calls to the 606 time-dependent Reset procedure that are guaranteed to initiate different 607 random number sequences. See A.5.2(45)." 608 609The minimum period between reset calls to guarantee distinct series of 610random numbers is one microsecond. 611 612* 613 "The values of the ``Model_Mantissa``, 614 ``Model_Emin``, ``Model_Epsilon``, ``Model``, 615 ``Safe_First``, and ``Safe_Last`` attributes, if the Numerics 616 Annex is not supported. See A.5.3(72)." 617 618Run the compiler with *-gnatS* to produce a listing of package 619``Standard``, has the values of all numeric attributes. 620 621* 622 "Any implementation-defined characteristics of the 623 input-output packages. See A.7(14)." 624 625There are no special implementation defined characteristics for these 626packages. 627 628* 629 "The value of ``Buffer_Size`` in ``Storage_IO``. See 630 A.9(10)." 631 632All type representations are contiguous, and the ``Buffer_Size`` is 633the value of ``type'Size`` rounded up to the next storage unit 634boundary. 635 636* 637 "External files for standard input, standard output, and 638 standard error See A.10(5)." 639 640These files are mapped onto the files provided by the C streams 641libraries. See source file :file:`i-cstrea.ads` for further details. 642 643* 644 "The accuracy of the value produced by ``Put``. See 645 A.10.9(36)." 646 647If more digits are requested in the output than are represented by the 648precision of the value, zeroes are output in the corresponding least 649significant digit positions. 650 651* 652 "The meaning of ``Argument_Count``, ``Argument``, and 653 ``Command_Name``. See A.15(1)." 654 655These are mapped onto the ``argv`` and ``argc`` parameters of the 656main program in the natural manner. 657 658* 659 "The interpretation of the ``Form`` parameter in procedure 660 ``Create_Directory``. See A.16(56)." 661 662The ``Form`` parameter is not used. 663 664* 665 "The interpretation of the ``Form`` parameter in procedure 666 ``Create_Path``. See A.16(60)." 667 668The ``Form`` parameter is not used. 669 670* 671 "The interpretation of the ``Form`` parameter in procedure 672 ``Copy_File``. See A.16(68)." 673 674The ``Form`` parameter is case-insensitive. 675Two fields are recognized in the ``Form`` parameter:: 676 677 *preserve=<value>* 678 *mode=<value>* 679 680<value> starts immediately after the character '=' and ends with the 681character immediately preceding the next comma (',') or with the last 682character of the parameter. 683 684The only possible values for preserve= are: 685 686================== =================================================================== 687Value Meaning 688================== =================================================================== 689*no_attributes* Do not try to preserve any file attributes. This is the 690 default if no preserve= is found in Form. 691*all_attributes* Try to preserve all file attributes (timestamps, access rights). 692*timestamps* Preserve the timestamp of the copied file, but not the other 693 file attributes. 694================== =================================================================== 695 696The only possible values for mode= are: 697 698============== =============================================================================== 699Value Meaning 700============== =============================================================================== 701*copy* Only do the copy if the destination file does not already exist. 702 If it already exists, Copy_File fails. 703*overwrite* Copy the file in all cases. Overwrite an already existing destination file. 704*append* Append the original file to the destination file. If the destination file 705 does not exist, the destination file is a copy of the source file. 706 When mode=append, the field preserve=, if it exists, is not taken into account. 707============== =============================================================================== 708 709If the Form parameter includes one or both of the fields and the value or 710values are incorrect, Copy_file fails with Use_Error. 711 712Examples of correct Forms:: 713 714 Form => "preserve=no_attributes,mode=overwrite" (the default) 715 Form => "mode=append" 716 Form => "mode=copy, preserve=all_attributes" 717 718Examples of incorrect Forms:: 719 720 Form => "preserve=junk" 721 Form => "mode=internal, preserve=timestamps" 722 723* 724 "The interpretation of the ``Pattern`` parameter, when not the null string, 725 in the ``Start_Search`` and ``Search`` procedures. 726 See A.16(104) and A.16(112)." 727 728When the ``Pattern`` parameter is not the null string, it is interpreted 729according to the syntax of regular expressions as defined in the 730``GNAT.Regexp`` package. 731 732See :ref:`GNAT.Regexp_(g-regexp.ads)`. 733 734* 735 "Implementation-defined convention names. See B.1(11)." 736 737The following convention names are supported 738 739======================= ============================================================================== 740Convention Name Interpretation 741======================= ============================================================================== 742*Ada* Ada 743*Ada_Pass_By_Copy* Allowed for any types except by-reference types such as limited 744 records. Compatible with convention Ada, but causes any parameters 745 with this convention to be passed by copy. 746*Ada_Pass_By_Reference* Allowed for any types except by-copy types such as scalars. 747 Compatible with convention Ada, but causes any parameters 748 with this convention to be passed by reference. 749*Assembler* Assembly language 750*Asm* Synonym for Assembler 751*Assembly* Synonym for Assembler 752*C* C 753*C_Pass_By_Copy* Allowed only for record types, like C, but also notes that record 754 is to be passed by copy rather than reference. 755*COBOL* COBOL 756*C_Plus_Plus (or CPP)* C++ 757*Default* Treated the same as C 758*External* Treated the same as C 759*Fortran* Fortran 760*Intrinsic* For support of pragma ``Import`` with convention Intrinsic, see 761 separate section on Intrinsic Subprograms. 762*Stdcall* Stdcall (used for Windows implementations only). This convention correspond 763 to the WINAPI (previously called Pascal convention) C/C++ convention under 764 Windows. A routine with this convention cleans the stack before 765 exit. This pragma cannot be applied to a dispatching call. 766*DLL* Synonym for Stdcall 767*Win32* Synonym for Stdcall 768*Stubbed* Stubbed is a special convention used to indicate that the body of the 769 subprogram will be entirely ignored. Any call to the subprogram 770 is converted into a raise of the ``Program_Error`` exception. If a 771 pragma ``Import`` specifies convention ``stubbed`` then no body need 772 be present at all. This convention is useful during development for the 773 inclusion of subprograms whose body has not yet been written. 774 In addition, all otherwise unrecognized convention names are also 775 treated as being synonymous with convention C. In all implementations 776 except for VMS, use of such other names results in a warning. In VMS 777 implementations, these names are accepted silently. 778======================= ============================================================================== 779 780* 781 "The meaning of link names. See B.1(36)." 782 783Link names are the actual names used by the linker. 784 785* 786 "The manner of choosing link names when neither the link 787 name nor the address of an imported or exported entity is specified. See 788 B.1(36)." 789 790The default linker name is that which would be assigned by the relevant 791external language, interpreting the Ada name as being in all lower case 792letters. 793 794* 795 "The effect of pragma ``Linker_Options``. See B.1(37)." 796 797The string passed to ``Linker_Options`` is presented uninterpreted as 798an argument to the link command, unless it contains ASCII.NUL characters. 799NUL characters if they appear act as argument separators, so for example 800 801.. code-block:: ada 802 803 pragma Linker_Options ("-labc" & ASCII.NUL & "-ldef"); 804 805causes two separate arguments ``-labc`` and ``-ldef`` to be passed to the 806linker. The order of linker options is preserved for a given unit. The final 807list of options passed to the linker is in reverse order of the elaboration 808order. For example, linker options for a body always appear before the options 809from the corresponding package spec. 810 811* 812 "The contents of the visible part of package 813 ``Interfaces`` and its language-defined descendants. See B.2(1)." 814 815See files with prefix :file:`i-` in the distributed library. 816 817* 818 "Implementation-defined children of package 819 ``Interfaces``. The contents of the visible part of package 820 ``Interfaces``. See B.2(11)." 821 822See files with prefix :file:`i-` in the distributed library. 823 824* 825 "The types ``Floating``, ``Long_Floating``, 826 ``Binary``, ``Long_Binary``, ``Decimal_ Element``, and 827 ``COBOL_Character``; and the initialization of the variables 828 ``Ada_To_COBOL`` and ``COBOL_To_Ada``, in 829 ``Interfaces.COBOL``. See B.4(50)." 830 831===================== ==================================== 832COBOL Ada 833===================== ==================================== 834*Floating* Float 835*Long_Floating* (Floating) Long_Float 836*Binary* Integer 837*Long_Binary* Long_Long_Integer 838*Decimal_Element* Character 839*COBOL_Character* Character 840===================== ==================================== 841 842For initialization, see the file :file:`i-cobol.ads` in the distributed library. 843 844* 845 "Support for access to machine instructions. See C.1(1)." 846 847See documentation in file :file:`s-maccod.ads` in the distributed library. 848 849* 850 "Implementation-defined aspects of access to machine 851 operations. See C.1(9)." 852 853See documentation in file :file:`s-maccod.ads` in the distributed library. 854 855* 856 "Implementation-defined aspects of interrupts. See C.3(2)." 857 858Interrupts are mapped to signals or conditions as appropriate. See 859definition of unit 860``Ada.Interrupt_Names`` in source file :file:`a-intnam.ads` for details 861on the interrupts supported on a particular target. 862 863* 864 "Implementation-defined aspects of pre-elaboration. See 865 C.4(13)." 866 867GNAT does not permit a partition to be restarted without reloading, 868except under control of the debugger. 869 870* 871 "The semantics of pragma ``Discard_Names``. See C.5(7)." 872 873Pragma ``Discard_Names`` causes names of enumeration literals to 874be suppressed. In the presence of this pragma, the Image attribute 875provides the image of the Pos of the literal, and Value accepts 876Pos values. 877 878* 879 "The result of the ``Task_Identification.Image`` 880 attribute. See C.7.1(7)." 881 882The result of this attribute is a string that identifies 883the object or component that denotes a given task. If a variable ``Var`` 884has a task type, the image for this task will have the form :samp:`Var_{XXXXXXXX}`, 885where the suffix *XXXXXXXX* 886is the hexadecimal representation of the virtual address of the corresponding 887task control block. If the variable is an array of tasks, the image of each 888task will have the form of an indexed component indicating the position of a 889given task in the array, e.g., :samp:`Group(5)_{XXXXXXX}`. If the task is a 890component of a record, the image of the task will have the form of a selected 891component. These rules are fully recursive, so that the image of a task that 892is a subcomponent of a composite object corresponds to the expression that 893designates this task. 894 895If a task is created by an allocator, its image depends on the context. If the 896allocator is part of an object declaration, the rules described above are used 897to construct its image, and this image is not affected by subsequent 898assignments. If the allocator appears within an expression, the image 899includes only the name of the task type. 900 901If the configuration pragma Discard_Names is present, or if the restriction 902No_Implicit_Heap_Allocation is in effect, the image reduces to 903the numeric suffix, that is to say the hexadecimal representation of the 904virtual address of the control block of the task. 905 906* 907 "The value of ``Current_Task`` when in a protected entry 908 or interrupt handler. See C.7.1(17)." 909 910Protected entries or interrupt handlers can be executed by any 911convenient thread, so the value of ``Current_Task`` is undefined. 912 913* 914 "The effect of calling ``Current_Task`` from an entry 915 body or interrupt handler. See C.7.1(19)." 916 917When GNAT can determine statically that ``Current_Task`` is called directly in 918the body of an entry (or barrier) then a warning is emitted and ``Program_Error`` 919is raised at run time. Otherwise, the effect of calling ``Current_Task`` from an 920entry body or interrupt handler is to return the identification of the task 921currently executing the code. 922 923* 924 "Implementation-defined aspects of 925 ``Task_Attributes``. See C.7.2(19)." 926 927There are no implementation-defined aspects of ``Task_Attributes``. 928 929* 930 "Values of all ``Metrics``. See D(2)." 931 932The metrics information for GNAT depends on the performance of the 933underlying operating system. The sources of the run-time for tasking 934implementation, together with the output from *-gnatG* can be 935used to determine the exact sequence of operating systems calls made 936to implement various tasking constructs. Together with appropriate 937information on the performance of the underlying operating system, 938on the exact target in use, this information can be used to determine 939the required metrics. 940 941* 942 "The declarations of ``Any_Priority`` and 943 ``Priority``. See D.1(11)." 944 945See declarations in file :file:`system.ads`. 946 947* 948 "Implementation-defined execution resources. See D.1(15)." 949 950There are no implementation-defined execution resources. 951 952* 953 "Whether, on a multiprocessor, a task that is waiting for 954 access to a protected object keeps its processor busy. See D.2.1(3)." 955 956On a multi-processor, a task that is waiting for access to a protected 957object does not keep its processor busy. 958 959* 960 "The affect of implementation defined execution resources 961 on task dispatching. See D.2.1(9)." 962 963Tasks map to threads in the threads package used by GNAT. Where possible 964and appropriate, these threads correspond to native threads of the 965underlying operating system. 966 967* 968 "Implementation-defined *policy_identifiers* allowed 969 in a pragma ``Task_Dispatching_Policy``. See D.2.2(3)." 970 971There are no implementation-defined policy-identifiers allowed in this 972pragma. 973 974* 975 "Implementation-defined aspects of priority inversion. See 976 D.2.2(16)." 977 978Execution of a task cannot be preempted by the implementation processing 979of delay expirations for lower priority tasks. 980 981* 982 "Implementation-defined task dispatching. See D.2.2(18)." 983 984The policy is the same as that of the underlying threads implementation. 985 986* 987 "Implementation-defined *policy_identifiers* allowed 988 in a pragma ``Locking_Policy``. See D.3(4)." 989 990The two implementation defined policies permitted in GNAT are 991``Inheritance_Locking`` and ``Concurrent_Readers_Locking``. On 992targets that support the ``Inheritance_Locking`` policy, locking is 993implemented by inheritance, i.e., the task owning the lock operates 994at a priority equal to the highest priority of any task currently 995requesting the lock. On targets that support the 996``Concurrent_Readers_Locking`` policy, locking is implemented with a 997read/write lock allowing multiple protected object functions to enter 998concurrently. 999 1000* 1001 "Default ceiling priorities. See D.3(10)." 1002 1003The ceiling priority of protected objects of the type 1004``System.Interrupt_Priority'Last`` as described in the Ada 1005Reference Manual D.3(10), 1006 1007* 1008 "The ceiling of any protected object used internally by 1009 the implementation. See D.3(16)." 1010 1011The ceiling priority of internal protected objects is 1012``System.Priority'Last``. 1013 1014* 1015 "Implementation-defined queuing policies. See D.4(1)." 1016 1017There are no implementation-defined queuing policies. 1018 1019* 1020 "On a multiprocessor, any conditions that cause the 1021 completion of an aborted construct to be delayed later than what is 1022 specified for a single processor. See D.6(3)." 1023 1024The semantics for abort on a multi-processor is the same as on a single 1025processor, there are no further delays. 1026 1027* 1028 "Any operations that implicitly require heap storage 1029 allocation. See D.7(8)." 1030 1031The only operation that implicitly requires heap storage allocation is 1032task creation. 1033 1034* 1035 "What happens when a task terminates in the presence of 1036 pragma ``No_Task_Termination``. See D.7(15)." 1037 1038Execution is erroneous in that case. 1039 1040* 1041 "Implementation-defined aspects of pragma 1042 ``Restrictions``. See D.7(20)." 1043 1044There are no such implementation-defined aspects. 1045 1046* 1047 "Implementation-defined aspects of package 1048 ``Real_Time``. See D.8(17)." 1049 1050There are no implementation defined aspects of package ``Real_Time``. 1051 1052* 1053 "Implementation-defined aspects of 1054 *delay_statements*. See D.9(8)." 1055 1056Any difference greater than one microsecond will cause the task to be 1057delayed (see D.9(7)). 1058 1059* 1060 "The upper bound on the duration of interrupt blocking 1061 caused by the implementation. See D.12(5)." 1062 1063The upper bound is determined by the underlying operating system. In 1064no cases is it more than 10 milliseconds. 1065 1066* 1067 "The means for creating and executing distributed 1068 programs. See E(5)." 1069 1070The GLADE package provides a utility GNATDIST for creating and executing 1071distributed programs. See the GLADE reference manual for further details. 1072 1073* 1074 "Any events that can result in a partition becoming 1075 inaccessible. See E.1(7)." 1076 1077See the GLADE reference manual for full details on such events. 1078 1079* 1080 "The scheduling policies, treatment of priorities, and 1081 management of shared resources between partitions in certain cases. See 1082 E.1(11)." 1083 1084See the GLADE reference manual for full details on these aspects of 1085multi-partition execution. 1086 1087* 1088 "Events that cause the version of a compilation unit to 1089 change. See E.3(5)." 1090 1091Editing the source file of a compilation unit, or the source files of 1092any units on which it is dependent in a significant way cause the version 1093to change. No other actions cause the version number to change. All changes 1094are significant except those which affect only layout, capitalization or 1095comments. 1096 1097* 1098 "Whether the execution of the remote subprogram is 1099 immediately aborted as a result of cancellation. See E.4(13)." 1100 1101See the GLADE reference manual for details on the effect of abort in 1102a distributed application. 1103 1104* 1105 "Implementation-defined aspects of the PCS. See E.5(25)." 1106 1107See the GLADE reference manual for a full description of all implementation 1108defined aspects of the PCS. 1109 1110* 1111 "Implementation-defined interfaces in the PCS. See 1112 E.5(26)." 1113 1114See the GLADE reference manual for a full description of all 1115implementation defined interfaces. 1116 1117* 1118 "The values of named numbers in the package 1119 ``Decimal``. See F.2(7)." 1120 1121==================== ========== 1122Named Number Value 1123==================== ========== 1124*Max_Scale* +18 1125*Min_Scale* -18 1126*Min_Delta* 1.0E-18 1127*Max_Delta* 1.0E+18 1128*Max_Decimal_Digits* 18 1129==================== ========== 1130 1131* 1132 "The value of ``Max_Picture_Length`` in the package 1133 ``Text_IO.Editing``. See F.3.3(16)." 1134 113564 1136 1137* 1138 "The value of ``Max_Picture_Length`` in the package 1139 ``Wide_Text_IO.Editing``. See F.3.4(5)." 1140 114164 1142 1143* 1144 "The accuracy actually achieved by the complex elementary 1145 functions and by other complex arithmetic operations. See G.1(1)." 1146 1147Standard library functions are used for the complex arithmetic 1148operations. Only fast math mode is currently supported. 1149 1150* 1151 "The sign of a zero result (or a component thereof) from 1152 any operator or function in ``Numerics.Generic_Complex_Types``, when 1153 ``Real'Signed_Zeros`` is True. See G.1.1(53)." 1154 1155The signs of zero values are as recommended by the relevant 1156implementation advice. 1157 1158* 1159 "The sign of a zero result (or a component thereof) from 1160 any operator or function in 1161 ``Numerics.Generic_Complex_Elementary_Functions``, when 1162 ``Real'Signed_Zeros`` is ``True``. See G.1.2(45)." 1163 1164The signs of zero values are as recommended by the relevant 1165implementation advice. 1166 1167* 1168 "Whether the strict mode or the relaxed mode is the 1169 default. See G.2(2)." 1170 1171The strict mode is the default. There is no separate relaxed mode. GNAT 1172provides a highly efficient implementation of strict mode. 1173 1174* 1175 "The result interval in certain cases of fixed-to-float 1176 conversion. See G.2.1(10)." 1177 1178For cases where the result interval is implementation dependent, the 1179accuracy is that provided by performing all operations in 64-bit IEEE 1180floating-point format. 1181 1182* 1183 "The result of a floating point arithmetic operation in 1184 overflow situations, when the ``Machine_Overflows`` attribute of the 1185 result type is ``False``. See G.2.1(13)." 1186 1187Infinite and NaN values are produced as dictated by the IEEE 1188floating-point standard. 1189Note that on machines that are not fully compliant with the IEEE 1190floating-point standard, such as Alpha, the *-mieee* compiler flag 1191must be used for achieving IEEE conforming behavior (although at the cost 1192of a significant performance penalty), so infinite and NaN values are 1193properly generated. 1194 1195* 1196 "The result interval for division (or exponentiation by a 1197 negative exponent), when the floating point hardware implements division 1198 as multiplication by a reciprocal. See G.2.1(16)." 1199 1200Not relevant, division is IEEE exact. 1201 1202* 1203 "The definition of close result set, which determines the 1204 accuracy of certain fixed point multiplications and divisions. See 1205 G.2.3(5)." 1206 1207Operations in the close result set are performed using IEEE long format 1208floating-point arithmetic. The input operands are converted to 1209floating-point, the operation is done in floating-point, and the result 1210is converted to the target type. 1211 1212* 1213 "Conditions on a *universal_real* operand of a fixed 1214 point multiplication or division for which the result shall be in the 1215 perfect result set. See G.2.3(22)." 1216 1217The result is only defined to be in the perfect result set if the result 1218can be computed by a single scaling operation involving a scale factor 1219representable in 64-bits. 1220 1221* 1222 "The result of a fixed point arithmetic operation in 1223 overflow situations, when the ``Machine_Overflows`` attribute of the 1224 result type is ``False``. See G.2.3(27)." 1225 1226Not relevant, ``Machine_Overflows`` is ``True`` for fixed-point 1227types. 1228 1229* 1230 "The result of an elementary function reference in 1231 overflow situations, when the ``Machine_Overflows`` attribute of the 1232 result type is ``False``. See G.2.4(4)." 1233 1234IEEE infinite and Nan values are produced as appropriate. 1235 1236* 1237 "The value of the angle threshold, within which certain 1238 elementary functions, complex arithmetic operations, and complex 1239 elementary functions yield results conforming to a maximum relative 1240 error bound. See G.2.4(10)." 1241 1242Information on this subject is not yet available. 1243 1244* 1245 "The accuracy of certain elementary functions for 1246 parameters beyond the angle threshold. See G.2.4(10)." 1247 1248Information on this subject is not yet available. 1249 1250* 1251 "The result of a complex arithmetic operation or complex 1252 elementary function reference in overflow situations, when the 1253 ``Machine_Overflows`` attribute of the corresponding real type is 1254 ``False``. See G.2.6(5)." 1255 1256IEEE infinite and Nan values are produced as appropriate. 1257 1258* 1259 "The accuracy of certain complex arithmetic operations and 1260 certain complex elementary functions for parameters (or components 1261 thereof) beyond the angle threshold. See G.2.6(8)." 1262 1263Information on those subjects is not yet available. 1264 1265* 1266 "Information regarding bounded errors and erroneous 1267 execution. See H.2(1)." 1268 1269Information on this subject is not yet available. 1270 1271* 1272 "Implementation-defined aspects of pragma 1273 ``Inspection_Point``. See H.3.2(8)." 1274 1275Pragma ``Inspection_Point`` ensures that the variable is live and can 1276be examined by the debugger at the inspection point. 1277 1278* 1279 "Implementation-defined aspects of pragma 1280 ``Restrictions``. See H.4(25)." 1281 1282There are no implementation-defined aspects of pragma ``Restrictions``. The 1283use of pragma ``Restrictions [No_Exceptions]`` has no effect on the 1284generated code. Checks must suppressed by use of pragma ``Suppress``. 1285 1286* 1287 "Any restrictions on pragma ``Restrictions``. See 1288 H.4(27)." 1289 1290There are no restrictions on pragma ``Restrictions``. 1291