Silverfrost Forums

Welcome to our forums

Variable names in executable

31 Aug 2006 4:19 #974

Hi,

we are currently working on a security relevant issue, a license check. I've renamed the executable for testing purposes to a text file and opened it, where I found that the variable names from the source code were still in there. It's not critical, but I've been wondering whether there is a compiler option or some other means to remove from the executable any information about such things as variable names in the source code.

Rainer

31 Aug 2006 4:54 #975

Rainer

There is no compiler option of this kind.

31 Aug 2006 5:29 #976

I thought that the /debug option placed more source code information in the executable, than if not using /debug. I mostly use /debug as I assumed it placed more information in the program so that if it crashed it gave the line number and source code file name, but at a minimal overhead to performance. By not using /debug or using /opt, I would have expected that there was less source code information placed in the .exe file. Certainly with these options, if the program crashes, there is not much information available. Paul, is this the case ? Could you update us on the compile option levels that control recovery information and optimisation. It is my understanding they range from: /opt (nothing) /debug /quick_bounds /check /undef /full or /checkmate

I typically only use /check or /debug, depending on a development or production version of the code; as well as always using: /ERROR_NUMBERS /IMPLICIT_NONE /INTL /LOGL

Regards

John Campbell

1 Sep 2006 4:42 #978

John

Yes you are right. I missed this. If you do not use any of the debugging options then the executable apparently shows no evidence of the programmer's identifiers (at least not the internal ones).

The range of debugging options is as you describe with /check implying /debug and so on.

However, /quick_bounds is accepted but has no effect. I will remove it from the help information.

Under normal circumstances /INTL and /LOGL are redundant because this is the default state.

1 Sep 2006 5:05 #979

/bounds_check works OK.

It does not imply /debug. It is implied by /check.

1 Sep 2006 5:31 #980

Using /opt it seems there is no reference to variable names in the executable anymore. Also, the executable is considerably smaller. Thanks to both of you. 😃

4 Sep 2006 4:32 #982

Using no option may be better, as /opt implies the optimiser, which can provide some unwanted changes to non-standard code.

5 Sep 2006 5:24 #985

Thanks. I guess I thought like 'I want something to happen, so I have to use an option for it.' instead of 'I want something not to happen, so I have to not use an option.' 😉

7 Sep 2006 12:56 #1001

A plain compile:

ftn95 test

Will not produce debug information unless you have configured FTN95 to produce it by default (with FTN05 /config). You can see the compiler options in effect by producing a list file:

ftn95 test /list

An executable without debug information will still contain the names of routines and functions. These are required to produce a traceback in the event of a run time error.

It should be noted that .NET is different and a lot more information is contained in the executable.


Administrator Silverfrost Forums


-- Admin Silverfrost Limited
Please login to reply.