469,910 Members | 1,496 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,910 developers. It's quick & easy.

Virtual bool bug in VS2005 ?

Hello,

Does anyone know if the "virtual bool bug" is still present in VS2005 when
calling between managed and unmanaged code?

Thanks

Kevin
Nov 17 '05 #1
5 966
Kevin Frey wrote:
Hello,

Does anyone know if the "virtual bool bug" is still present in VS2005
when calling between managed and unmanaged code?


No, it's fixed.

-cd
Nov 17 '05 #2
Carl Daniel [VC++ MVP] wrote:
Kevin Frey wrote:
Hello,

Does anyone know if the "virtual bool bug" is still present in VS2005
when calling between managed and unmanaged code?


No, it's fixed.


The good question being : where has it been fixed? In the compiler or in the
..NET runtime ;-)

Arnaud
MVP - VC
Nov 17 '05 #3
Hi Arnaud!
Does anyone know if the "virtual bool bug" is still present in VS2005
when calling between managed and unmanaged code?


No, it's fixed.


The good question being : where has it been fixed? In the compiler or in the
..NET runtime ;-)


The compiler was not the problem... the problem occured during the
unmanaged-to-managed transition, so it must be fixed in the .NET-Framework.
For the VC7(.1) bug see:
http://www.codeproject.com/buglist/virtualboolbug.asp

I just can remember the reason for this bug: The compiler and the
framework team discussed who should solve the problem (and then they
forgot to solve it :-) )

The CLR team said the "bool(ean)" is 4 bytes and the C++-teams says
"bool" is 1-byte.
And I think it was hard for the C++-team to change the size of bool from
1 to 4 ;-)

Therefor the C++-team has done everything correct...
So for VC8 the C++-team still just set the lower 8-bit of the
EAX-register (called AL).
And the conversion from AL to EAX (1-byte to 4-byte) is done by the
..NET-Framework (mscorwks!PInvokeCalliPostCall).

So the CLR-team has done the conversion...
PS: But for the VC7.1 bug it seems that the C++-team had to solve the
bug (see: http://support.microsoft.com/kb/823071/en-us)

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/
Nov 17 '05 #4

Jochen Kalmbach [MVP] wrote:
Hi Arnaud! Hello Jochen,

The good question being : where has it been fixed? In the compiler or in the
..NET runtime ;-)


The compiler was not the problem... the problem occured during the
unmanaged-to-managed transition, so it must be fixed in the .NET-Framework.
For the VC7(.1) bug see:
http://www.codeproject.com/buglist/virtualboolbug.asp

I just can remember the reason for this bug: The compiler and the
framework team discussed who should solve the problem (and then they
forgot to solve it :-) )


Yep : that's why I ask the question ;-)
The CLR team said the "bool(ean)" is 4 bytes and the C++-teams says
"bool" is 1-byte.
And I think it was hard for the C++-team to change the size of bool from
1 to 4 ;-)


What is really strange (with framework 1.0 and 1.1) is that, during the
transition return from unmanaged to managed, if the 3 upper bytes of
EAX are !=0, then the framework sets EAX=0x1 (at least, it is how I
have understood the problem...)

Arnaud
MVP - VC

Nov 17 '05 #5
Hi adebaene
What is really strange (with framework 1.0 and 1.1) is that, during the
transition return from unmanaged to managed, if the 3 upper bytes of
EAX are !=0, then the framework sets EAX=0x1 (at least, it is how I
have understood the problem...)


Thats not strange, thats the conversion from "4-byte-value" to
"System::Boolean"...

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/
Nov 17 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by A. Saksena | last post: by
7 posts views Thread by Frank-René Schäfer | last post: by
8 posts views Thread by Floogle | last post: by
12 posts views Thread by mijobee | last post: by
11 posts views Thread by Chris Thomasson | last post: by
1 post views Thread by Waqarahmed | last post: by
reply views Thread by Salome Sato | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.