rsjetty
asked on
Executable Sizes
certain C programs that iam trying to re-engg use a lot of non-descriptive variable names. for eg:- most int's are 'i', filehandlers are 'fh' etc. what i want to do is give more descriptive variable names. however the catch is that the size of the new executable should not be greater than the previous one. so the question is
"how do the variable names and consequently the size of the symbol table affect the executable size ? Is there any way one can shrink the symbol table?"
i'd appreciate if you can point me to some info about the sym T's.
"how do the variable names and consequently the size of the symbol table affect the executable size ? Is there any way one can shrink the symbol table?"
i'd appreciate if you can point me to some info about the sym T's.
ASKER
Thanks dyp.
you have certainly thrown some insight into the problem.
But there are certain issues which i would like to address
(1)i'm not trying to move my executable from a Debug ver. to a Release ver. rather i'm doing code optimisation/enhancements , so at the same time i felt i should make the code more readable.
(2)i'm not familiar with the 'strip' command. what does it do?
--------------------------
if i were to reframe my question i'd put it this way,
how do the statements/declarations
< int ctr; >
and
< int nCounterToSequentiallyIncr
differ from each other when they are loaded in the SymT?
Is there any way I can use lenghty identifiers such as nCounterToSeq... (though i've exaggerated a bit in this example)
in my program and still maintain the SymT or the Executable at the same size as though i were using the identifier 'ctr'.
you have certainly thrown some insight into the problem.
But there are certain issues which i would like to address
(1)i'm not trying to move my executable from a Debug ver. to a Release ver. rather i'm doing code optimisation/enhancements , so at the same time i felt i should make the code more readable.
(2)i'm not familiar with the 'strip' command. what does it do?
--------------------------
if i were to reframe my question i'd put it this way,
how do the statements/declarations
< int ctr; >
and
< int nCounterToSequentiallyIncr
differ from each other when they are loaded in the SymT?
Is there any way I can use lenghty identifiers such as nCounterToSeq... (though i've exaggerated a bit in this example)
in my program and still maintain the SymT or the Executable at the same size as though i were using the identifier 'ctr'.
You should understand that the length of identifiers
will affect the size of the executable only if you
will compile debug info. Otherwise size will not be
changed.
strip simple removes all debug information from executable.
will affect the size of the executable only if you
will compile debug info. Otherwise size will not be
changed.
strip simple removes all debug information from executable.
ASKER
got you , thanks.
But iam confused with the /H flag supported by the MS compilers.
/H :-Restricts significant characters in external names to a specified length.
also can you be a little more descriptive about 'strip'. ie is it a compiler/linker flag or what.
But iam confused with the /H flag supported by the MS compilers.
/H :-Restricts significant characters in external names to a specified length.
also can you be a little more descriptive about 'strip'. ie is it a compiler/linker flag or what.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
dyp has it right, if you are building your executables in release mode (vs. debug mode) you don't need to worry about strip.
Likewise, the /H option mentioned only affects exported function names - and therefore only matters if you are building a DLL.
So- assuming you build in release mode - using "nCounterToSequentiallyInc
Likewise, the /H option mentioned only affects exported function names - and therefore only matters if you are building a DLL.
So- assuming you build in release mode - using "nCounterToSequentiallyInc
ASKER
Thanks dpy (& alamo),
I think I've finally got it straight.
I think I've finally got it straight.
any debug information it will be no difference...
Otherwise you may use strip command to remove
debug info...