[solved] buserror when trying to convert date

[TRon]

I am getting:

Code: [Select]

An unhandled exception occurred at $000879B0:
EBusError: Bus error or misaligned data access
  $000879B0  TRYENCODEDATE,  line 115 of /home/Pierre/pas/release-build/release_3_2_0/fpcsrc/rtl/objpas/sysutils/dati.inc
  $00011960  main,  line 297 of test.pas
when using:

Code: Pascal  [Select][+][-]

1. if not TryISOStrToDate(SomeString, SomeRecord.DateTimeField) then ...

Do I (manually) have to take the position of the field inside the record into account and make sure it is aligned at an even address ?

edit: Free Pascal Compiler version 3.2.0 [2020/06/08] for arm (debian 32 bit)

solved: I was (wrongfully) expecting packed would obey alignment/packrecord settings but it doesn't. Instead it always seems to default to 1, which causes the alignment error.

[TRon]

@Tahddy:
Yeah, I used "packrecords". But using "packed record" at the same time as well simply seem to overrule the "packrecords" setting (thus causing the alignment issue)

Maybe it's my lack of understanding but that behaviour wasn't exactly clear to me after reading https://www.freepascal.org/docs-html/ref/refse14.html#QQ2-39-63

.. or should I perhaps be reading somewhere else ?

[Thaddy]

records declared as packed are indeed always packed to one, basically for file formats and transfer or space.
The local compiler directive {$packrecords X} behaves differently, e.g.

Code: Pascal  [Select][+][-]

1. {$mode objfpc}
2. {$push}{$packrecords 2}
3. type
4.    Tmyrecord1 = record  //without packed
5.      a:Byte;
6.      b:dword;
7.    end;
8. {$pop}
9. {$push}{$packrecords 4}
10. type
11.    Tmyrecord2 = record  //without packed
12.      a:Byte;
13.      b:dword;
14.    end;
15. {$pop}
16. var
17.   R1:TMyRecord1;
18.   R2:TMyRecord2;
19. begin
20.   writeln(SizeOf(R1)); // prints 6, alignment is 2
21.   writeln(SizeOf(R2)); // prints 8, alignment is 4.
22. end.

If you would declare both records as packed, the result would be 5, which is efficient for transport and storage, but not efficient to compute on most platforms.
I hope this clarifies the issue and the difference.

[TRon]

Yes, I got it now 

Thank you for the explanation Thaddy.

It was a silly mistake, as I inserted some fields before (in an attempt to save a few bytes) and mis-calculated their sizes , which caused the fields located after those inserted fields to shift 3 bytes (instead of the intended 4). And of course, once in a blue moon that does work... except when located at odd or 2 byte boundaries  (which initially caused some confusion on my part)