Comparing to float.NaN throws ArithmeticException

We have a DLL compiled under Borland C++ Builder 5 calling an exported C 
entry point in a Mixed Mode Managed C++ DLL. This function in turn calls 
functions in a C# assembly. The application executable is also compiled 
by Borland.

We encountered an ArithmeticException thrown from the 
System.Drawing.Font constructor, and using a disassembler, found it to 
be on the line:

if (((emSize == float.NaN) || (emSize == float.NegativeInfinity)) || 
(((emSize == float.PositiveInfinity) || (emSize <= 0f)) || (emSize > 
float.MaxValue)))

in the function

private void Initialize(FontFamily family, float emSize, FontStyle 
style, GraphicsUnit unit, byte gdiCharSet, bool gdiVerticalFont)

So, we pulled out the line into our own C# code, where it still throws 
an exception, and narrowed it down to the portion:

(emSize == float.NaN)

This expression throws an ArithmeticException exception with the message 
"Overflow or underflow in the arithmetic operation." The rest of the 
comparisons work correctly, and assigning float.NaN to a variable also 
works, but then trying to compare that variable to another throws the 
exception.

However, if I change the statement to float.IsNaN(emSize), it doesn't 
throw an exception. The docs for float.NaN say:
"Use IsNaN to determine whether a value is not a number. It is not 
possible to determine whether a value is not a number by comparing it to 
another value equal to NaN."

So, is Microsoft violating their own rules here?

Also, if I try a literal comparison, e.g. (15 == float.NaN), this does 
not throw.


So, what could be going wrong? When the code is called from an unmanaged 
DLL compiled with Microsoft's compiler, we don't have this problem. So 
it seems that Borland is doing something differently that causes this 
problem. Any ideas what this could be, or any way we can get around it?

thanks

Ok, here's some more info. The second time this is attempted, it works.
So it seems like Borland is somehow not doing something it should to
initialize the floating point system? Is there some way I can ensure
that it will be initialized without triggering the exceptions and
ignoring it?




exported C
calls
compiled
to
throws
message
also


to
does
unmanaged
So

it?

Hi Dave,

Thank you for your posting. Regarding on the issue, we'll try 
finding proper resource to assist you and we will update as soon as posible.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security(This posting is provided "AS IS", 
with no warranties, and confers no rights.)

Here's something else interesting. If I try to do the same comparison
from managed C++ like this:

System::Single x = 15;
bool b = (x == System::Single::NaN);

Not only do I get the same exception being thrown, but I get the
compiler warning "warning C4756: overflow in constant arithmetic" on
the second line.

The reason I have this code is to trigger the first exception and
ignore it, letting subsequent attempts work corretly. So, the full code
is this:

try {
	System::Single x = 15;
	bool b = (x == System::Single::NaN);
}
catch (...)
{
}

It works, but in addition to the warning above, I also get a "warning
C4702: unreachable code" on the closing brace of the catch statement,
which doesn't seem to make sense




posible.
IS", 

Hi

Based on my understanding, if we use the == to compare a float with 
float.IsNaN will get exception in VS.NET C#/C++.

[C#]
float f=1.0f;
if(float.NaN ==f)
	Console.WriteLine("Helo");
float.IsNaN(f);

[MC++]
int _tmain()
{
                Console::WriteLine(S"Hello World");
	System::Single x = 15;
	bool b = (x == System::Single::NaN);
	Console::WriteLine(b);
	return 0;
}

But I can not reproduce the problem on my side with code above.
Or do you mean that the problem only occur when you do this in a 
BorlandCompiled C++ dll?
If so, I think you may also try to post the problem in the Borland's 
support web page as below.
 http://www.**--****.com/ 
 http://www.**--****.com/ 

If I have any misunderstanding, please feel free to let me know.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

The problem occurs in a C# dll or a Managed C++ dll, compiled by
microsoft's compiler. The problem seems to only occur when that dll is
loaded by an application that is compiled with Borland's compiler. I
don't know if this is specific to Borland's compiler, but it seems like
there should be a way to make the managed code work the same regardless
of the code that calls it.

Hi Dave,

So the problem occurred when the C#/MC++ dll compiled with MS compiler is 
called by a Borland C++ Builder 5 compiled Application.
Since we did not known how the Borland compiler works, I think the Borland 
compiled code is not same with the VC++ compiled one, that is why I suggest 
you contact Borland, I think they can investigatet why the exception will 
occur.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

I have posted to a Borland newsgroup as you suggested.

However, I'm still not quite sure you understand the problem. The
exception does not occur when the code is called, all of that works
correctly. Once inside of the managed code however, floating point
operations behave differently. Once inside the managed code, we're
executing the same instructions as if the function had been called by
an executable compiled by any other compiler (I would assume... I
suppose the JIT compiler could be behaving differently, which seems
like it would be an even bigger problem).

The only explanation I can think of is that there are certain steps
that take place at application initialization to somehow set up
floating point arithmetic that are either not being done or being done
differently. I can contact Borland and ask them "What does your
compiler do differently than Microsoft's", but that doesn't really help
me, and I think it's much more eefficient to ask you "What sort of
initialization steps must take place before perforoming floating point
operations in a Managed Assembly"? Whatever these steps are, they seem
to occur before the second time I try to reproduce the issue above, so
triggering the exception seems to be one way of ensuring that
everything is properly initialized, but it also seems like a lousy way
to do that.

Also, I think it is a bug that System.Drawing.Font is using == to test
for NaN instead of float.IsNaN, since the documentation explicitly says
you are not allowed to do that.

Thanks for your help,
Dave

Hi

Thank you for your reply.
So I assume your scenario is as below.
Borland compiled C++ app---> C# DLL registered as COM(using 
System.Drawing.Font) will get the exception
MS VC6 app                         ------>the same C# DLL registered as COM 
with above will work fine.

The two tests ran on the same environment.

And I assume that you are using the same C++ source code and the only 
difference is that we use two compilers.

So I guess the possiblity is that we will use two versions of CRuntime, as 
we know that it is the CRuntime that load the main function in the C++ 
source which may make the different, since the following steps, load 
COM,clr, JIT is handled by the same library on the windows machine and that 
is why I recommend that you contact Borland.

Also since the problem needed further detailed troubleshooting to see what 
is the problem(e.g. dump analyse), I think you may also try to contact 
MSPSS via the link below.
 http://www.**--****.com/ 

If we confirm that this is a problem in our product, the incident fee will 
be refund.

Thanks for your understanding!
If you still have any concern, please feel free to post here.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

Hi

In addition, for the issue,

We will write email to product group on it.

Many thanks for your feedback.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.