bool transition bug (proof and refinement)

1 view
Skip to first unread message

Koen

unread,
Apr 9, 2002, 11:44:02 AM4/9/02
to
I posted this bug already before (27/3), but as I got no
reply I tried to produce it with a simple example. Yhis
way I could refine the specification as "a virtual
unmanaged function that returns a bool will not be treated
correctly when returning false when called by managed
code".

Attached is a very simple example that proves the bug. The
text says "Hello World, what a nice day" but should
return "Hello World, what an awful day"

Removing the virtual before the function makes the program
behave correctly.

Please advise about an elegant way to work around this.

bugcheck.cpp

Koen

unread,
Apr 9, 2002, 12:04:13 PM4/9/02
to
the version I posted is the one that works (without
virtual) so here is the one that doesn't
bugcheck.cpp

David Lowndes

unread,
Apr 9, 2002, 4:51:55 PM4/9/02
to
>Attached is a very simple example that proves the bug. The
>text says "Hello World, what a nice day" but should
>return "Hello World, what an awful day"
>
>Removing the virtual before the function makes the program
>behave correctly.

I can confirm your results, but I've no idea how you'd work around
this. Looking at the disassembly while debugging shows that the EAX
register changes from 0 to 1 during the return (when the function is
virtual).

Can someone from MS have a look at this and comment please.

Dave
--
MVP VC++ FAQ: http://www.mvps.org/vcfaq
My address is altered to discourage junk mail.
Please post responses to the newsgroup thread,
there's no need for follow-up email copies.

Jonathan Caves [MSFT]

unread,
Apr 9, 2002, 6:07:58 PM4/9/02
to
This is due to the way the runtime marshals boolean values. Basically it
assumes that a Boolean is 4-bytes 4 bytes while in C++ it is only 1 byte.

Normally you can get around this by using the MarshalAs attribute to force
the runtime to do the right think but in this case you can't as you cannot
apply a Custom Attribute like MarshalAs to a method that is being compiled
as un-managed.

So in short for Visual C++ .NET there is not, unfortunately, an elagant way
around this issue.

--
Jonathan Caves
Microsoft Corporation

This posting is provided "AS IS" with no warranties, and confers no rights.

"David Lowndes" <dav...@mvps.org> wrote in message
news:62l6buk7sol575jc0...@4ax.com...

David Lowndes

unread,
Apr 9, 2002, 7:26:54 PM4/9/02
to
>This is due to the way the runtime marshals boolean values. Basically it
>assumes that a Boolean is 4-bytes 4 bytes while in C++ it is only 1 byte.

...but it is a bug - isn't it?

Jonathan Caves [MSFT]

unread,
Apr 9, 2002, 8:09:27 PM4/9/02
to
As the program does not execute correctly I would have to say yes. But the
question is where - I think the bug is in the CLR: when they are marshaling
a bool from native to managed they should not assume that the upper 3 bytes
in EAX contain meaningful information. They say we should emit the MarshalAs
attribute to force the CLR to do act as we want it to -- the problem is that
with unmanaged function there is no where for the compiler to attach the
MarshalAs attribute as unmanaged functions don't appear in meta-data.

So yes it is a bug and yes we are aware of it and yes we are going to try to
fix it for the next release.

--
Jonathan Caves
Microsoft Corporation

This posting is provided "AS IS" with no warranties, and confers no rights.

"David Lowndes" <dav...@mvps.org> wrote in message

news:84u6bu4enf993qa5v...@4ax.com...

Sean Kelly

unread,
Apr 9, 2002, 8:24:16 PM4/9/02
to
"Jonathan Caves [MSFT]" <no_spam_...@microsoft.com> wrote in message
news:eGdKLPC4BHA.1344@tkmsftngp04...

> As the program does not execute correctly I would have to say yes. But the
> question is where - I think the bug is in the CLR: when they are
marshaling
> a bool from native to managed they should not assume that the upper 3
bytes
> in EAX contain meaningful information. They say we should emit the
MarshalAs
> attribute to force the CLR to do act as we want it to -- the problem is
that
> with unmanaged function there is no where for the compiler to attach the
> MarshalAs attribute as unmanaged functions don't appear in meta-data.
>
> So yes it is a bug and yes we are aware of it and yes we are going to try
to
> fix it for the next release.

Thanks for that brief glimpse of MS corporate politics at work ;)
Personally, I agree with your argument.

This seems like a potential show-stopper -- any hope for getting a fix in an
upcoming patch rather than waiting for the next release? Alternately, I
suppose a small inline function could be written which evaluates only the
first byte of a bool value and outputs the result? It could be called as
so:

if( eval( um->IsItANiceDay() ) )

Better than changing unmanaged code to use BOOLs in the short-term.

Sean


Jochen Kalmbach

unread,
Apr 10, 2002, 2:54:23 AM4/10/02
to
Sean Kelly wrote:

> "Jonathan Caves [MSFT]" <no_spam_...@microsoft.com> wrote in
> message news:eGdKLPC4BHA.1344@tkmsftngp04...

>> So yes it is a bug and yes we are aware of it and yes we are going to
>> try to fix it for the next release.
>

> This seems like a potential show-stopper -- any hope for getting a fix
> in an upcoming patch rather than waiting for the next release?


This is really a major BUG!!!!
Is there any change to get a path as soon as possible ???
This is really a show-stopper....


--
Greetings
Jochen

Koen

unread,
Apr 10, 2002, 4:01:30 AM4/10/02
to
Seems not so simple as to write an inline function because
even if that inline function is in unmanaged code, it is
still in managed code so that your EAX register gets set
to 1 even before you enter your inline function.
Without changing the original unmanaged code (changing
signature or somehow forcing the EAX register fully to 0)
the only way is to write a dedicated unmanged function
that does the conversion to BOOL or to long. (dedicated in
the sense that it only executes this particular function)
Not as simple as writing an eval function that you can use
over again, you have to write one unmanaged function for
each virtual function you want to call.

>-----Original Message-----
Alternately, I
>suppose a small inline function could be written which
evaluates only the
>first byte of a bool value and outputs the result? It
could be called as
>so:
>
>if( eval( um->IsItANiceDay() ) )
>
>Better than changing unmanaged code to use BOOLs in the
short-term.
>
>Sean
>
>

>.
>

Koen

unread,
Apr 10, 2002, 4:08:59 AM4/10/02
to
This is how I'll work around it. I can change my unmanged
code and I only need to redefine the ase class and not all
derived ones.
bugcheck.cpp

Jochen Kalmbach

unread,
Apr 10, 2002, 4:24:09 AM4/10/02
to
Koen wrote:

But if you have some other LIBs without source code, then you are stuck...

And this is still a really big bug...

--
Greetings
Jochen

Koen

unread,
Apr 10, 2002, 7:41:53 AM4/10/02
to
Yep I agree that it is an important bug, but we have to
live with it for now : you can write the Call_XXX function
in an unamaged part in your client code and take as
parameter the a pointer or ref to the object

#pragma unmanaged

bool Call_IsItANiceDay (Unmanaged *u)
{return u->IsItANiceDay ();}

#pragma managed

>-----Original Message-----
>
>But if you have some other LIBs without source code, then
you are stuck...
>
>And this is still a really big bug...
>
>--
>Greetings
> Jochen

>.
>

Sean Kelly

unread,
Apr 10, 2002, 4:38:41 PM4/10/02
to
"Koen" <k...@remove-this.bvdep.com> wrote in message
news:07b601c1e065$ec7035a0$a5e62ecf@tkmsftngxa07...

> Seems not so simple as to write an inline function because
> even if that inline function is in unmanaged code, it is
> still in managed code so that your EAX register gets set
> to 1 even before you enter your inline function.

So the CLR is actually evaluating a 4-byte memory segment and setting the
register to 0x1, rather than passing 4 bytes to the register, the lowest of
which being the actual bool value? I had assumed that the problem was just
that the CLR was passing 3 bytes of garbage on top of the actual bool, so
the value ended up being some arbitrary integer value. (I don't have VC7
installed yet to test this, thus the guessing).

My function suggestion would have been to write a managed function that
evaluates a bool. But if what you say is true, that would obviously not
work.

> Without changing the original unmanaged code (changing
> signature or somehow forcing the EAX register fully to 0)
> the only way is to write a dedicated unmanged function
> that does the conversion to BOOL or to long. (dedicated in
> the sense that it only executes this particular function)
> Not as simple as writing an eval function that you can use
> over again, you have to write one unmanaged function for
> each virtual function you want to call.

This is terrible. It pretty much eliminates the possibility of integrating
unmanaged library code or existing code with managed C++ code. Any idea why
it is just virtual functions? Even if the function must be evaluated at
run-time, the return type is known at compile-time. I don't see why the
virtual should matter.


Koen

unread,
Apr 11, 2002, 4:15:22 AM4/11/02
to
That is right
I had described the registry behaviour in an earliear post
(27/3) and didn't repeat it here. The EAX is indeed set to
00001 on the ret statement.
For the distinction between virtual and non-virtual I have
no explanation, I saw it in my simple example that it only
went wrong with the virtual.
In the mean while I think that there are other
circumstances that make if fail : I think that it does not
work for members of a class exported from a dll even if it
is not virtual but maybe that was because my function
(that was just a wrapper around the virtual function) was
evaluated as an inline and so maybe the CLR took over too
soon. Anyway I didn't feel much like digging into it
further and defined a non-inline funciton that returns a
long and that is compiled fully in unmanaged. Thay way I
was sure that it would work.

>-----Original Message-----
>So the CLR is actually evaluating a 4-byte memory segment
and setting the
>register to 0x1, rather than passing 4 bytes to the
register, the lowest of
>which being the actual bool value? I had assumed that
the problem was just
>that the CLR was passing 3 bytes of garbage on top of the
actual bool, so
>the value ended up being some arbitrary integer value.
>

>


>This is terrible. It pretty much eliminates the
possibility of integrating
>unmanaged library code or existing code with managed C++
code. Any idea why
>it is just virtual functions? Even if the function must
be evaluated at
>run-time, the return type is known at compile-time. I
don't see why the
>virtual should matter.
>
>

>.
>

Brandon Bray [MSFT]

unread,
Apr 11, 2002, 12:48:23 PM4/11/02
to
Jochen Kalmbach wrote:
>
> This is really a major BUG!!!!
> Is there any change to get a path as soon as possible ???
> This is really a show-stopper....

If no one has done so already, this should be reported to product support.
They're the only ones who can supply patches outside of service packs. And
given the nature of this bug, product support is better equipped at finding
solutions.

--
Brandon Bray Visual C++ Compiler, CRT, and STL Program Manager

Mike

unread,
Apr 11, 2002, 8:23:04 PM4/11/02
to
Brandon Bray [MSFT] wrote:

>Jochen Kalmbach wrote:
>>
>> This is really a major BUG!!!!
>> Is there any change to get a path as soon as possible ???
>> This is really a show-stopper....
>
>If no one has done so already, this should be reported to product support.
>They're the only ones who can supply patches outside of service packs. And
>given the nature of this bug, product support is better equipped at finding
>solutions.

Better equipped at finding solutions than the ones building the
compiler?!

Feel free to elaborate.

/Mike

Brandon Bray [MSFT]

unread,
Apr 11, 2002, 8:39:15 PM4/11/02
to
Mike wrote:
>
> Better equipped at finding solutions than the ones building the
> compiler?!
>
> Feel free to elaborate.

Not exactly. We can make a big fuss about getting the right people to fix
it, but product support has the voice of the customer. That customer voice
goes a long ways around here, especially when resolving issues that span
several teams. Another factor is that product support can supply fixes to
you directly -- the product team cannot.

So, basically I'm giving you the most efficient, effective way of seeing
this particular problem resolved -- both for you and me.

Thanks for asking for clarification. I hope that helps!

Mike

unread,
Apr 11, 2002, 10:31:08 PM4/11/02
to
Brandon Bray [MSFT] wrote:

>Mike wrote:
>>
>> Better equipped at finding solutions than the ones building the
>> compiler?!
>>
>> Feel free to elaborate.
>
>Not exactly. We can make a big fuss about getting the right people to fix
>it, but product support has the voice of the customer.

Even more than customers themselves have here (in this NG)?

>That customer voice goes a long ways around here, especially
> when resolving issues that span several teams.

OK. But in cases where it only "spans" one team, the C++ compiler
team, would it really be better to (try to) contact the (sometimes
technically inadept) "product support" than to report bugs and
possibly be presented workarounds from the ones implementing the
compiler?

I understand that for the more vague problems it's good to have the
"support" as a first, second and third line of defense, but if the
problem is already displayed in this NG and the people working on the
compiler both read about the problem and are in position to file a
bug, wouldn't this be the most efficient way to both report the bug
and possibly get a workaround?

> Another factor is that product support can supply fixes to
>you directly -- the product team cannot.

Ehhh, I've reported quite a few bugs through the years and been
invited to a few beta-test for a few MS products, but not once have
I've been offered a non-sp compiler that fixes a problem. Do "product
support" really ever supply such updates?

/Mike

Brandon Bray [MSFT]

unread,
Apr 11, 2002, 10:48:55 PM4/11/02
to
Mike wrote:
> > ... but product support has the voice of the customer.

>
> Even more than customers themselves have here (in this NG)?

Most of the time it doesn't matter... for this issue, it does.

> OK. But in cases where it only "spans" one team, the C++ compiler
> team, would it really be better to (try to) contact the (sometimes
> technically inadept) "product support" than to report bugs and
> possibly be presented workarounds from the ones implementing the
> compiler?

If you're willing to wait for a service pack, then dealing with us in the
newsgroup is a perfect way of reporting issues. If you need an immediate fix
(and have the necessary support contract), then working with product support
is a necessity. I think this particular issue is not the usual case, and one
that product support is really much better prepared to handle.

> I understand that for the more vague problems it's good to have the
> "support" as a first, second and third line of defense, but if the
> problem is already displayed in this NG and the people working on the
> compiler both read about the problem and are in position to file a
> bug, wouldn't this be the most efficient way to both report the bug
> and possibly get a workaround?

When a problem comes to us through product support, it sounds like, "A
customer has this problem, give us the fix tomorrow." When it comes through
the newsgroup, it can sound like, "A customer found this problem, we really
should fix it in the next version." While the C++ team tends to have more
interaction in the newsgroup, and therefore has a better understanding of
what to fix now, tomorrow, next week, and next year. Other teams that are
just now getting used to participating in the newsgroup don't have the
understanding and experience to realize your bug reports are just as
important as those that come through product support.

> Ehhh, I've reported quite a few bugs through the years and been
> invited to a few beta-test for a few MS products, but not once have
> I've been offered a non-sp compiler that fixes a problem. Do "product
> support" really ever supply such updates?

It depends on the support contract. It certainly is done -- check out what
support contracts are available if you think you need this.

Hope that helps!

Mike

unread,
Apr 12, 2002, 12:57:48 AM4/12/02
to
Brandon Bray [MSFT] wrote:

>When a problem comes to us through product support, it sounds like, "A
>customer has this problem, give us the fix tomorrow." When it comes through
>the newsgroup, it can sound like, "A customer found this problem, we really
>should fix it in the next version."

OK. I didn't know that. I was under the impression that everything
reported to/by them (the 1:st-3:rd line of defense) was at the
earliest postponed to the next sp, but where applicable preferrably
the next release (to keep the customers waiting). That has at least
been my impression with MS the last 10 years, except for the few times
I've been in _direct_ contact with e.g. NT kernel devels where I've
even been woken up by a delivery-boy with a freshly burnt CD "Here you
go - sign here.".

> While the C++ team tends to have more
>interaction in the newsgroup, and therefore has a better understanding of
>what to fix now, tomorrow, next week, and next year. Other teams that are
>just now getting used to participating in the newsgroup don't have the
>understanding and experience to realize your bug reports are just as
>important as those that come through product support.

Then you have quite a responsibility here to educate them, eh? :-)

I hope you make progress and that they understand that "The developers
we meet here are often more technically adept (since they apparently
know what NNTP is)".

>> Ehhh, I've reported quite a few bugs through the years

[...]


>It depends on the support contract.

Oh. That might explain it. As merely an invited tester of to try to
ensure the quality of MS products I obviously had no need for a
"support contract", and if I ever had it I'm sure I couldn't afford
it. Thanks however for telling me there is such a thing (even that it
might be unreachable).

/Mike

David Lowndes

unread,
Apr 12, 2002, 2:55:27 AM4/12/02
to
>>It depends on the support contract.
>
>Oh. That might explain it. As merely an invited tester of to try to
>ensure the quality of MS products I obviously had no need for a
>"support contract", and if I ever had it I'm sure I couldn't afford
>it. Thanks however for telling me there is such a thing (even that it
>might be unreachable).

It's a little sad, but that's the way of the world. I had a problem
with something that didn't work under NT4 which had been fixed in
2000. I couldn't get a fix from MS, but once our end customer (I think
it was Exxon) filed a bug about it, there was an emergency quick fix
available! :)

koen

unread,
Apr 12, 2002, 9:12:14 AM4/12/02
to

>-----Original Message-----
>
>I hope you make progress and that they understand
that "The developers
>we meet here are often more technically adept (since they
apparently
>know what NNTP is)".
>

Hmmmm, Can I feel ok that I just use the plain web
interface ? ;-) It's been years since my newsreader was
last configured correctly. Have been using dejanews (now
google) and MS's own web interface for all postings and
more yet for searching ....
I don't think we've got the right support contract either.
I'll wait for the next SP

Cheers
Koen

Sean Kelly

unread,
Apr 12, 2002, 11:20:09 AM4/12/02
to
"Brandon Bray [MSFT]" <bran...@online.microsoft.com> wrote in message
news:eN9Fnxc4BHA.2092@tkmsftngp07...

>
> When a problem comes to us through product support, it sounds like, "A
> customer has this problem, give us the fix tomorrow." When it comes
through
> the newsgroup, it can sound like, "A customer found this problem, we
really
> should fix it in the next version." While the C++ team tends to have more
> interaction in the newsgroup, and therefore has a better understanding of
> what to fix now, tomorrow, next week, and next year.

I just wanted to say that the VC++ team's presence here is an incredible
boon. Thanks for taking the time out to listen to us.

> Other teams that are
> just now getting used to participating in the newsgroup don't have the
> understanding and experience to realize your bug reports are just as
> important as those that come through product support.

That they are. And often communicated more clearly, I'd think, as some sort
of dialogue can be part of the process.


Sean


Sean Kelly

unread,
Apr 12, 2002, 11:23:02 AM4/12/02
to
"David Lowndes" <dav...@mvps.org> wrote in message
news:ov0dbukf33t2lksuj...@4ax.com...

> >>It depends on the support contract.
> >
> >Oh. That might explain it. As merely an invited tester of to try to
> >ensure the quality of MS products I obviously had no need for a
> >"support contract", and if I ever had it I'm sure I couldn't afford
> >it. Thanks however for telling me there is such a thing (even that it
> >might be unreachable).
>
> It's a little sad, but that's the way of the world. I had a problem
> with something that didn't work under NT4 which had been fixed in
> 2000. I couldn't get a fix from MS, but once our end customer (I think
> it was Exxon) filed a bug about it, there was an emergency quick fix
> available! :)

And how much they listen depends on the degree of that support contract. I
remember my team reporting bugs in SQL 6.0 to MS and for months they
wouldn't believe that they existed until other people started reporting the
same problems. It's much nicer to be able to communicate directly to the
dev team at times.


David Lowndes

unread,
Apr 12, 2002, 12:24:11 PM4/12/02
to
>It's much nicer to be able to communicate directly to the
>dev team at times.

That's my feeling too. Much more satisfactory than potentially getting
your problem garbled by intermediaries.

So, VC++ team, please keep up the good work here!

Reply all
Reply to author
Forward
0 new messages