From: "Alexei A. Frounze" <alex DOT fru AT mtu-net DOT n-o-s-p-a-m DOT ru>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: GCC bugs
Date: 20 Jan 2000 06:51:36 GMT
Organization: MTU-Intel ISP
Lines: 36
Message-ID: <01bf6314$23454060$LocalHost@alex>
References: <01bf611a$9c6e9500$LocalHost AT alex> <3883BCC2 DOT 2CC1DCD9 AT a DOT crl DOT com> <01bf61c3$70f0a7c0$LocalHost AT alex> <Pine DOT SUN DOT 3 DOT 91 DOT 1000119113628 DOT 9609M-100000 AT is> <01bf627f$0b8075c0$LocalHost AT alex> <3885FC3A DOT E2827604 AT is DOT elta DOT co DOT il> <388637F7 DOT 7EB3 AT erols DOT com>
NNTP-Posting-Host: dial57060.mtu-net.ru
X-Trace: gavrilo.mtu.ru 948351096 99132 195.34.57.60 (20 Jan 2000 06:51:36 GMT)
X-Complaints-To: usenet-abuse AT mtu DOT ru
NNTP-Posting-Date: 20 Jan 2000 06:51:36 GMT
X-Newsreader: Microsoft Internet News 4.70.1155
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

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.