«

"Paavo Helde" <>
> "Balog Pal" <> wrote in news:j62hha$2sej$:
>
>>>>> 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(: 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

Jorgen Grahn <grahn+> 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]

On Fri, 2011-09-30, Miles Bader wrote:
> Jorgen Grahn <grahn+> 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 .

Jorgen Grahn <grahn+> 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.

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?

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 .

Edek wrote:

> On 09/28/2011 08:28 PM, Paul Brettschneider wrote:
>> Stefan Ram wrote:
>>
>>> . But didn't ISO/IEC 14882:2011 say in 4.12 Boolean
>>> conversion about non-zero values:
>>>
>>> »any other value is converted to true.«
>>>
>>> ?
>>
>> Oh yes! This has bitten me numerous times. Erroneously declared a
>> function parameter as bool instead of int and got very strange results.
>>
>
> I don't think that is the point; it is about the standard conversion
> to bool, which many programmers rely on and which is well specified
> in the standard.

Yes, I know what the point was. I was just complaining about this
behaviour, which took me by surprise more than once, even though it is well
documented.

Either treat bools like a normal integer type (with a size optimized for the
use as flag, e.g. char for x86, int for RISC) or make the conversion non-
explicit. But I understand that the reasons for the standard compliant
behaviour are historical and this has been discussed at length before. One
of the terrible legacy things we have to live with.

Paul Brettschneider <> writes:
> Either treat bools like a normal integer type (with a size optimized for the
> use as flag, e.g. char for x86, int for RISC) or make the conversion non-
> explicit. But I understand that the reasons for the standard compliant
> behaviour are historical and this has been discussed at length before. One
> of the terrible legacy things we have to live with.

Wait, why is it "terrible"? This conversion seems perfectly reasonable.

-miles

--
Americans are broad-minded people. They'll accept the fact that a person can
be an alcoholic, a dope fiend, a wife beater, and even a newspaperman, but if
a man doesn't drive, there is something wrong with him. -- Art Buchwald

Miles Bader <> writes:
>Paul Brettschneider <> writes:
>>Either treat bools like a normal integer type (with a size optimized for the
>>use as flag, e.g. char for x86, int for RISC) or make the conversion non-
>>explicit. But I understand that the reasons for the standard compliant
>>behaviour are historical and this has been discussed at length before. One
>>of the terrible legacy things we have to live with.
>Wait, why is it "terrible"? This conversion seems perfectly reasonable.

Yes, the canonical conversion semantics has to be

[]( int const i ){ return i ? true : false; }

, since this naturally agrees with the identity

[]( bool const b ){ return b ? true : false; }