Conference turris::ada

3862.0. "Problem with program ported from VAX to Alpha" by H2SO4::GERSBACH (Edwin Gersbach MCS Switzerland) Fri Apr 11 1997 06:34

The following small program is a short reproducer of a problem the customer is
encountering in a large application he is porting from VAX to Alpha. The reason
behind the 'USE AT' clause is that the program gets data from a external source.
Depending on some facts one of several possible records is 'mapped' to the data
buffer (which is a array of bytes in the real program). This has worked fine on
VAX'en but causes a PROGRAM_ERROR during elaboration on Alpha systems:

$ ada use_test
$ acs link test_p
$ run test_p
%ADA-F-PROGRAM_ERROR, PROGRAM_ERROR
-ADA-I-EXCRAIPRI, Exception raised prior to PC = 00030270
%TRACE-E-TRACEBACK, symbolic stack dump follows
 Image Name   Module Name     Routine Name    Line Number  rel PC      abs PC
 ADARTL                                                 0 00054A3C    000A6A3C
                                                        0 80495D44    80495D44
----- above condition handler called with exception 00318964:
%ADA-F-PROGRAM_ERROR, PROGRAM_ERROR
-ADA-I-EXCRAIPRI, Exception raised prior to PC = 00030270
----- end of exception message
                                                        0 892BC2BC    892BC2BC
 ADARTL                                                 0 00037754    00089754
 TEST_P       TEST_USE_       TEST_USE_                11 00000100    00030270
 TEST_P       ADA$ELAB_TEST_P                           0 000200C0    000300C0
 ADARTL                                                 0 00054BC0    000A6BC0
 ADARTL                                                 0 00054344    000A6344
 ADARTL                                                 0 0003F260    00091260
 TEST_P       ADA$ELAB_TEST_P                           0 0002005C    0003005C
 TEST_P                                                 0 00020340    00030340
                                                        0 893B8170    893B8170

the code is as follows:
-----------------------

     with system;use system;
     package test_use is
         type str_ptr is access string;
         type xrec_t is
         Record
            tl   : integer;
            tc   : character;
            tf   : long_float;
         End Record;
         buffer : str_ptr:= new String(1..integer(xrec_t'size/8));
         xrec : xrec_t;
         for xrec use at buffer.All'Address;
     end test_use;
     with test_use;
     procedure test_p is
     begin
         test_use.xrec.tl := 1;
     end test_p;

The customer has found that the problem only exists when the record contains a
floating point element of any kind.

Obvious question: Is it a bug or a feature?
Any idea how to work around this problem?

Edwin

This is a feature.

The Program_Error is being raised because the storage allocated by the "new
String" is not adequately aligned for its use as a xrec_t.

/Bevin

>Any idea how to work around this problem?

First let me note that the program is erroneous, because it is using address
clauses to achieve overlays.  LRM 13.5(9): "Address clauses should not be used
to achieve overlays of objects or overlays of program units.... Any program
using address clauses to achieve such effects is erroneous."

The right way to achieve the effect of overlays is usually to declare the
variable as being one form, and then use instances of Unchecked_Conversion to
convert from this form to any others desired.

Have a buffer...

	type ALIGNED_STORAGE(Amount : Natural) is
	record
		Filler  : String(1..12);
		Storage : String(1..Amount);
	end record;

	for ALIGNED_STORAGE use
	record at mod 16;
		Amount at 0 range   0.. 4*8-1;
		Filler at 0 range 4*8..16*8-1;
	end record;                     

allocate it "new ALIGNED_STORAGE" and take P.Storage'address;

/Bevin

Thanks!
The customer is happy with this information, although he does now have to modify
a very old program (the data sender) which he wanted to avoid to touch. He is
planing to do it the right way this time using variant records.

Edwin