Mail Archives: djgpp/1998/03/07/23:00:25
From: | "Luke Bishop" <lbishop AT calvin DOT stemnet DOT nf DOT ca>
|
Newsgroups: | comp.os.msdos.djgpp
|
Subject: | GCC Bug (HELP ME!!!!!)
|
Date: | 6 Mar 1998 20:41:41 GMT
|
Organization: | The Zone
|
Lines: | 32
|
Message-ID: | <01bd4887$162bdc80$7348a5c6@technoid>
|
NNTP-Posting-Host: | n072h115.thezone.net
|
To: | djgpp AT delorie DOT com
|
DJ-Gateway: | from newsgroup comp.os.msdos.djgpp
|
Sorry for the title and this is probably slightly off-topic, but I found a
NASTY bug in GCC. I don't think it is anything I did, and I don't have the
source to compare to, and I haven't seen 2.8.0 yet, so I don't know if it's
corrected, but here is some code which should probably crash with GCC:
class ThisWillCrash {
public:
void* operator new(size_t mysize)
{
return NULL; // yes NULL, just watch...
}
virtual void thisisvirtual()
{
}
};
main()
{
ThisWillCrash a;
}
I have tracked down the reason:
If the NEW operator returns NULL, the VFTBL (virtual function table)
pointer is still written to the class. All the assembly-dumps seem to
verify this, as well as several of my tests. The Constructor is called
anyway regardless of NULL (which is OK, all that needs doing then is just
checking for this==NULL).
When the default NEW fails in DJGPP, it just dumps to DOS saying "virtual
memory exceeded" or somesuch. NULL is never returned (but the current ANSI
says that it should be).
Thanks for any help...
- Raw text -