Mail Archives: djgpp/1997/11/25/09:05:14
Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> wrote:
> On Mon, 24 Nov 1997, sl wrote:
> > Regardless of if you allocate the array staticly or dynamically it
> > should NOT use up diskspace!
>
> This cannot be done in all cases. For example, if the array is
> initialized by values other than zeroes, the linker has no other way
> than to write all those values into the disk .exe file.
However, if it is not actually initialised, for instance:
int array[10000];
then there should be no need to put it in the executable.
Way back in the old days of the original Unix C, there was
a link area called BSS, Blank Space Segment (or Section).
This was set in the executable to tell the OS that it was
needed space, but didn't take up room in the image. Either
the OS or the program startup code (on different systems)
would then initialise this to zero.
Can this be done now? Certainly as far as the DOS executable
format is concerned. However, recent versions of Unix have
tended to drop this, because the Unix file format allows
files to have 'holes' which don't actually take up disk
space - MSDOS doesn't allow this.
There's also the problem with ANSI C (and C++) that all
variables are initialised as though they had the value zero
assigned to them. This used to be predictable that this was
the same as setting te memory to zero bytes, but the standards
explicitly allow for othe byte values to represent zero. For
instance, a null pointer could be internally represented by
0xFFFFFFFF, say, and a floating-point zero value might have a
non-zero exponent. This makes just "zapping" to memory to
zero bytes not necessarily what is needed.
Surely the solution is to use the DJGPP exe compressor (DJP?)
which should make those massive blank regions effectively
disappear. This will have the same effect as on Unix, to
reduce the amount of disk space to a sensible amount.
Chris C
- Raw text -