Corrupted .OBJ File When Using /FULL_UNDEF

I have a source file which seems to compile fine with the latest version of FTN95 (4.9.1) when no debugging compiler directives are selected, but when I compile with /FULL_UNDEF selected the Call to SELECT_GRAPHICS_OBJECT@ is corrupted in the .OBJ. This is easy to see when the /EXPLIST option is also selected by searching for 'select_graphics_object' in the List file -- it has 4 garbage characters appended to the end of the name, and this prevents complete linkage and any subsequent debugging effort. The garbage characters can also be seen by searching for 'select_graphcis_object' in the .OBJ file.

I don't expect anybody to help me debug my software, but this doesn't feel to me like a programming problem, but rather a potential problem in the compiler. Quite possibly I have exceeded some unknown limit in the compiler, but whatever it might be is not apparent to me.

I don't know how to post attachments in the Forum (a relative newbie in that regard), so I have posted the source file in question (WIOWM_1.FOR) and the various necessary Include files it uses at my web site located at http://www.StrongConcepts.net/Downloads/FTN/. If anyone could first replicate the problem, then possibly offer a course of action to find the problem, it would be much appreciated.

Dennis Strong, Strong Concepts

PS An interesting observation I just made is that when I change my FTN95.cfg options from /INTS /LOGS to /INTL /LOGL, the problem appears to go away!

Dennis

If the problem is solved by using /INTL rather than /INTS then it is not necessary to look further.

/INTL is the default and it means that INTEGER is the same as INTEGER4 ie INTEGER(3). This is the integer size that is used in most of the Salford library routines. /INTS sets the default size to 16 bit integers and is not recommended on 32-bit machines and operating systems. If you have to use 16 bit integers then you can use INTEGER2 ie INTEGER(2) locally.

Regards

Paul

I agree with your suggestion to change to a /INTL default, but I have been trying to avoid such a change for years, mostly 'cuz I'm an old-school programmer who cut my teeth programming in 64kb environments, not 512MB (!) (so it's just in my blood to keep my memory usage down); but also 'cuz as a result of so many years programming on smaller machines I fear I've written code where I've expected the largest integer to be 32,767 and fear the unexpected backlash if I blatantly change that (what for me has been a fundamental) assumption.

For many years using FTN77, /INTS & /LOGS have served me well in this regard, so I've expected that since it is still an option in FTN95 that it will continue to work for me. I just declare anything that interfaces to the Salford libraries as I*4 and happily keep my memory usage to a minimum. In fact, I had to wait for the 4.9.1 release to even begin using FTN95 because of the problem using /INTS with the <WINDOWS.INS> include files. On the basis that /INTS & /LOGS are documented features of FTN95, is it worth exploring further to figure out the cause of the problem? My fears run deep thinking of changing to /INTL...

Dennis Strong, Strong Concepts

Dennis

My recommendation is that you switch to the default integer size. It is more efficient and safer all round. It would take several hours of work to find the cause of your problem and the outcome is likely to be the same.

Regards

Paul