Xref: news-dnh.mv.net comp.os.msdos.djgpp:4217 Path: news-dnh.mv.net!mv!barney.gvi.net!news.netrail.net!imci2!newsfeed.internetmci.com!howland.reston.ans.net!agate!islay.ssl.berkeley.edu!korpela From: korpela AT islay DOT ssl DOT berkeley DOT edu (Eric J. Korpela) Newsgroups: comp.os.msdos.djgpp Subject: Re: (none) Date: 9 Jan 1996 19:58:44 GMT Organization: Cal Berkeley-- Space Sciences Lab Lines: 33 Message-ID: <4cuhdk$ebc@agate.berkeley.edu> References: NNTP-Posting-Host: islay.ssl.berkeley.edu To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp In article , dunder wrote: > >We are currently making a relatively big program in C++. We wrote it in >Turbo C++. We arranged it so it could be compiled within GCC (dj's) (ie >arranging the random() pow(long, long) and itoa() [wich we had to redo >;)] but it seems that GCC doesn't support it. It compiles well, without >warnings but the executable doesn't work (its NOT a renamed COFF file ;)) >It bugs 'at start'. Go32 v1.11.maint4 reports: > >Segment violation in pointer 0x00000000 at d8:de81 > >It works fine compiled with TC... Is this error sent by a particular bug >en DJGPP or by some 'TC supported' functions or syntax that GCC handles >badly? Thanx You're looking for a bug in the wrong place. The bug isn't in djgpp, the bug is in your program. At some point in your program you are dereferencing a NULL pointer. Turbo C didn't catch the bug because there is no memory protection in real mode. Turbo C will let you smash the interrupt table with reckless abandon. The easiest way to find the bug is to use the debugger. It should be able to tell you where the error happened. Eric -- Eric Korpela | An object at rest can never be korpela AT ssl DOT berkeley DOT edu | stopped. Click here for more info.