Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #10572 > unrolled thread

Re: "bool const a( 5 )" in "Microsoft Visual Studio C++ 2010"

Back to article view | Back to comp.lang.c++

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: "bool const a( 5 )" in "Microsoft Visual Studio C++ 2010" "Balog Pal" <pasa@lib.hu> - 2011-09-28 20:17 +0200
    Re: "bool const a( 5 )" in "Microsoft Visual Studio C++ 2010" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-09-29 12:13 +0000
      Re: "bool const a( 5 )" in "Microsoft Visual Studio C++ 2010" "Balog Pal" <pasa@lib.hu> - 2011-09-29 21:39 +0200
        Re: "bool const a( 5 )" in "Microsoft Visual Studio C++ 2010" Paavo Helde <myfirstname@osa.pri.ee> - 2011-09-29 15:04 -0500
          Re: "bool const a( 5 )" in "Microsoft Visual Studio C++ 2010" "Balog Pal" <pasa@lib.hu> - 2011-09-29 23:15 +0200
      Re: "bool const a( 5 )" in "Microsoft Visual Studio C++ 2010" Krice <paulkp@mbnet.fi> - 2011-09-29 12:49 -0700
      Re: "bool const a( 5 )" in "Microsoft Visual Studio C++ 2010" Miles Bader <miles@gnu.org> - 2011-09-30 11:04 +0900
        Re: "bool const a( 5 )" in "Microsoft Visual Studio C++ 2010" Paavo Helde <myfirstname@osa.pri.ee> - 2011-09-29 23:05 -0500
        Re: "bool const a( 5 )" in "Microsoft Visual Studio C++ 2010" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-09-30 19:35 +0000
          Re: "bool const a( 5 )" in "Microsoft Visual Studio C++ 2010" Miles Bader <miles@gnu.org> - 2011-10-01 08:27 +0900
            Re: "bool const a( 5 )" in "Microsoft Visual Studio C++ 2010" Peter <pilarp@poczta.onet.pl> - 2011-10-03 14:28 -0700
              Re: "bool const a( 5 )" in "Microsoft Visual Studio C++ 2010" Leigh Johnston <leigh@i42.co.uk> - 2011-10-03 22:35 +0100
                Re: "bool const a( 5 )" in "Microsoft Visual Studio C++ 2010" Leigh Johnston <leigh@i42.co.uk> - 2011-10-03 22:43 +0100
                  Re: "bool const a( 5 )" in "Microsoft Visual Studio C++ 2010" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-10-04 09:21 +0000
                    Re: "bool const a( 5 )" in "Microsoft Visual Studio C++ 2010" Leigh Johnston <leigh@i42.co.uk> - 2011-10-04 16:11 +0100
              Re: "bool const a( 5 )" in "Microsoft Visual Studio C++ 2010" Paavo Helde <myfirstname@osa.pri.ee> - 2011-10-03 23:10 -0500

#10572 — Re: "bool const a( 5 )" in "Microsoft Visual Studio C++ 2010"

"Stefan Ram" <ram@zedat.fu-berlin.de>

>  I compiled and executed (via Ctrl-F5)
>
> #include <iostream>
> #include <ostream>
>
> int main(){ bool const a( 5 ); ::std::cout <<( a == true )<< '\n'; }
>
>  in »Microsoft Visual Studio 2010 C++ Express, Version 10.0.30319.1 
> RTMRel«
>  (a recent version) with the default settings (the Debug configuration as
>  preconfigured).
>
>  It printed:
>
> 0
>
>  . But didn't ISO/IEC 14882:2011 say in 4.12 Boolean
>  conversion about non-zero values:
>
>      »any other value is converted to true.«

Yep. Bug-ridden compiler :-(.   VS2008 does the same. It even prints a 
warning about converting int to const bool, but then leaves its value at 5, 
that can be printed.  If you remove 'const' and only use bool, then value is 
1 and prints 1 for comarision. 

[toc] | [next] | [standalone]

#10583

On Wed, 2011-09-28, Balog Pal wrote:
> "Stefan Ram" <ram@zedat.fu-berlin.de>
>
>>  I compiled and executed (via Ctrl-F5)
>>
>> #include <iostream>
>> #include <ostream>
>>
>> int main(){ bool const a( 5 ); ::std::cout <<( a == true )<< '\n'; }
>>
>>  in »Microsoft Visual Studio 2010 C++ Express, Version 10.0.30319.1 
>> RTMRel«
>>  (a recent version) with the default settings (the Debug configuration as
>>  preconfigured).
>>
>>  It printed:
>>
>> 0
>>
>>  . But didn't ISO/IEC 14882:2011 say in 4.12 Boolean
>>  conversion about non-zero values:
>>
>>      »any other value is converted to true.«
>
> Yep. Bug-ridden compiler :-(.   VS2008 does the same. It even prints a 
> warning about converting int to const bool, but then leaves its value at 5, 
> that can be printed.  If you remove 'const' and only use bool, then value is 
> 1 and prints 1 for comarision. 

That surprises me -- it's a fairly visible and very dangerous bug, and
I thought the MS compilers were really good these days. Or did I miss
something? (I don't use them myself.)

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#10590

"Jorgen Grahn" <grahn+nntp@snipabacken.se>
>>> int main(){ bool const a( 5 ); ::std::cout <<( a == true )<< '\n'; }
>>
>> Yep. Bug-ridden compiler :-(.   VS2008 does the same. It even prints a
>> warning about converting int to const bool, but then leaves its value at 
>> 5,
>> that can be printed.  If you remove 'const' and only use bool, then value 
>> is
>> 1 and prints 1 for comarision.
>
> That surprises me -- it's a fairly visible and very dangerous bug, and
> I thought the MS compilers were really good these days.

Me too. For the record, VS6 does not have this bug. It was picked up on the 
way up.

[toc] | [prev] | [next] | [standalone]

#10593

"Balog Pal" <pasa@lib.hu> wrote in news:j62hha$2sej$1@news.ett.com.ua:

> "Jorgen Grahn" <grahn+nntp@snipabacken.se>
>>>> int main(){ bool const a( 5 ); ::std::cout <<( a == true )<< '\n';
>>>> } 
>>>
>>> Yep. Bug-ridden compiler :-(.   VS2008 does the same. It even prints
>>> a warning about converting int to const bool, but then leaves its
>>> value at 5,
>>> that can be printed.  If you remove 'const' and only use bool, then
>>> value is
>>> 1 and prints 1 for comarision.
>>
>> That surprises me -- it's a fairly visible and very dangerous bug,
>> and I thought the MS compilers were really good these days.
> 
> Me too. For the record, VS6 does not have this bug. It was picked up
> on the way up.

Does VS6 allow

	bool const a( 5 ); 
	char arr[a];

VS2010 accepts the code and makes an array containing 5 elements.

Also interesting:

int main() {
	bool const a( 0xfff ); 
	const int x=a;
	char arr[x+1];
}

produces:
1>consoletest.cpp(8): error C2466: cannot allocate an array of constant 
size 0

[toc] | [prev] | [next] | [standalone]

#10596

"Paavo Helde" <myfirstname@osa.pri.ee>
> "Balog Pal" <pasa@lib.hu> wrote in news:j62hha$2sej$1@news.ett.com.ua:
>
>>>>> int main(){ bool const a( 5 ); ::std::cout <<( a == true )<< '\n';
>>> That surprises me -- it's a fairly visible and very dangerous bug,
>>> and I thought the MS compilers were really good these days.
>>
>> Me too. For the record, VS6 does not have this bug. It was picked up
>> on the way up.

It's weird. When I tried it hours ago, it gave 1 for value, 1 for compare, 
now using the same code it gives 0 for compare...


> Does VS6 allow
>
> bool const a( 5 );
> char arr[a];
>
> VS2010 accepts the code and makes an array containing 5 elements.
>
> Also interesting:
>
> int main() {
> bool const a( 0xfff );
> const int x=a;
> char arr[x+1];
> }
>
> produces:
> 1>consoletest.cpp(8): error C2466: cannot allocate an array of constant
> size 0

This code in VS5:


#include <iostream>
#include <ostream>

int main()
{
 bool const a( 5 );
 ::std::cout << a <<( a == true )<< '\n';
 char c[a];
 ::std::cout << sizeof(c) << '\n';

 bool const b( 0xfff );
 const int x=b;
 char arr[x+1];
 ::std::cout << sizeof(arr) << '\n';

 return 0;
}

gives

E:\m32\try\t1\t1.cpp(309) : warning C4305: 'initializing' : truncation from 
'const int' to 'const bool'
E:\m32\try\t1\t1.cpp(314) : warning C4305: 'initializing' : truncation from 
'const int' to 'const bool'
E:\m32\try\t1\t1.cpp(315) : warning C4309: 'initializing' : truncation of 
constant value
E:\m32\try\t1\t1.cpp(316) : warning C4101: 'arr' : unreferenced local 
variable
E:\m32\try\t1\t1.cpp(311) : warning C4101: 'c' : unreferenced local variable

and prints:

10
5
4096

[toc] | [prev] | [next] | [standalone]

#10591

On 29 syys, 15:13, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
> I thought the MS compilers were really good these days. Or did I miss
> something?

VC++ is teaching to avoid mixing numbers with bool type.
It's a good lesson!

[toc] | [prev] | [next] | [standalone]

#10601

Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
> That surprises me -- it's a fairly visible and very dangerous bug, and
> I thought the MS compilers were really good these days. Or did I miss
> something? (I don't use them myself.)

MS compilers seem to optimize pretty well, etc, but _don't_ seem so
good at being standards-conforming.

I think one reason is that MS is reallly big on backward-
compatibility, even when it means continuing to support horrible
crufty old code that's completely invalid according to the standard.
So bugs and misfeatures of past releases have a way of getting locked
in...

[A big chunk of my time at work is twisting "but it compiled with VS!"
code into shape so that other compilers can compile it too...]

-miles

-- 
In New York, most people don't have cars, so if you want to kill a person, you
have to take the subway to their house.  And sometimes on the way, the train
is delayed and you get impatient, so you have to kill someone on the subway.
  [George Carlin]

[toc] | [prev] | [next] | [standalone]

#10603

Miles Bader <miles@gnu.org> wrote in news:87fwjeeqg9.fsf@catnip.gol.com:

> Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
>> That surprises me -- it's a fairly visible and very dangerous bug, and
>> I thought the MS compilers were really good these days. Or did I miss
>> something? (I don't use them myself.)
> 
> MS compilers seem to optimize pretty well, etc, but _don't_ seem so
> good at being standards-conforming.
> 
> I think one reason is that MS is reallly big on backward-
> compatibility, even when it means continuing to support horrible
> crufty old code that's completely invalid according to the standard.
> So bugs and misfeatures of past releases have a way of getting locked
> in...

Yes, but this bug is so terrible (const bool a(0xfff) having about 4 
different values in the same program in different contexts (false, true, 
4095 and -1)) I cannot imagine even MS keeping that for backward-
compatibility. 

Cheers
Paavo

[toc] | [prev] | [next] | [standalone]

#10612

On Fri, 2011-09-30, Miles Bader wrote:
> Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
>> That surprises me -- it's a fairly visible and very dangerous bug, and
>> I thought the MS compilers were really good these days. Or did I miss
>> something? (I don't use them myself.)
>
> MS compilers seem to optimize pretty well, etc, but _don't_ seem so
> good at being standards-conforming.
>
> I think one reason is that MS is reallly big on backward-
> compatibility, even when it means continuing to support horrible
> crufty old code that's completely invalid according to the standard.
> So bugs and misfeatures of past releases have a way of getting locked
> in...
>
> [A big chunk of my time at work is twisting "but it compiled with VS!"
> code into shape so that other compilers can compile it too...]

Are you talking about recent MS compilers, with a decent set of
standard-compliance options enabled?  The venerable VS6 certainly had
that reputation.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#10619

Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
> On Fri, 2011-09-30, Miles Bader wrote:
> > MS compilers seem to optimize pretty well, etc, but _don't_ seem so
> > good at being standards-conforming.
...
> > [A big chunk of my time at work is twisting "but it compiled with VS!"
> > code into shape so that other compilers can compile it too...]

> Are you talking about recent MS compilers, with a decent set of
> standard-compliance options enabled?  The venerable VS6 certainly
> had that reputation.

I think the version most people use around here (from which stems much
my practical experience) is VS2008.

-Miles

-- 
Dawn, n. When men of reason go to bed.

[toc] | [prev] | [next] | [standalone]

#10651

Is this some bad joke? Are we talking about a COMMERCIAL compiler
released a year ago? Please tell me these results are obtained for
some weird configuration and otherwise they're correct.
Some fundamental pieces of code are miscompiled here! If this, in
fact,
is VC++ 2010's typical behaviour, how did it go unnoticed and how are
people not AFRAID to build their applications with it?

[toc] | [prev] | [next] | [standalone]

#10652

On 03/10/2011 22:28, Peter wrote:
> Is this some bad joke? Are we talking about a COMMERCIAL compiler
> released a year ago? Please tell me these results are obtained for
> some weird configuration and otherwise they're correct.
> Some fundamental pieces of code are miscompiled here! If this, in
> fact,
> is VC++ 2010's typical behaviour, how did it go unnoticed and how are
> people not AFRAID to build their applications with it?

This bug probably exists because it is a rare event indeed for a good 
programmer to actually assign an int to a bool so most good programmers 
need not worry; I am certainly not going to lose any sleep over this 
particular compiler bug.

/Leigh

[toc] | [prev] | [next] | [standalone]

#10653

On 03/10/2011 22:35, Leigh Johnston wrote:
> On 03/10/2011 22:28, Peter wrote:
>> Is this some bad joke? Are we talking about a COMMERCIAL compiler
>> released a year ago? Please tell me these results are obtained for
>> some weird configuration and otherwise they're correct.
>> Some fundamental pieces of code are miscompiled here! If this, in
>> fact,
>> is VC++ 2010's typical behaviour, how did it go unnoticed and how are
>> people not AFRAID to build their applications with it?
>
> This bug probably exists because it is a rare event indeed for a good
> programmer to actually assign an int to a bool so most good programmers
> need not worry; I am certainly not going to lose any sleep over this
> particular compiler bug.

My mistake: in this case we are actually talking about initialization 
rather then assignment but my argument still holds.

/Leigh

[toc] | [prev] | [next] | [standalone]

#10656

On Mon, 2011-10-03, Leigh Johnston wrote:
> On 03/10/2011 22:35, Leigh Johnston wrote:
>> On 03/10/2011 22:28, Peter wrote:
>>> Is this some bad joke? Are we talking about a COMMERCIAL compiler
>>> released a year ago? Please tell me these results are obtained for
>>> some weird configuration and otherwise they're correct.
>>> Some fundamental pieces of code are miscompiled here! If this, in
>>> fact,
>>> is VC++ 2010's typical behaviour, how did it go unnoticed and how are
>>> people not AFRAID to build their applications with it?
>>
>> This bug probably exists because it is a rare event indeed for a good
>> programmer to actually assign an int to a bool so most good programmers
>> need not worry; I am certainly not going to lose any sleep over this
>> particular compiler bug.
>
> My mistake: in this case we are actually talking about initialization 
> rather then assignment but my argument still holds.

I disagree -- this conversion to bool is a well-known feature of C++,
and feels like something I might do, for example when interfacing with
ancient code or C code which has its own typedefs, enums of defines
for bool, true and false.

Perhaps the special circumstances needed to trigger it makes it
appear extremely rarely in real code -- I can't really tell.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#10664

On 04/10/2011 10:21, Jorgen Grahn wrote:
> On Mon, 2011-10-03, Leigh Johnston wrote:
>> On 03/10/2011 22:35, Leigh Johnston wrote:
>>> On 03/10/2011 22:28, Peter wrote:
>>>> Is this some bad joke? Are we talking about a COMMERCIAL compiler
>>>> released a year ago? Please tell me these results are obtained for
>>>> some weird configuration and otherwise they're correct.
>>>> Some fundamental pieces of code are miscompiled here! If this, in
>>>> fact,
>>>> is VC++ 2010's typical behaviour, how did it go unnoticed and how are
>>>> people not AFRAID to build their applications with it?
>>>
>>> This bug probably exists because it is a rare event indeed for a good
>>> programmer to actually assign an int to a bool so most good programmers
>>> need not worry; I am certainly not going to lose any sleep over this
>>> particular compiler bug.
>>
>> My mistake: in this case we are actually talking about initialization
>> rather then assignment but my argument still holds.
>
> I disagree -- this conversion to bool is a well-known feature of C++,
> and feels like something I might do, for example when interfacing with
> ancient code or C code which has its own typedefs, enums of defines
> for bool, true and false.

Rubbish; interfacing with "ancient code or C code" is still no excuse 
for directly assigning an int to a bool; always compare against zero 
instead:

int i = 5;
bool b = (i != 0);

Also consider:

int x;
...
if (x=3)
{
}

Here it is unclear if the assignment should actually be a comparison; if 
we enforce the rule that one shouldn't rely on implicit integer to bool 
conversion we are more likely to pick up bugs such as this.

> Perhaps the special circumstances needed to trigger it makes it
> appear extremely rarely in real code -- I can't really tell.

If you "can't really tell" then don't post in the first place.

/Leigh

[toc] | [prev] | [next] | [standalone]

#10655

Peter <pilarp@poczta.onet.pl> wrote in news:ae543a0a-0356-463b-9359-
4459864b8330@20g2000yqq.googlegroups.com:

> Is this some bad joke? Are we talking about a COMMERCIAL compiler
> released a year ago? Please tell me these results are obtained for
> some weird configuration and otherwise they're correct.

I'm not sure what you mean by "weird configuration", but the usage 
pattern is very rare I guess (a constexpr bool initialized from a 
constexpr int) so probably the bug has not been noticed or not considered 
important enough to fix. I can well imagine the manager asking: How many 
people will stomp on this bug? One in a million? Not worth fixing!

Any conversions applied during such a initialization must be performed on 
the compile time, not run-time, so it seems there is a bug (or rather 
several) in the compile-time constexpr support of MSVC. If the const bool 
is initialized from something not constexpr (like a non-const int), then 
the conversions appear to work correctly. In this case the conversion 
happens at run-time (Debug build) or is moved to compile time by the 
optimizer (Release build). It appears the MSVC optimizer works correctly 
here.

> Some fundamental pieces of code are miscompiled here! If this, in
> fact,
> is VC++ 2010's typical behaviour, how did it go unnoticed and how are
> people not AFRAID to build their applications with it?

You work with what you have. MSVC has certainly got a lot better over the 
years, so I would say this is not a typical behavior. There is always a 
danger that the compiler (or cpu!) misinterprets your code and produces 
some nonsense (last happened with gcc for me), that's one more reason why 
you need an (automated) testing system.

Cheers
Paavo

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web