Message-ID: <39F3AC04.8FC5B786@otakuwars.org>
From: the Icefalcon <kourino AT otakuwars DOT org>
Organization: Harumichi Otaku ... doko ni mo!
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
Newsgroups: comp.os.msdos.djgpp
Subject: Programs crash on fstream<< if features.h included before fstream.h
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 40
Date: Mon, 23 Oct 2000 02:58:15 GMT
NNTP-Posting-Host: 12.75.130.187
X-Complaints-To: abuse AT worldnet DOT att DOT net
X-Trace: bgtnsc06-news.ops.worldnet.att.net 972269895 12.75.130.187 (Mon, 23 Oct 2000 02:58:15 GMT)
NNTP-Posting-Date: Mon, 23 Oct 2000 02:58:15 GMT
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Okay, I found out something interesting today. fstream does NOT like it
when you #include features.h before it. I mean, it really doesn't. It
seems to dislike the file so much, in fact, that it will crash within
ostream operator<< (location: ___ls__7ostreamPCc+203) if features.h is
included before fstream.h. Interestingly enough, this doesn't affect
cout: it appears to only affect fstreams. The culprit is a horribly
wrong value of edx, which causes a GPF. A traceback follows:

=======================================================================
Exiting due to signal SIGSEGV
General Protection Fault at eip=00003feb
eax=000acf80 ebx=0000000d ecx=fbad2484 edx=fbad2484 esi=000acfd8
edi=00000000
ebp=000acf38 esp=000acf0c program=D:\OWSF2K\GFX\VESAINFO.EXE
cs: sel=00ef  base=82e38000  limit=000bffff
ds: sel=00ff  base=82e38000  limit=000bffff
es: sel=00ff  base=82e38000  limit=000bffff
fs: sel=010f  base=00000000  limit=0010ffff
gs: sel=010f  base=00000000  limit=0010ffff
ss: sel=00ff  base=82e38000  limit=000bffff
App stack: [000ad02c..0002d02c]  Exceptn stack: [0002cf80..0002b040]

Call frame traceback EIPs:
  0x00003feb ___ls__7ostreamPCc+203
  0x000026f4 _main+252, line 24 of vesainfo.cc
  0x00013c12 ___crt1_startup+178
=======================================================================

Anyone care to venture a guess on this one? I took a quick glance at the
files and didn't see anything obviously revealing ... I off-handedly
seem
to remember this happening with another file, something to do with
dpmi.h
or go32.h ... but I don't really remember. Anyway, for features.h, it
only
croaks like this if features.h is included before fstream.h (say,
through
stdint.h, which is what did it to me).
--
                                              -|-E the Icefalcon