Lost support for +inf and NaN

[zarnon]

Until recently, lines similar to the following caused no problems in my project.

double test = 0, test2, test3;

test2 = 10/ test; //test2 = +Inf
test3 = test * test2; //test3 = NaN

Now, operations that evaluate to Inf or NaN are causing fatal Double faults.

If I just highlight an expression that evaluates to Inf or NaN, I get a Genral Protection fault and the debugger exits.

Oddly enough, PositiveInfinity() and NotANumber() work fine.

Does anyone know a way to get around this?

[menchar]

I guess I'm surprised divide by zero doesn't always cause an exception, and since you can't write an exception handler in CVI C, it never gets handled and hits the environment and the OS kills the app.

Are you using CVI 8.5? 

NI was considering making changes to the compiler to include C99 floating point features.  I believe C99 defines enhanced support for IEEE floating point.  But to use the new features you have to use a pragma to enable them, assuming 1) NI changed this part of the compiler and 2) It's faulty compiler code.

I wonder what happens if you use the excepting expression in the IsNotANumber ( ) ?  Or   IsInfinity ( ) ?

Menchar

[zarnon]

I'm using CVI 8.5, but #pragma iso_9899_1999 doesn't solve the problem.

Using the expressions in IsNotANumber() and IsInfinity() also gives a Double fault.

I've found that the expressions are fine if I use them at the start of my code, but using them later on causes faults, so it's actually something happening at runtime that is messing it up.

[J_Stape]

Hi zarnon,

I tried to reproduce this behavior on my machine, but wasn't able to do so.  Can you attach a simple sample program that demostrates this behavior?  In your example code, can you please insert the divide by zero statement in two places - where it works and where it causes a run-time error.

Also, did you make any changes to your compiler warnings and errors?  What debugging levels are you using?

[zarnon]

I managed to narrow it down to a call I make to LoadLibrary(), which means it's related to another problem I had earlier with DisplayPanel().

This time however, I discovered that it's specific to the dlls I'm loading.  LoadLibrary() doesn't cause a problem if I use it on any other dll, nor is there a problem if I load one these dlls statically.  Unfortunately, the dlls have functions with the same prototype, so I have to load at least one at runtime to be able to tell the difference between them.

I figure this is either something strange with the company's code (the same company made both dlls), or it's because the dlls were created with Borland.

I attached a simple program if you want to check it out.

[J_Stape]

Hi zarnon,

I tested your sample program and saw the same behavior.  This does not appear to be an issue with CVI, however.  I can replicate the same problem using Visual Studio.

I tried loading other DLLs (not those you provided) and the program worked fine.  I also created a DLL in CVI with Borland compatibility mode, and that too did not cause this issue when loaded.

Therefore, this issue does seems to be caused by your DLLs, but is not an issue specific to CVI.  As suggested above, it is always a good programming practice to perform error checking to avoid things like dividing by zero.

[zarnon]

Well, at least it broke for you too, so I know it's not machine specific.

The division by zero happens inside a mess of physics equations when the user does something foolish, so it was nice letting CVI catch this stuff quietly without me having to hunt it down.

I guess at some point we all have to earn our paychecks the hard way.

Thanks for your help!