Mail Archives: djgpp/2000/01/20/08:27:26
John S. Fine <johnfine AT erols DOT com> çàïèñàíî â ñòàòüþ
<388637F7 DOT 7EB3 AT erols DOT com>...
> Let me jump in here with a guess.
You're welcome John!
> Don't be offended Alexei, and I might easily be wrong, but I think
> this problem is that you don't know COFF format well enough.
>
> It is possible in COFF format to have unused space within the
> COFF file. If a file with unused space is generated then that
> unused space will have whatever bytes were left over in RAM in
> some buffer the compiler allocated but incompletely used.
John, I know what I talk about.
typedef struct {
unsigned short f_magic; /* magic number */
unsigned short f_nscns; /* number of sections */
unsigned long f_timdat; /* time & date stamp */
unsigned long f_symptr; /* file pointer to symtab */
unsigned long f_nsyms; /* number of symtab entries */
unsigned short f_opthdr; /* sizeof(optional hdr) */
unsigned short f_flags; /* flags */
} FILHDR;
The "f_nscns" field really contained 4 instead of 3 or 2 or 1. The name of
the 4th section was ".eh_fram". What information it held I don't know but
probably nothing useful.
> The bug you reported, perfectly fits what you would see if
> you use a COFF dumper that tries to interpret the entire file
> on a file that contains garbage in unused spaces.
But I thought if compiler generates different output files out of unchanged
sources w/o changing any settings of the compiler, it probably has a bug.
There is no room for accident inside the compiler. It must not play dice.
- Raw text -