Illegal Pointer problem

Thanks for your correction, John, it makes me feel somewhat clearer as we may only be dealing with how to use SAVE (I think). From my quite small understanding of 'how things work' I am very attracted to Eddie's view of applying the same technique in all places for consistency reasons and so continue to use /SAVE as routine.

Eddie; As for Clearwin+ well, maybe I will try again. I did do the demo program years ago but have since not felt the need to try again. Thanks for the push!

I've enjoyed reading the continued responses! It is always illuminating to read of others experiences, and it's a good way to document things to look for/be aware of, and tips and techniques to handle different situations.

Having ported lots of code to FTN95 from long before the days when variables could be dynamically allocated, the idea of going back and reworking the declarations is daunting!

That said, it IS a good idea to leave a trail of breadcrumbs to those who will follow you in maintaining the code! Even if the person(s) who follow you happens to be yourself in 20 years! It happened to me!

Yes. the whole discussion has opened up some interesting points and leaves much to mull over.

One thing that I would be pleased to be clear about, though, is just what problems, actual or potential, if any, am I setting myself up for by using /SAVE in all compilations. I do not see from the discussions whether it is a case of 'it should not be needed', 'is not a tidy way to do things' or 'is a bodge that seems to work'.

It may be that there is no clear-cut answer to this and it is far from clear (to me) that all will now be well but it would be good to know of what the use of /SAVE might lead to in the future.

Your question (to /SAVE or not) is ill-timed.

If you wrote the program yourself, you should know what assumptions you made. Simply make the appropriate declarations and choose the appropriate compiler options.

If someone else wrote the program, find out from the author the requirements regarding saving of local variables.

Saving variables that do not deserve/require to be saved has some undesirable consequences.

1. Debugging becomes much harder, because /SAVE makes it impossible to use the excellent debugging facilities of the Silverfrost compiler. Undefined local variables go undetected because they appear to be defined (with some junk value).

2. Small local arrays that could stay in the memory cache, had they not been SAVEd unnecessarily, would have to remain in main memory, causing the program to run slowly. If your program has lots of big common blocks, unnecessary SAVEs can cause performance degradation.

3. Bugs in the program can hide for months, years or decades, especially if the bug causes the results to be off by, say, 5 percent -- or something else that is small enough not to be noticed as indicative of the presence of a bug. The program may even work and give perfectly correct results for a large number of input data sets, and suddenly fail one day with a new data set.

After all, it is the programmer's responsibility to make appropriate design decisions and document the requirements.

Eddie gave a clear description of his style of programming. He knows his conventions and convictions, and stays true to them.

John made a different choice, and he stated his reasons.

I use /SAVE as little as possible, as do many large modern Fortran programs, but my goals, needs and personal inclinations are probably different from theirs.

Which convention suits you best? Ponder and find out!

Thank you for your clear response. I will need to ponder indeed and see what I can find our!

Thank you, and all, for comments and pointers (no pun intended) to a way ahead.

According to the manual /SAVE does NOT physically move any data (thus slowing execution). It does, however, make the variable(s) statically allocated (fixed storage addresses). This will definitely mean that more memory is allocated at run time, and perhaps cause the SWAP file to be used to handle memory usage, while dynamic allocation may/may-not exceed the available memory.

The manual also states that the SAVE statement should be used for individual variables, rather than /SAVE which makes ALL the variables statically allocated.

When dealing with legacy code where the /SAVE was implicit, its use is likely to reduce the debug time.

http://www.silverfrost.com/ftn95-help/options/_save.aspx