forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

GET_GSTORAGE@ doesn't always work?
Goto page Previous  1, 2, 3, 4
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7777
Location: Salford, UK

PostPosted: Tue Jan 17, 2023 7:09 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
Robert



Joined: 29 Nov 2006
Posts: 439
Location: Manchester

PostPosted: Tue Jan 17, 2023 7:11 pm    Post subject: Reply with quote

If you are allocating from the top 2GB then it is false positive but they checking mechanisms are designed that way.
Back to top
View user's profile Send private message Visit poster's website
JohnCampbell



Joined: 16 Feb 2006
Posts: 2507
Location: Sydney

PostPosted: Wed Jan 18, 2023 5:11 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
KennyT



Joined: 02 Aug 2005
Posts: 317

PostPosted: Wed Jan 18, 2023 7:14 am    Post subject: Reply with quote

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:

Code:
 
    CALL DS_Del (XP%IAXP)

works:
Code:
        
             iadkkk    =  XP%IAXP
        CALL DS_Del (iadkkk)


fails:

Code:
 
  INTEGER, ALLOCATABLE   :: ITY(:)

  ALLOCATE(ITY(100), STAT=IST)

   CALL DS_GetI ('ch_type', IAD, IBL, J, 1, ITY(J))

works:
Code:
   
  INTEGER, ALLOCATABLE   :: ITY(:)

  ALLOCATE(ITY(100), STAT=IST)
   
  CALL DS_GetI ('ch_type', IAD, IBL, J, 1, kkk)
  ITY(J)   = kkk


I think it may only be a problem if the address of the variable is negative (e.g. >2Gb in 32bit) which may be why it's been difficult to make a "noddy" up to now...

...but i'll try!

K
Back to top
View user's profile Send private message Visit poster's website
Robert



Joined: 29 Nov 2006
Posts: 439
Location: Manchester

PostPosted: Wed Jan 18, 2023 9:31 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Visit poster's website
KennyT



Joined: 02 Aug 2005
Posts: 317

PostPosted: Wed Jan 18, 2023 9:50 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message Visit poster's website
Robert



Joined: 29 Nov 2006
Posts: 439
Location: Manchester

PostPosted: Wed Jan 18, 2023 9:55 am    Post subject: Reply with quote

It is a function of FTN95 but the checks are so ingrained that the best way is to avoid the checking options...
Back to top
View user's profile Send private message Visit poster's website
KennyT



Joined: 02 Aug 2005
Posts: 317

PostPosted: Wed Jan 18, 2023 10:03 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Goto page Previous  1, 2, 3, 4
Page 4 of 4

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group