forums.silverfrost.com

[PaulLaidler]

Kenny

If you have a short working program that illustrates a false error report then please send it to us so that we can fix it.

[Robert]

If you are allocating from the top 2GB then it is false positive but they checking mechanisms are designed that way.

[JohnCampbell]

I may be saying what Robert said, but slightly differently, as for a 32 bit executable on Win 9 +, a valid memory address could be between 0 to about 3.7 GBytes.

There is potential for some of the 32-bit library routines to not accept values greater than 2 GBytes, and especially > 3 GBytes.

With more recent OS, the chance of getting a memory address above 3 GBytes has increased.

LOC gives a valid answer as an unsigned 32-bit integer, which can be annoying when received to a default integer. I overcame this by equivalencing the receiving integer to an 8-byte integer (initialised to zero), so that I don't need to worry about -ve values with default integers.

[KennyT]

ok, following on from Robert's comment, i noticed what was causing the error 14's!

passing a structure element (defined in a module?) to a subroutine compiled with /undef can cause it.

passing an allocated array element to a subroutine compiled with /undef can cause it.

examples:
fails:

[Robert]

If the address of the variable is above 2GB in 32-bit mode then you can get checking errors. This is by design. Original 32-bit Windows did not allow any user variables above 2GB and so the checking uses the top bit to identify things that cannot be written. In 64-bit Windows some of this upper 2GB can be using in 32-bit mode - but you cannot have checking code that uses this data.

64-bit programs do not have this issue.

[KennyT]

ok, at least that clarifies why we're getting the false positives.

and we have a (albeit long-winded) workaround of passing a simple variable to our memory accessing routines and copying that to/from the allocated/structure element as necessary.

are the checks done by windows or FTN? if the latter, can a switch be set to ignore bombing out when you've got negative addresses? if it's a function of windows, then i guess all bets are off!!

K

[Robert]

It is a function of FTN95 but the checks are so ingrained that the best way is to avoid the checking options...

[KennyT]

just for reference, this all started when we wanted to trap some use of uninitialised memory locations and we found that we couldn't use /UNDEF because of the prevalence of these error 14s.

but if it's more of a pain for you to "unwrap" the checks than it is for us to use temporary variables when we hit an error 14 in undef, so be it!

tks

K