Click here to Skip to main content
15,868,340 members
Please Sign up or sign in to vote.
5.00/5 (2 votes)
See more:
Issue in WIN-8 64-bit (Divide by zero exception)

1. Application is made using Embarcadero Builder XE - 6.
2. Application setting changed to locale DE(German) and found working fine in all OSs(WIN XP, WIN-7, WIN-8 64-bit)
3. If Application setting changed to locale english(United State), it works fine in XP,WIN7 but fails in WIN-8 64-bit.(FYI: WIN-8 machine is installed as English).
4. Issue is divide by zero exception.
5. Divide by zero gives -NAN, where the s/w is working fine. But why throwing exception(Abnormal program termination) in WIN-8 64-bit only in English while German version is working fine(I kept log in place of exception and found it's converting to -NAN by which it's not throwing exception).
6. I want to know why the behavior is changing from one locale to another?

Example:

double x = 0.0, y = 0.0;

double z = x/y;

Run the program in WIN-8 64bit and WIN XP.
Change the locale settings to German in IDE, build and check.
Posted
Updated 30-Sep-14 5:56am
v2
Comments
BillWoodruff 30-Sep-14 11:42am    
Are you aware this is Forum for C# .NET related questions ?
Subrat 4708266 30-Sep-14 11:44am    
I don't know, how to move to C++ windows?
BillWoodruff 30-Sep-14 13:35pm    
My apologies, Subrat, it seems that when you (or whatever) tagged your post "C#" that means it shows up if I select the C# menu-option under the QA main menu.

I did not mean to side-track your question !
Sergey Alexandrovich Kryukov 30-Sep-14 11:52am    
Why? I found this question in a general Q&A forum. The question is perfectly legitimate (but incomplete).
—SA
BillWoodruff 30-Sep-14 12:11pm    
If the OP is developing in Embarcadero in C++ and using, I assume, Borland's compiler, isn't it possible the compiler is emitting different code than would be produced in C++ in .NET ? And, this is the C# forum in QA, not the C++ forum.

Is it possible to program in Embarcadero in C# and compile against .NET ? I dunno !

1 solution

First of all, I really, really appreciate your struggle for using of the "special values" -Inf, +Inf and NaN. I just voted my 5 for this fundamental and practically very important question.

There are two behaviors: throwing exceptions (which are hard-coded exceptions thrown by the CPU's FPU) or not; in second case, those values should be used. The x86, x86-64 and IE64 architectures have the feature to switch this modes of operations on and off, but the question is: how to do it in a standard way?

I found it!

This include file <cfenv> or "fenv.h", provides the way to define floating-point exception behavior: http://www.cplusplus.com/reference/cfenv[^].

For Microsoft, there is the C++ compiler switch: http://msdn.microsoft.com/en-us/library/e7s85ffb.aspx[^].

Now, from your observations, if only they are correct, I couldn't stand one conclusion: Windows sucks. Linux is also not good enough, because the default is to throw the exceptions. But what to do? For a workaround, explicit floating-point exception mode should be set.

Now, some background:

As I say, The x86, x86-64 and IE64 architectures have the feature to switch this modes of operations on and off, which can be done, with C++, using the inline Assembly, which would kill the platform portability of code. Moreover, it's apparent that on the level of CPU instructions, the option will be set for a current thread, so different threads could use different options.

If exception is not thrown, some arithmetic operations will return "special values" −Inf, +Inf or NaN. They are defined in the standard IEEE 754, along with their semantics: http://en.wikipedia.org/wiki/IEEE_floating_point[^].

This is a very important feature of the standard for floating-point numbers, operations and devices implementing floating-point semantics. Without them, such object would not form a formal closed algebra. With those "special numbers", the set of floating-point numbers does form such algebra, which is different from the algebra of "real numbers", as it is understood mathematics. The root of such a "special" computer algebra is simple: it's impossible to represent the continuum using any finite-set machine, such as a computer:
http://en.wikipedia.org/wiki/Continuum_%28set_theory%29[^],
http://en.wikipedia.org/wiki/Real_numbers[^],
http://en.wikipedia.org/wiki/Finite-state_machine[^].

Now, the situation you described looks way too ugly. I never expected that, but the simple check of the default behavior is very frustrating. I clearly remember: quite a while ago, with Microsoft OS and C++ compiler, floating-point division by default always thrown exception. Presently, the default is to return NaN (which is presented as a string in the most ugly way). Better, buy how can we trust the compiler then? In .NET, it was always so-so: there is only one option, to return NaN with no exception. It is much better, because those who want the exception, can always do the check up (at some cost, unfortunately) and throw their own exceptions. Still, this is a viable solution. Yes, I did not test Mono though, and now I'm afraid of testing it :-). This is all way too frustrating.

[EDIT]

I forgot to reference one useful article: http://www.johndcook.com/IEEE_exceptions_in_cpp.html[^].

First of all, I did not do it, because the author provided good recommendation on using floating-point "Infs" and "NaNs", managed to say no a word on the topic we are discussing. But advice on testing values is useful.

—SA
 
Share this answer
 
v6
Comments
Maciej Los 30-Sep-14 17:13pm    
WOW!
+5!
Sergey Alexandrovich Kryukov 30-Sep-14 17:14pm    
Thank you, Maciej.
—SA
Subrat 4708266 30-Sep-14 19:26pm    
I'll try the soln. provided by you. But my major concern lies in locale independent operation. I am runing the build in same CPU architecture. Where it's giving NAN for German build and Exception for English. I'm just changing the locale option in the project settings. Other options remains same for getting German/English build.

One more observation I can add to above comment.
NAN can be checked as follows.

if(result == result)
Not a NAN/ Valid operation
else
NAN
means if you compare NAN with NAN using same variable, it fails to indicate it is not a number. Generally if you will see, always x==x should be true. But that is not the case in case of NAN.
Sergey Alexandrovich Kryukov 30-Sep-14 19:46pm    
Of course this locale-dependent behavior you detected is ridiculous. But try to specify the behavior explicitly.
—SA
Subrat 4708266 30-Sep-14 20:02pm    
Brief:
I have kept log to track what is value of numerator and denominator. And also the resultant division.
Ex:
double x = 0.0, y = 0.0, z = 0.0;
x=GetX();
LOG(x);
y=GetY();
LOG(y);
z=x/y;
LOG(z);

Experiment-1
Steps:
1. Change the project setting->Locale to German
2. Build the application
3. Run in WIN-8 64 bit English OS.
4. S/W Works fine.
5. In log, I am finding y=0, z = NAN. Because of this NAN, it's not throwing exception.

Experiment-2(Frustrating)
Steps:
1. Change the project setting->Locale to English United State
2. Build the application
3. Run in WIN-8 64 bit English OS.
4. S/W throws exception.
5. Collected the log and found, y=0. Then no log about z, because of crash. During evaluation of z, it's throwing exception.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900