Bug 157153 - bool true gets converted to integer 8
bool true gets converted to integer 8
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: boost (Show other bugs)
12
All Linux
medium Severity medium
: ---
: ---
Assigned To: Benjamin Kosnik
bzcl34nup
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-07 14:14 EDT by John Smith
Modified: 2013-08-09 01:47 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-09-14 14:38:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
testcase (628 bytes, text/plain)
2005-05-07 14:14 EDT, John Smith
no flags Details
Test case. (610 bytes, text/plain)
2007-10-09 07:40 EDT, Petr Machata
no flags Details
Test case. (515 bytes, text/plain)
2007-10-09 07:44 EDT, Petr Machata
no flags Details

  None (edit)
Description John Smith 2005-05-07 14:14:07 EDT
Description of problem:
Converting true to an int must yield the value 1, according
to the standard.  The attached program shows that in a certain
situation gcc converts true to other values than 1.

Version-Release number of selected component (if applicable):
gcc-3.4.3-22.fc3

How reproducible:
Always.

Steps to Reproduce:
1.  Type
  g++ foo.cpp -o foo
2. Then type
  ./foo
  
Actual results:
8

Expected results:
1

Additional info:
1) The bug does not happen if you use -O2 or -O9.
2) With gcc 3.3.4 it also happens if you use -O2 (but it
does not if you use -O9).
3) The bug has been reported to happen also with gcc 4.0.
4) 8 is not a special number.  In a closely related
situation I was getting 191.
5) The attached program uses boost (I am using the
package boost-devel-1.32.0-5.fc3), and boost might
happen to be buggy, but this is really a gcc bug.
In no situation should gcc convert a bool to any
integer other than 0 or 1.
Comment 1 John Smith 2005-05-07 14:14:07 EDT
Created attachment 114125 [details]
testcase
Comment 2 John Smith 2005-05-07 14:23:03 EDT
I take my last comment back: I don't know if it's a gcc bug
or a boost bug.
Comment 3 Jakub Jelinek 2005-05-10 04:44:47 EDT
I think you trigger undefined behaviour, because there is no sequence
point at | in:
            b = (ch_p(':')[assign_a(mybool, false)] |
                                 eps_p[assign_a(mybool, true)]);
so expecting that mybool will be true is a wrong expectation.

I don't know boost at all (that's why I'm reassigning the bug), but
under the debugger I see the actors that actually do the assignment
(boost::spirit::assign_action::act<bool, bool> (bool &, const bool &) in
this case) is called far after the definition method has left, yet it uses
references to definition's local variables.
Comment 4 Matthew Miller 2006-07-10 17:06:14 EDT
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!
Comment 5 John Smith 2006-11-13 09:13:05 EST
Same bug in current FC5.
Comment 6 Benjamin Kosnik 2006-11-14 11:03:37 EST
Same bug FC6.
Comment 7 Benjamin Kosnik 2006-11-15 13:55:05 EST
This is undefined behavior. Results are very strange, however. I do think that
the -O0 behavior is a gcc bug. 

-O2
%./a.out 
0

-O1
%./a.out 
1

-00
%./a.out
8
Comment 8 John Smith 2006-12-21 02:59:43 EST
I do not think that the behavior is undefined.  The source code seems to me to
be perfectly compliant with the Boost Spirit documentation.  (I do not
understand the objection in Comment #3: the fact that there is or not a sequence
point at | does not seem relevant to me.)
Comment 9 Petr Machata 2007-10-09 07:40:59 EDT
Created attachment 221151 [details]
Test case.

I took a stab at this problem.	What happens in boost is in more simple terms
illustrated by the attached source.  The problem is with const reference to
immediate value, which ends up pointing to stack.  Obviously when the action
actually takes place, the stack is in completely different shape.  The run
looks like this:

$ ./a.out 
ctor: 0xbf9ed113, 1
call: 0xbf9ed113, 191
191

Sequencing of the original test case may still be dubious, but I didn't dig in
that direction, because the problem exhibits itself even when I remove the
first branch of | operator.

Benjamin, I'm not sure what's the problem here.  Is C++ supposed to treat const
references to immediate values like this, which would indicate that the problem
is in boost; or is this a bug in compiler, and I should report upstream?
Comment 10 Petr Machata 2007-10-09 07:44:40 EDT
Created attachment 221161 [details]
Test case.

And just for reference, cut down version of original testcase.	Transcript of
run:

$ ./a.out 
8
$ ./a.out 
10
$ ./a.out 
8

So you see, it's not even deterministic...
Comment 11 Benjamin Kosnik 2007-10-12 13:53:56 EDT
Great job on the reduced test case Petr!

To me, this is a boost bug. In your reduced example, the second argument of the
tester ctor should not be a reference, but a value. A reference to temporary is
wack.

-benjamin

Comment 12 Bug Zapper 2008-04-03 21:56:29 EDT
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
Comment 13 Petr Machata 2008-04-04 09:20:35 EDT
Bug still present.
Comment 14 petrosyan 2008-04-04 16:59:10 EDT
Petr, update Fedora version field.
Comment 15 Bug Zapper 2008-11-26 01:50:17 EST
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 16 Bug Zapper 2009-11-18 03:03:30 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 17 Bug Zapper 2009-12-18 00:50:46 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 18 John Smith 2010-03-08 08:57:58 EST
Same bug in current Fedora 12 (original testcase gives 191 instead of 1).
Comment 19 Matthew Miller 2010-03-08 09:50:43 EST
Given the long history of this bug, I think it's unlikely to get directly resolved via this bug ticket. Has the issue been discussed upstream?
Comment 20 Benjamin Kosnik 2010-09-14 14:38:16 EDT
I'm closing this. Results are the same on F13/F14/RHEL6 with the 2nd attachment's testcase:

-O0 == 0
-01 and higher = 1

The original issue is about bool conversions to int values other than 0 or 1, so
that seems resolved.

This isn't a bug, but rather undefined behavior, see #3.

-benjamin
Comment 21 John Smith 2010-09-20 13:43:06 EDT
Not wanting to create unsolicited noise I do not reopen the bug, but on my system (up to date F13) I still get 191 with -O0.

Note You need to log in before you can comment on or make changes to this bug.