1.. _Compatibility_and_Porting_Guide: 2 3******************************* 4Compatibility and Porting Guide 5******************************* 6 7This chapter presents some guidelines for developing portable Ada code, 8describes the compatibility issues that may arise between 9GNAT and other Ada compilation systems (including those for Ada 83), 10and shows how GNAT can expedite porting 11applications developed in other Ada environments. 12 13.. _Writing_Portable_Fixed-Point_Declarations: 14 15Writing Portable Fixed-Point Declarations 16========================================= 17 18The Ada Reference Manual gives an implementation freedom to choose bounds 19that are narrower by ``Small`` from the given bounds. 20For example, if we write 21 22.. code-block:: ada 23 24 type F1 is delta 1.0 range -128.0 .. +128.0; 25 26then the implementation is allowed to choose -128.0 .. +127.0 if it 27likes, but is not required to do so. 28 29This leads to possible portability problems, so let's have a closer 30look at this, and figure out how to avoid these problems. 31 32First, why does this freedom exist, and why would an implementation 33take advantage of it? To answer this, take a closer look at the type 34declaration for ``F1`` above. If the compiler uses the given bounds, 35it would need 9 bits to hold the largest positive value (and typically 36that means 16 bits on all machines). But if the implementation chooses 37the +127.0 bound then it can fit values of the type in 8 bits. 38 39Why not make the user write +127.0 if that's what is wanted? 40The rationale is that if you are thinking of fixed point 41as a kind of 'poor man's floating-point', then you don't want 42to be thinking about the scaled integers that are used in its 43representation. Let's take another example: 44 45.. code-block:: ada 46 47 type F2 is delta 2.0**(-15) range -1.0 .. +1.0; 48 49Looking at this declaration, it seems casually as though 50it should fit in 16 bits, but again that extra positive value 51+1.0 has the scaled integer equivalent of 2**15 which is one too 52big for signed 16 bits. The implementation can treat this as: 53 54.. code-block:: ada 55 56 type F2 is delta 2.0**(-15) range -1.0 .. +1.0-(2.0**(-15)); 57 58and the Ada language design team felt that this was too annoying 59to require. We don't need to debate this decision at this point, 60since it is well established (the rule about narrowing the ranges 61dates to Ada 83). 62 63But the important point is that an implementation is not required 64to do this narrowing, so we have a potential portability problem. 65We could imagine three types of implementation: 66 67(a) those that narrow the range automatically if they can figure 68 out that the narrower range will allow storage in a smaller machine unit, 69 70(b) those that will narrow only if forced to by a ``'Size`` clause, and 71 72(c) those that will never narrow. 73 74Now if we are language theoreticians, we can imagine a fourth 75approach: to narrow all the time, e.g. to treat 76 77.. code-block:: ada 78 79 type F3 is delta 1.0 range -10.0 .. +23.0; 80 81as though it had been written: 82 83 84.. code-block:: ada 85 86 type F3 is delta 1.0 range -9.0 .. +22.0; 87 88But although technically allowed, such a behavior would be hostile and silly, 89and no real compiler would do this. All real compilers will fall into one of 90the categories (a), (b) or (c) above. 91 92So, how do you get the compiler to do what you want? The answer is give the 93actual bounds you want, and then use a ``'Small`` clause and a 94``'Size`` clause to absolutely pin down what the compiler does. 95E.g., for ``F2`` above, we will write: 96 97.. code-block:: ada 98 99 My_Small : constant := 2.0**(-15); 100 My_First : constant := -1.0; 101 My_Last : constant := +1.0 - My_Small; 102 103 type F2 is delta My_Small range My_First .. My_Last; 104 105and then add 106 107.. code-block:: ada 108 109 for F2'Small use my_Small; 110 for F2'Size use 16; 111 112In practice all compilers will do the same thing here and will give you 113what you want, so the above declarations are fully portable. If you really 114want to play language lawyer and guard against ludicrous behavior by the 115compiler you could add 116 117.. code-block:: ada 118 119 Test1 : constant := 1 / Boolean'Pos (F2'First = My_First); 120 Test2 : constant := 1 / Boolean'Pos (F2'Last = My_Last); 121 122One or other or both are allowed to be illegal if the compiler is 123behaving in a silly manner, but at least the silly compiler will not 124get away with silently messing with your (very clear) intentions. 125 126If you follow this scheme you will be guaranteed that your fixed-point 127types will be portable. 128 129 130 131 132.. _Compatibility_with_Ada_83: 133 134Compatibility with Ada 83 135========================= 136 137.. index:: Compatibility (between Ada 83 and Ada 95 / Ada 2005 / Ada 2012) 138 139Ada 95 and the subsequent revisions Ada 2005 and Ada 2012 140are highly upwards compatible with Ada 83. In 141particular, the design intention was that the difficulties associated 142with moving from Ada 83 to later versions of the standard should be no greater 143than those that occur when moving from one Ada 83 system to another. 144 145However, there are a number of points at which there are minor 146incompatibilities. The :title:`Ada 95 Annotated Reference Manual` contains 147full details of these issues as they relate to Ada 95, 148and should be consulted for a complete treatment. 149In practice the 150following subsections treat the most likely issues to be encountered. 151 152.. _Legal_Ada_83_programs_that_are_illegal_in_Ada_95: 153 154Legal Ada 83 programs that are illegal in Ada 95 155------------------------------------------------ 156 157Some legal Ada 83 programs are illegal (i.e., they will fail to compile) in 158Ada 95 and later versions of the standard: 159 160 161* *Character literals* 162 163 Some uses of character literals are ambiguous. Since Ada 95 has introduced 164 ``Wide_Character`` as a new predefined character type, some uses of 165 character literals that were legal in Ada 83 are illegal in Ada 95. 166 For example: 167 168 .. code-block:: ada 169 170 for Char in 'A' .. 'Z' loop ... end loop; 171 172 The problem is that 'A' and 'Z' could be from either 173 ``Character`` or ``Wide_Character``. The simplest correction 174 is to make the type explicit; e.g.: 175 176 .. code-block:: ada 177 178 for Char in Character range 'A' .. 'Z' loop ... end loop; 179 180* *New reserved words* 181 182 The identifiers ``abstract``, ``aliased``, ``protected``, 183 ``requeue``, ``tagged``, and ``until`` are reserved in Ada 95. 184 Existing Ada 83 code using any of these identifiers must be edited to 185 use some alternative name. 186 187* *Freezing rules* 188 189 The rules in Ada 95 are slightly different with regard to the point at 190 which entities are frozen, and representation pragmas and clauses are 191 not permitted past the freeze point. This shows up most typically in 192 the form of an error message complaining that a representation item 193 appears too late, and the appropriate corrective action is to move 194 the item nearer to the declaration of the entity to which it refers. 195 196 A particular case is that representation pragmas 197 cannot be applied to a subprogram body. If necessary, a separate subprogram 198 declaration must be introduced to which the pragma can be applied. 199 200* *Optional bodies for library packages* 201 202 In Ada 83, a package that did not require a package body was nevertheless 203 allowed to have one. This lead to certain surprises in compiling large 204 systems (situations in which the body could be unexpectedly ignored by the 205 binder). In Ada 95, if a package does not require a body then it is not 206 permitted to have a body. To fix this problem, simply remove a redundant 207 body if it is empty, or, if it is non-empty, introduce a dummy declaration 208 into the spec that makes the body required. One approach is to add a private 209 part to the package declaration (if necessary), and define a parameterless 210 procedure called ``Requires_Body``, which must then be given a dummy 211 procedure body in the package body, which then becomes required. 212 Another approach (assuming that this does not introduce elaboration 213 circularities) is to add an ``Elaborate_Body`` pragma to the package spec, 214 since one effect of this pragma is to require the presence of a package body. 215 216* *Numeric_Error is the same exception as Constraint_Error* 217 218 In Ada 95, the exception ``Numeric_Error`` is a renaming of ``Constraint_Error``. 219 This means that it is illegal to have separate exception handlers for 220 the two exceptions. The fix is simply to remove the handler for the 221 ``Numeric_Error`` case (since even in Ada 83, a compiler was free to raise 222 ``Constraint_Error`` in place of ``Numeric_Error`` in all cases). 223 224* *Indefinite subtypes in generics* 225 226 In Ada 83, it was permissible to pass an indefinite type (e.g, ``String``) 227 as the actual for a generic formal private type, but then the instantiation 228 would be illegal if there were any instances of declarations of variables 229 of this type in the generic body. In Ada 95, to avoid this clear violation 230 of the methodological principle known as the 'contract model', 231 the generic declaration explicitly indicates whether 232 or not such instantiations are permitted. If a generic formal parameter 233 has explicit unknown discriminants, indicated by using ``(<>)`` after the 234 subtype name, then it can be instantiated with indefinite types, but no 235 stand-alone variables can be declared of this type. Any attempt to declare 236 such a variable will result in an illegality at the time the generic is 237 declared. If the ``(<>)`` notation is not used, then it is illegal 238 to instantiate the generic with an indefinite type. 239 This is the potential incompatibility issue when porting Ada 83 code to Ada 95. 240 It will show up as a compile time error, and 241 the fix is usually simply to add the ``(<>)`` to the generic declaration. 242 243 244.. _More_deterministic_semantics: 245 246More deterministic semantics 247---------------------------- 248 249* *Conversions* 250 251 Conversions from real types to integer types round away from 0. In Ada 83 252 the conversion Integer(2.5) could deliver either 2 or 3 as its value. This 253 implementation freedom was intended to support unbiased rounding in 254 statistical applications, but in practice it interfered with portability. 255 In Ada 95 the conversion semantics are unambiguous, and rounding away from 0 256 is required. Numeric code may be affected by this change in semantics. 257 Note, though, that this issue is no worse than already existed in Ada 83 258 when porting code from one vendor to another. 259 260* *Tasking* 261 262 The Real-Time Annex introduces a set of policies that define the behavior of 263 features that were implementation dependent in Ada 83, such as the order in 264 which open select branches are executed. 265 266 267.. _Changed_semantics: 268 269Changed semantics 270----------------- 271 272The worst kind of incompatibility is one where a program that is legal in 273Ada 83 is also legal in Ada 95 but can have an effect in Ada 95 that was not 274possible in Ada 83. Fortunately this is extremely rare, but the one 275situation that you should be alert to is the change in the predefined type 276``Character`` from 7-bit ASCII to 8-bit Latin-1. 277 278 .. index:: Latin-1 279 280* *Range of type ``Character``* 281 282 The range of ``Standard.Character`` is now the full 256 characters 283 of Latin-1, whereas in most Ada 83 implementations it was restricted 284 to 128 characters. Although some of the effects of 285 this change will be manifest in compile-time rejection of legal 286 Ada 83 programs it is possible for a working Ada 83 program to have 287 a different effect in Ada 95, one that was not permitted in Ada 83. 288 As an example, the expression 289 ``Character'Pos(Character'Last)`` returned ``127`` in Ada 83 and now 290 delivers ``255`` as its value. 291 In general, you should look at the logic of any 292 character-processing Ada 83 program and see whether it needs to be adapted 293 to work correctly with Latin-1. Note that the predefined Ada 95 API has a 294 character handling package that may be relevant if code needs to be adapted 295 to account for the additional Latin-1 elements. 296 The desirable fix is to 297 modify the program to accommodate the full character set, but in some cases 298 it may be convenient to define a subtype or derived type of Character that 299 covers only the restricted range. 300 301 302.. _Other_language_compatibility_issues: 303 304Other language compatibility issues 305----------------------------------- 306 307* *-gnat83* switch 308 309 All implementations of GNAT provide a switch that causes GNAT to operate 310 in Ada 83 mode. In this mode, some but not all compatibility problems 311 of the type described above are handled automatically. For example, the 312 new reserved words introduced in Ada 95 and Ada 2005 are treated simply 313 as identifiers as in Ada 83. However, 314 in practice, it is usually advisable to make the necessary modifications 315 to the program to remove the need for using this switch. 316 See the ``Compiling Different Versions of Ada`` section in 317 the :title:`GNAT User's Guide`. 318 319 320* Support for removed Ada 83 pragmas and attributes 321 322 A number of pragmas and attributes from Ada 83 were removed from Ada 95, 323 generally because they were replaced by other mechanisms. Ada 95 and Ada 2005 324 compilers are allowed, but not required, to implement these missing 325 elements. In contrast with some other compilers, GNAT implements all 326 such pragmas and attributes, eliminating this compatibility concern. These 327 include ``pragma Interface`` and the floating point type attributes 328 (``Emax``, ``Mantissa``, etc.), among other items. 329 330 331.. _Compatibility_between_Ada_95_and_Ada_2005: 332 333Compatibility between Ada 95 and Ada 2005 334========================================= 335 336.. index:: Compatibility between Ada 95 and Ada 2005 337 338Although Ada 2005 was designed to be upwards compatible with Ada 95, there are 339a number of incompatibilities. Several are enumerated below; 340for a complete description please see the 341:title:`Annotated Ada 2005 Reference Manual`, or section 9.1.1 in 342:title:`Rationale for Ada 2005`. 343 344* *New reserved words.* 345 346 The words ``interface``, ``overriding`` and ``synchronized`` are 347 reserved in Ada 2005. 348 A pre-Ada 2005 program that uses any of these as an identifier will be 349 illegal. 350 351* *New declarations in predefined packages.* 352 353 A number of packages in the predefined environment contain new declarations: 354 ``Ada.Exceptions``, ``Ada.Real_Time``, ``Ada.Strings``, 355 ``Ada.Strings.Fixed``, ``Ada.Strings.Bounded``, 356 ``Ada.Strings.Unbounded``, ``Ada.Strings.Wide_Fixed``, 357 ``Ada.Strings.Wide_Bounded``, ``Ada.Strings.Wide_Unbounded``, 358 ``Ada.Tags``, ``Ada.Text_IO``, and ``Interfaces.C``. 359 If an Ada 95 program does a ``with`` and ``use`` of any of these 360 packages, the new declarations may cause name clashes. 361 362* *Access parameters.* 363 364 A nondispatching subprogram with an access parameter cannot be renamed 365 as a dispatching operation. This was permitted in Ada 95. 366 367* *Access types, discriminants, and constraints.* 368 369 Rule changes in this area have led to some incompatibilities; for example, 370 constrained subtypes of some access types are not permitted in Ada 2005. 371 372* *Aggregates for limited types.* 373 374 The allowance of aggregates for limited types in Ada 2005 raises the 375 possibility of ambiguities in legal Ada 95 programs, since additional types 376 now need to be considered in expression resolution. 377 378* *Fixed-point multiplication and division.* 379 380 Certain expressions involving '*' or '/' for a fixed-point type, which 381 were legal in Ada 95 and invoked the predefined versions of these operations, 382 are now ambiguous. 383 The ambiguity may be resolved either by applying a type conversion to the 384 expression, or by explicitly invoking the operation from package 385 ``Standard``. 386 387* *Return-by-reference types.* 388 389 The Ada 95 return-by-reference mechanism has been removed. Instead, the user 390 can declare a function returning a value from an anonymous access type. 391 392 393.. _Implementation-dependent_characteristics: 394 395Implementation-dependent characteristics 396======================================== 397 398Although the Ada language defines the semantics of each construct as 399precisely as practical, in some situations (for example for reasons of 400efficiency, or where the effect is heavily dependent on the host or target 401platform) the implementation is allowed some freedom. In porting Ada 83 402code to GNAT, you need to be aware of whether / how the existing code 403exercised such implementation dependencies. Such characteristics fall into 404several categories, and GNAT offers specific support in assisting the 405transition from certain Ada 83 compilers. 406 407.. _Implementation-defined_pragmas: 408 409Implementation-defined pragmas 410------------------------------ 411 412Ada compilers are allowed to supplement the language-defined pragmas, and 413these are a potential source of non-portability. All GNAT-defined pragmas 414are described in :ref:`Implementation_Defined_Pragmas`, 415and these include several that are specifically 416intended to correspond to other vendors' Ada 83 pragmas. 417For migrating from VADS, the pragma ``Use_VADS_Size`` may be useful. 418For compatibility with HP Ada 83, GNAT supplies the pragmas 419``Extend_System``, ``Ident``, ``Inline_Generic``, 420``Interface_Name``, ``Passive``, ``Suppress_All``, 421and ``Volatile``. 422Other relevant pragmas include ``External`` and ``Link_With``. 423Some vendor-specific 424Ada 83 pragmas (``Share_Generic``, ``Subtitle``, and ``Title``) are 425recognized, thus 426avoiding compiler rejection of units that contain such pragmas; they are not 427relevant in a GNAT context and hence are not otherwise implemented. 428 429 430.. _Implementation-defined_attributes: 431 432Implementation-defined attributes 433--------------------------------- 434 435Analogous to pragmas, the set of attributes may be extended by an 436implementation. All GNAT-defined attributes are described in 437:ref:`Implementation_Defined_Attributes`, 438and these include several that are specifically intended 439to correspond to other vendors' Ada 83 attributes. For migrating from VADS, 440the attribute ``VADS_Size`` may be useful. For compatibility with HP 441Ada 83, GNAT supplies the attributes ``Bit``, ``Machine_Size`` and 442``Type_Class``. 443 444.. _Libraries: 445 446Libraries 447--------- 448 449Vendors may supply libraries to supplement the standard Ada API. If Ada 83 450code uses vendor-specific libraries then there are several ways to manage 451this in Ada 95 and later versions of the standard: 452 453* If the source code for the libraries (specs and bodies) are 454 available, then the libraries can be migrated in the same way as the 455 application. 456 457* If the source code for the specs but not the bodies are 458 available, then you can reimplement the bodies. 459 460* Some features introduced by Ada 95 obviate the need for library support. For 461 example most Ada 83 vendors supplied a package for unsigned integers. The 462 Ada 95 modular type feature is the preferred way to handle this need, so 463 instead of migrating or reimplementing the unsigned integer package it may 464 be preferable to retrofit the application using modular types. 465 466 467.. _Elaboration_order: 468 469Elaboration order 470----------------- 471The implementation can choose any elaboration order consistent with the unit 472dependency relationship. This freedom means that some orders can result in 473Program_Error being raised due to an 'Access Before Elaboration': an attempt 474to invoke a subprogram before its body has been elaborated, or to instantiate 475a generic before the generic body has been elaborated. By default GNAT 476attempts to choose a safe order (one that will not encounter access before 477elaboration problems) by implicitly inserting ``Elaborate`` or 478``Elaborate_All`` pragmas where 479needed. However, this can lead to the creation of elaboration circularities 480and a resulting rejection of the program by gnatbind. This issue is 481thoroughly described in the *Elaboration Order Handling in GNAT* appendix 482in the :title:`GNAT User's Guide`. 483In brief, there are several 484ways to deal with this situation: 485 486* Modify the program to eliminate the circularities, e.g., by moving 487 elaboration-time code into explicitly-invoked procedures 488 489* Constrain the elaboration order by including explicit ``Elaborate_Body`` or 490 ``Elaborate`` pragmas, and then inhibit the generation of implicit 491 ``Elaborate_All`` 492 pragmas either globally (as an effect of the *-gnatE* switch) or locally 493 (by selectively suppressing elaboration checks via pragma 494 ``Suppress(Elaboration_Check)`` when it is safe to do so). 495 496 497.. _Target-specific_aspects: 498 499Target-specific aspects 500----------------------- 501 502Low-level applications need to deal with machine addresses, data 503representations, interfacing with assembler code, and similar issues. If 504such an Ada 83 application is being ported to different target hardware (for 505example where the byte endianness has changed) then you will need to 506carefully examine the program logic; the porting effort will heavily depend 507on the robustness of the original design. Moreover, Ada 95 (and thus 508Ada 2005 and Ada 2012) are sometimes 509incompatible with typical Ada 83 compiler practices regarding implicit 510packing, the meaning of the Size attribute, and the size of access values. 511GNAT's approach to these issues is described in :ref:`Representation_Clauses`. 512 513 514.. _Compatibility_with_Other_Ada_Systems: 515 516Compatibility with Other Ada Systems 517==================================== 518 519If programs avoid the use of implementation dependent and 520implementation defined features, as documented in the 521:title:`Ada Reference Manual`, there should be a high degree of portability between 522GNAT and other Ada systems. The following are specific items which 523have proved troublesome in moving Ada 95 programs from GNAT to other Ada 95 524compilers, but do not affect porting code to GNAT. 525(As of January 2007, GNAT is the only compiler available for Ada 2005; 526the following issues may or may not arise for Ada 2005 programs 527when other compilers appear.) 528 529* *Ada 83 Pragmas and Attributes* 530 531 Ada 95 compilers are allowed, but not required, to implement the missing 532 Ada 83 pragmas and attributes that are no longer defined in Ada 95. 533 GNAT implements all such pragmas and attributes, eliminating this as 534 a compatibility concern, but some other Ada 95 compilers reject these 535 pragmas and attributes. 536 537* *Specialized Needs Annexes* 538 539 GNAT implements the full set of special needs annexes. At the 540 current time, it is the only Ada 95 compiler to do so. This means that 541 programs making use of these features may not be portable to other Ada 542 95 compilation systems. 543 544* *Representation Clauses* 545 546 Some other Ada 95 compilers implement only the minimal set of 547 representation clauses required by the Ada 95 reference manual. GNAT goes 548 far beyond this minimal set, as described in the next section. 549 550 551.. _Representation_Clauses: 552 553Representation Clauses 554====================== 555 556The Ada 83 reference manual was quite vague in describing both the minimal 557required implementation of representation clauses, and also their precise 558effects. Ada 95 (and thus also Ada 2005) are much more explicit, but the 559minimal set of capabilities required is still quite limited. 560 561GNAT implements the full required set of capabilities in 562Ada 95 and Ada 2005, but also goes much further, and in particular 563an effort has been made to be compatible with existing Ada 83 usage to the 564greatest extent possible. 565 566A few cases exist in which Ada 83 compiler behavior is incompatible with 567the requirements in Ada 95 (and thus also Ada 2005). These are instances of 568intentional or accidental dependence on specific implementation dependent 569characteristics of these Ada 83 compilers. The following is a list of 570the cases most likely to arise in existing Ada 83 code. 571 572* *Implicit Packing* 573 574 Some Ada 83 compilers allowed a Size specification to cause implicit 575 packing of an array or record. This could cause expensive implicit 576 conversions for change of representation in the presence of derived 577 types, and the Ada design intends to avoid this possibility. 578 Subsequent AI's were issued to make it clear that such implicit 579 change of representation in response to a Size clause is inadvisable, 580 and this recommendation is represented explicitly in the Ada 95 (and Ada 2005) 581 Reference Manuals as implementation advice that is followed by GNAT. 582 The problem will show up as an error 583 message rejecting the size clause. The fix is simply to provide 584 the explicit pragma ``Pack``, or for more fine tuned control, provide 585 a Component_Size clause. 586 587* *Meaning of Size Attribute* 588 589 The Size attribute in Ada 95 (and Ada 2005) for discrete types is defined as 590 the minimal number of bits required to hold values of the type. For example, 591 on a 32-bit machine, the size of ``Natural`` will typically be 31 and not 592 32 (since no sign bit is required). Some Ada 83 compilers gave 31, and 593 some 32 in this situation. This problem will usually show up as a compile 594 time error, but not always. It is a good idea to check all uses of the 595 'Size attribute when porting Ada 83 code. The GNAT specific attribute 596 Object_Size can provide a useful way of duplicating the behavior of 597 some Ada 83 compiler systems. 598 599* *Size of Access Types* 600 601 A common assumption in Ada 83 code is that an access type is in fact a pointer, 602 and that therefore it will be the same size as a System.Address value. This 603 assumption is true for GNAT in most cases with one exception. For the case of 604 a pointer to an unconstrained array type (where the bounds may vary from one 605 value of the access type to another), the default is to use a 'fat pointer', 606 which is represented as two separate pointers, one to the bounds, and one to 607 the array. This representation has a number of advantages, including improved 608 efficiency. However, it may cause some difficulties in porting existing Ada 83 609 code which makes the assumption that, for example, pointers fit in 32 bits on 610 a machine with 32-bit addressing. 611 612 To get around this problem, GNAT also permits the use of 'thin pointers' for 613 access types in this case (where the designated type is an unconstrained array 614 type). These thin pointers are indeed the same size as a System.Address value. 615 To specify a thin pointer, use a size clause for the type, for example: 616 617 .. code-block:: ada 618 619 type X is access all String; 620 for X'Size use Standard'Address_Size; 621 622 which will cause the type X to be represented using a single pointer. 623 When using this representation, the bounds are right behind the array. 624 This representation is slightly less efficient, and does not allow quite 625 such flexibility in the use of foreign pointers or in using the 626 Unrestricted_Access attribute to create pointers to non-aliased objects. 627 But for any standard portable use of the access type it will work in 628 a functionally correct manner and allow porting of existing code. 629 Note that another way of forcing a thin pointer representation 630 is to use a component size clause for the element size in an array, 631 or a record representation clause for an access field in a record. 632 633 See the documentation of Unrestricted_Access in the GNAT RM for a 634 full discussion of possible problems using this attribute in conjunction 635 with thin pointers. 636 637 638.. _Compatibility_with_HP_Ada_83: 639 640Compatibility with HP Ada 83 641============================ 642 643All the HP Ada 83 pragmas and attributes are recognized, although only a subset 644of them can sensibly be implemented. The description of pragmas in 645:ref:`Implementation_Defined_Pragmas` indicates whether or not they are 646applicable to GNAT. 647 648* *Default floating-point representation* 649 650 In GNAT, the default floating-point format is IEEE, whereas in HP Ada 83, 651 it is VMS format. 652 653* *System* 654 655 the package System in GNAT exactly corresponds to the definition in the 656 Ada 95 reference manual, which means that it excludes many of the 657 HP Ada 83 extensions. However, a separate package Aux_DEC is provided 658 that contains the additional definitions, and a special pragma, 659 Extend_System allows this package to be treated transparently as an 660 extension of package System. 661