turbo c processor fault

[danijohn]

when I exit a function i get 'general protection exception' -' processor fault'. Function writes to file and works ok except won't exit. What does this mean please, and where should I look ? Am using Turbo C 4.5 & Windows xp. Must be overwriting memory somehow I suppose but can't see where. Have increased stack size in .def file- no use.
All suggestions welcome !!

[John A]

Could you post the code you're having trouble with? Most likely you're trying to acess memory you shouldn't be, such as using a pointer that isn't pointing to what you expect it to, but it's kind of hard to guess unless you actually show us what you're trying to do.

[SpS]

when I exit a function i get 'general protection exception' -' processor fault'. Function writes to file and works ok except won't exit. What does this mean please, and where should I look ? Am using Turbo C 4.5 & Windows xp. Must be overwriting memory somehow I suppose but can't see where. Have increased stack size in .def file- no use. All suggestions welcome !!

I think it's waste of time solving your problem for Turbo C. Better get a new compiler Check this link http://www.daniweb.com/techtalkforums/thread50370.html

[jwenting]

His problem is almost certainly not caused by using TC 4.5 (which though old is still somewhat servicable and can produce 32 bit Windows code) but by a bug in his code.

[danijohn]

Thanks for encouraging me to look for coding bug.
You are right. Eventually I traced it to repeated calls to a library routine, fcvt, which converts floats to strings. I didn't expect a problem here because I've used it elsewhere, but not with repeated calls. It seems I have to store the ouput in a static variable. Hence the return addresses getting screwed up, and the bizarre error messages.

[danijohn]

Yes you are right. It turned out to be repeated calls to a library routine, fcvt, that converts floats to strings. The small print which I missed says the ouput must be stored in a static variable. I hadn't, which accounts for the return addresses getting screwed up and the bizarre error messages.

[danijohn]

Thanks for reply. You are probably right that I'm missing some goodies staying with an old compiler, but I don't want the cost of a new one, or learning a new environment.
In spite of the bizarre error messages, it turned out to be a simple coding error.

[Ancient Dragon]

Thanks for reply. You are probably right that I'm missing some goodies staying with an old compiler, but I don't want the cost of a new one, or learning a new environment. In spite of the bizarre error messages, it turned out to be a simple coding error.

cost is no excuse -- some such as Dev-C++ are free.

>> or learning a new environment
If you want to do this as a hobby that's ok. But no company uses that compiler any more.

[jwenting]

and no company uses Dev-C either.

[~s.o.s~]

Depends on what exactly do you mean by a company -- a big time software gaint or a small time budding organization with no more than 10 people.

If the former, then yes, you are correct. But if the latter, then no, I have seen small time companies (like those in embedded development etc.) using free IDE's like Code::Blocks and Dev C++.

[jwenting]

I've also seen 10+ year old software in use in even large (multinational large) companies...
So it's pretty likely that BC 4.5 is in use somewhere to this day, in a similar niche market as your market for DevC...
But with free and cheap versions of major implementations (Borland and Microsoft both for example) being available for commercial use now that's likely to change (though there's a lot more market for BC 4.5 out there than DevC as it can do DOS and 16 bit Windows development, which are handy for things like PLCs).

[WaltP]

C'mon people. C++ is C++ whether TurboC Ver 1 or MSVC.NET (for the most part).

There are a few things you have to keep in mind at high level programming but at basic learning it doesn't matter what compiler you use as long as it's solid. Yes the older compilers don't follow the current standards 100% (but neither do current compilers) but what they implemented was looked at when the standards were adopted.

When compiled, the program from TCver1 works the same as DevC++.

And I can guarantee the problem exists no matter what compiler he uses, so please let's concentrate in the OP's problem rather than an upgrade that produces a non-fix.

JMAO :twisted:

[~s.o.s~]

C'mon people. C++ is C++ whether TurboC Ver 1 or MSVC.NET (for the most part).

Not when you have a deadline to meet, in that case having a really good IDE helps big time.And I can guarantee the problem exists no matter what compiler he uses, so please let's concentrate in the OP's problem rather than an upgrade that produces a non-fix.
A bit correction....lets concentrate on an upgrade that keeps him away from non standard programming.:twisted:

But yes, back on topic,danijohn post your code so we can have a look at it. Maybe then we would be able to help you better.

[John A]

But yes, back on topic, danijohn post your code so we can have a look at it. Maybe then we would be able to help you better.

Which is what I said in the first place.

[Ancient Dragon]

I think the Op's original problem has been solved -- see his post #5 and 6 to this thread.

[~s.o.s~]

Sheesh, missed that, marking this as solved...