I am compiling with the Text IDE, and I set it up with the same settings I was
using with the 32bit version… and yes I did turn on Range checking, so that
explains why we didn’t notice it before.
James
From: fpc-pascal <fpc-pascal-boun...@lists.freepascal.org> On Behalf Of Jean
SUZINEAU
Sent: Friday, August 9, 2019 12:34 AM
To: James Richters <ja...@productionautomation.net>; 'FPC-Pascal users
discussions' <fpc-pascal@lists.freepascal.org>
Subject: Re: [fpc-pascal] USB Human Interface Devices
Hi James,
Le 09/08/2019 à 02:19, James Richters a écrit :
so this was strange... it was working before
line 81 For J := 1 to Length(PortPath)-1 do
line 82 Write('->',PortPath[I]);
Line 82 is using variable I but it's in a loop that uses J, I didn't think that
made a lot of sense.. so without really analyzing how any of this was supposed
to work.. I just changed the I to a J and then I got this:
I think it's a typo.
I think we didn't saw it before because Range type checking was disabled (
{$RANGECHECKS OFF} or {$R-} ).
It seems it's the default value for the compiler:
https://www.freepascal.org/docs-html/prog/progsu65.html . Very often in Windows
system functions you have to deal with records with declared with a length of 1
and the real length stored a few bytes before in the record. This could not
work with {$R+}
But it's seems that for some reason it's enabled for your compiler (may be a
different default value when your recompiled with fpcupdeluxe, or more likely a
different default value in your settings for fp.exe ?).
I'm not an expert in memory allocation, but I think that while a certain amount
of memory is allocated after the memory pointed to by PortPath and you're in
{$R-} mode, you can happily read several bytes after the actual end of PortPath
without any segmentation fault or memory access exception.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
