[solved] buserror when trying to convert date
lazarus / 64-FPC development

----------------------------------------------------------------------
TRon · 2020-08-28 23:52

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][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i 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 · 2020-08-29 07:58

@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 · 2020-08-29 07:58

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][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i {$mode
objfpc}{$push}{$packrecords 2}type   Tmyrecord1 = record  //without
packed     a:Byte;     b:dword;   end;{$pop}{$push}{$packrecords
4}type   Tmyrecord2 = record  //without packed     a:Byte;   
 b:dword;   end;{$pop}var   R1:TMyRecord1;  R2:TMyRecord2;begin 
writeln(SizeOf(R1)); // prints 6, alignment is 2  writeln(SizeOf(R2));
// prints 8, alignment is 4.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 · 2020-08-29 08:22

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)