Re: Divide by 0 - exception thrown?
Jason Doucette wrote:
David, thanks for your story. It's great to hear about real world
experiences like this.
A few questions:
1. You said, "the moral was: always check for divide by zero rather
than relying on the standard behavior." But, how do you check for
divide by zero, when checking denominator != 0.0 is not sufficient to
prevent an overflow? In reality, you wish to prevent an overflow,
not merely prevent a divide by 0.
I think you can avoid the check by ensuring that FP exceptions are masked
(see below).
2. It appears your story implies an astonishing fact: That the FP
status is not maintained per thread / process. Is this really true? That
means even if I modified the FP exception masking, then I could
start crashing other software on the machine that expects the default
status. In fact, two pieces of software could be fighting back and
forth attempting to set the exception masking as they see fit. Thus,
it would seem that the proper behaviour of any application is to: A.
not change the FP exception masking, and B. not assume the FP
exception masking is set to default.
FP status is indeed maintained on a per-thread basis. The issue is that
many applications install "hooks" and other forms of parasites that actually
run in the context of your thread. In the case of printing, all of the code
to support the printer dialogs, and possibly even some (or all) of the
rasterization code used in producing the printed image runs in the context
of your thread. If that code changes the mask and doesn't change it back
when it's done, then you have a problem. (Incidentally, I'm not surprised
that it was an HP printer - their drivers are the most overly complex and
bug-ridden of any printer out there). You _should_ be able to keep things
under control by being sensitive to where you call out to large, complex
code that might change things, and put them back yourself when you're done.
3. On the CodeGuru forums (
http://www.codeguru.com/forum/showthread.php?p=1472920 ) it was
stated that "By default, floating point exceptions are turned on. ...
and the VC++ standard library happens to turn them off." Thus, this
would indicate that whenever a program that is compiled with VC++ is
run, it changes the default behaviour until another application
changes it back. Can this possibly be true?
Not exactly. As I mentioned, the status is maintained on a per-thread
basis. The VC++ CRT masks exceptions for your thread and it won't ever
change back unless code running on your thread changes it.
-cd