Bug 11882 - Uninitialised bool variables do not work properly
Summary: Uninitialised bool variables do not work properly
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 3.2.2
: P3 minor
Target Milestone: 3.4.0
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-08-11 13:03 UTC by Flavio Poletti
Modified: 2005-07-23 22:49 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Flavio Poletti 2003-08-11 13:03:39 UTC
[Excuse me if the "triplet" fields are empty, I have no clue of their meaning.]
[Yes, I do know that uninitialised variables are not good programming]

I think there's a bug in GCC 3.2.2 dealing with correct bool type handling.
Please forgive me if this is not a bug.

Consider the following fragment of code (please note that tmp and tmp2 are not
initialised):

// BEGIN FRAGMENT OF CODE, compile with g++
#include <iostream>

typedef bool mybool;

int main(int argc, char *argv[])
{
	mybool tmp;
	bool tmp2;
	std::cout << "Now tmp is " << (tmp ? "true" : "false") << std::endl;
	std::cout << "Now tmp2 is " << (tmp2 ? "true" : "false") << std::endl;
	tmp = !tmp;
	std::cout << "Now tmp is " << (tmp ? "true" : "false") << std::endl;
	std::cout << "Now tmp2 is " << (tmp2 ? "true" : "false") << std::endl;
	return 0;
}
// END FRAGMENT OF CODE

The net effect of this code *could* be a print like the following:

>>>>  Now tmp is true
>>>>  Now tmp2 is true
>>>>  Now tmp is true
>>>>  Now tmp2 is true

which seems buggy due to the fact that the bool and mybool types should have
only two valid states, i.e. true and false.

Looking more in depht with gdb, I discovered that mybool is really defined
something like a char or similar. The lack of initialisation *could* lead to
initial values different from 0 or 1 (in my case, 64, but in the original code
was 243), so the following happens:

* when tmp = !tmp; is called, only the last bit is changed
* when the test is called, all bits are considered (hence the test will be
always true if the random initial value is different from 0 and 1).

Is this a bug? I think so, but I'm not in the standardisation process! Here
follow my specs:
g++ --version
g++ (GCC) 3.2.2
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 

g++ -v
Reading specs from /usr/lib/gcc-lib/i386-slackware-linux/3.2.2/specs
Configured with: ../gcc-3.2.2/configure --prefix=/usr --enable-shared
--enable-threads=posix --enable-__cxa_atexit --disable-checking --with-gnu-ld
--verbose --target=i386-slackware-linux --host=i386-slackware-linux
Thread model: posix
gcc version 3.2.2

Note: the compiler is what is shipped with Slackware 9.0.
Comment 1 Andreas Schwab 2003-08-11 13:12:46 UTC
Use of uninitialized variables leads to undefined behaviour, which is what you 
are observing. 
Comment 2 Wolfgang Bangerth 2003-08-11 15:28:51 UTC
And as for the bit-patterns: gcc assumes that bools have only one bit set or cleared, so 
flipping it is enough to change from true to false. On the other hand, an expression like 
 (tmp ? "true" : "false") 
if implicitly converted to 
  ((int)tmp !=0 ? ...) 
so all bits in tmp are considered. 
 
W.