Waldek Hebisch wrote:
Adriaan van Os wrote:
Looking into this further, the cause seems to be a curious miscalculation of record sizes.
Why do you think that sizes are miscalculated? On my Linux box I get the same result and explanation is simple: to get correct alignment Extended uses 16 bytes (only 10 are really used, the rest is just padding). That explains size of pv3 and pv4. pv1 must be aligned to 16 bytes, so we must round up the size to 48 bytes. pv2 is packed, so final padding is skipped, and we get 34.
So, it looks OK (assuming that C compiler on Mac OSX gives you 16 as the size for 'long double').
Yes, you are right, it has nothing to do with record sizes as such. I thought so, because putting "packed" in front of the record type, solved the problem. However, it does have to do with alignments (see my follow-up email on the issue). When --maximum-field-alignment=0 (the default), then within procedure 'd', the addresses of sp and z are wrong. With any other value for --maximum-field-alignment, the program compiles and runs OK.
Regards,
Adriaan van Os
program prog;
procedure dcp; type pv = record x, y: extended; v: array[1..2] of Boolean; end; var sp: pv; z: Boolean;
procedure d(p: pv); begin writeln( 'in d: @sp = ', PtrWord( @sp)); writeln( 'in d: @z = ', PtrWord( @z)); writeln('access z before'); if z then writeln('z is true'); end;
begin { dcp } writeln( 'in dcp: @sp = ', PtrWord( @sp)); writeln( 'in dcp: @z = ', PtrWord( @z)); z := True; d(sp); end;
begin dcp; end. [p17:~/gpc/testgpc/adriaan] adriaan% gpc schorn1b.pas -Os [p17:~/gpc/testgpc/adriaan] adriaan% ./a.out in dcp: @sp = 3221219184 in dcp: @z = 3221219232 in d: @sp = 0 in d: @z = 48 access z before Bus error