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 

Initialization to zero
Goto page Previous  1, 2, 3  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 1683
Location: Yateley, Hants, UK

PostPosted: Mon Jan 04, 2016 10:53 am    Post subject: Reply with quote

Paul,

I assume that the space for COMMON blocks is allocated when a program starts, but thereafter the allocation is static for the whole program run.

John,

I liked your first_call idea, and decided that I would use it myself, until I realised that if I start a program with File | New I automatically initialise everything, and if I start from File | Open or a file association (I don't do 'drag and drop') then I initialise in a different way. I only use single document interfaces (SDI) so I know at any point (as if it isn't obvious from where in the program it is) from the grey codes in the File menu whether it is a 'start from nothing' run or not.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Mon Jan 04, 2016 12:37 pm    Post subject: Reply with quote

That is also my assumption.
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 1834
Location: Sydney

PostPosted: Wed Jan 06, 2016 8:06 am    Post subject: Reply with quote

Eddie,

I learnt to use Fortran using compilers that did not initialise memory. I was taught that failing to initialise variables and arrays is wrong and I still have that view, so I never use /zero.

However, although /save was not required back then, I have learnt to manage dynamic allocation of local variables in a subroutine and now consider all variables to be lost between calls, unless I explicitly save them. I don't like /save.

I will always use /implicit_none, which just goes to show that the use of all these options remains a personal coding preference and is not a RULE.

John
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 1683
Location: Yateley, Hants, UK

PostPosted: Thu Jan 07, 2016 12:06 am    Post subject: Reply with quote

John,

I detest /zero for reasons you adduce, and dislike /save because it debauches the clarity of the original Fortran:use COMMON, and variable contents are saved, define them locally and they aren't.
Back to top
View user's profile Send private message
Steve



Joined: 23 Feb 2007
Posts: 73

PostPosted: Thu Aug 31, 2017 4:54 pm    Post subject: Reply with quote

If I may, I would like to continue with this thread and provide our compilation findings.

We have just moved from v6 to the latest v8.1 using the same compilation options of /WINDOWS /INTL /ZEROISE. We are now creating a DLL where in the past we created an EXE.

A user contacted us to say our software crashed. It turns out a local variable was undefined. v6 use of the /ZEROISE option worked fine for us and now there seems to be a difference in its use. Reading the current thread confirms what I found : using /SAVE resolved the initialisation concern. However, we are not wanting this as a solution due to the size of the product and also the potential for any other undefined local variables, using their last value.

So, looking thru the compiler options, we noticed /LOcal_zero which reads exactly what we want " implies /ZEROise and also initialises local variables to zero when not using /UNDEF". [ This is confusing, as you cannot have /UNDEF at the same time as /LO ]. Apart from creating an enormous product - just like using /UNDEF or /SAVE - this option did NOT solve our problem.

My question, Paul, is why did /LO not initialise local variables as /ZEROISE did in v6 ? Thanks
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 1683
Location: Yateley, Hants, UK

PostPosted: Thu Aug 31, 2017 5:36 pm    Post subject: Reply with quote

Steve,

Reading what you wrote, is it possible that the problem arises through the use of a DLL instead of an EXE, and therefore is not a SAVE or ZEROISE issue? Have you compiled and run the old version software with 8.1?

Eddie
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Fri Sep 01, 2017 8:34 am    Post subject: Reply with quote

Steve

I don't have access to the required information at the moment so I can't respond fully to your query.

/UNDEF is designed for use when developing your application. Switch it on and test every path through the code. In other words, you only need to test for undefined variables once. The same principle applies to /CHECK and /CHECKMATE (which is /FULL_UNDEF). These options add a significant overhead to the code size and speed and normally are not helpful once every path has been checked.
Back to top
View user's profile Send private message
Steve



Joined: 23 Feb 2007
Posts: 73

PostPosted: Fri Sep 01, 2017 9:05 am    Post subject: Reply with quote

Thanks. Eddie. But we now have no choice but to go for our source code to be DLL - called from a Delphi wrapper.

I see no reason why DLL should be compromised by the compiler options, as DLL is permitted as an alternative to EXE.

It seems that /ZERO has changed since v6 and I just wonder if the /LO is doing what it is supposed to do, but with an unfortunate size implication. Hopefully, Paul can enlighten us.

And why should /LO increase the size of the DLL/EXE, when /ZERO did not need to in v6 ?

Steve
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Fri Sep 01, 2017 5:19 pm    Post subject: Reply with quote

The only thing that I can add at the moment is that /ZEROISE has not changed. Also we may need some sample code that illustrates the issue that is causing a problem.
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 1683
Location: Yateley, Hants, UK

PostPosted: Fri Sep 01, 2017 6:44 pm    Post subject: Reply with quote

Steve,

Don't you archive the source for old versions? If you have that source code, you could do a trial compilation and run with FTN95 8.10. If it works, then the problem can't lie with the change of compiler versions but with something else you are doing. If it doesn't work, then it is definitely something for Paul to investigate. At the moment there is no proof that the problem relates to the compiler.

Alternatively, does your Delphi / DLL version work properly when compiled with your previous version v6 FTN95? Again, if it does not, then the problem lies with your changes, if it does work, then the problem is in the compiler.

If you no longer have the source code for the version without the Delphi wrapper / DLL, (or a computer with v6 FTN95 installed on it) then the chance of finding what is going wrong has decreased dramatically!

Eddie
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 739

PostPosted: Fri Sep 01, 2017 8:36 pm    Post subject: Reply with quote

I have frequently come across one situation in which compiling with /UNDEF causes spurious aborts: a subprogram saves a copy of an argument, often an array argument. Later, the subprogram changes the value(s) of the argument before using the previous values. When the copy is made, undefined values are used and an abort occurs, even though that copy (or the undefined original) would never be actually used were the program allowed to continue executing.

Other than in the case that I just mentioned, using /Zero, /Save, and other subterfuges to suppress compile time or run time errors does more harm than good. I tend to be sceptical about codes that need such subterfuges to run.

It would be a good investment of your time and effort to determine the causes and implement a proper fix, rather than attempting to keep the problem hidden.
Back to top
View user's profile Send private message
wahorger



Joined: 13 Oct 2014
Posts: 393
Location: Morrison, CO

PostPosted: Mon Sep 04, 2017 2:16 am    Post subject: Reply with quote

I've run across occasions where the actual computed DATA causes the /UNDEF to get triggered. While it is not common, it can occur.

In my case, I was building a bit-mapped image in memory, with each byte being bit-wise set. Occasionally, the bit pattern in the character*1/integer*1 would become the hex pattern 81, and the /UNDEF would get triggered.

In the old days (1960's/70's) on the IBM 7040, there was an actual opcode to set the contents of memory with a bad parity bit. Access (read) this data, and it was trapped. The ultimate in /UNDEF. Alas, those days are long gone, and now a specific pattern has to be used.

While this bit pattern idea does work, it has some limitations.
Back to top
View user's profile Send private message Visit poster's website
Steve



Joined: 23 Feb 2007
Posts: 73

PostPosted: Mon Sep 04, 2017 10:32 am    Post subject: Reply with quote

Thanks for the latest replies.

The whole point is that it was only a change of compiler from v6 to v8.1 that highlighted the problem and not the change of code with v8.1.

Only now, when reading up the definition of /ZERO, is it a puzzle that v6 worked at all, ie that local variables must have been getting initialised, because they should not have done so according to the documentation. The places we have found wanting in v8.1 so far, on a revisit to v6 worked fine.

If /ZERO has not changed, as Paul points out, this suggests that something else in the v6 compiler must be doing the initialisation : what other explanation is there ?

Certainly, amending the 'old' code to initialiase the offending variables with v8.1 works fine. We appreciate Paul's advice in attempting to identify these places in the 'old' code, but this would be a massive undertaking at the moment. We shall definitely need to do plenty of testing.

But I would like to re-emphasize the /LO option. Using it did not overcome the problem ! as I said before, with such a big overhead due to product size, it does seem to be a restrictive option.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Tue Sep 05, 2017 7:17 am    Post subject: Reply with quote

Steve

The option /LOCAL_ZERO is for .NET only (i.e. /CLR). Also it can't be used with /CHECK or any option that implies /CHECK such as /UNDEF and /CHECKMATE.

/LOCAL_ZERO was added at the request of a major user of .NET FTN95 and has only been implemented for .NET.

I don't understand how you can have used /LOCAL_ZERO because without /CLR you get a compile time failure and presumably you are not aiming to create a .NET assembly.

More to follow...
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Tue Sep 05, 2017 7:36 am    Post subject: Reply with quote

Steve

You refer to the option /ZEROISE and also that you have moved from using a Fortran executable to using a Fortran DLL.

My first question would be, do you have shared data/variables in the DLL (i.e. data/variables that are shared between different functions and subroutines) and, if so how are these values initialised and shared?

If you only use local variables and pass other values as arguments in function/subroutine calls then it would be a simple matter to find out what /ZEROISE does in that context.
Back to top
View user's profile Send private message
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  Next
Page 2 of 3

 
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