VC++ 6.0 / 7.0 compilation difference ?

[ideas2050]

[SUMMARY]
Observed a compilation error reporting differences between VC++ 6.0 and
7.0 VS .NET 2003.
Seeking opinions.

[IN DETAILS]

Here is the code abbreviated:-

main()
{

// xxxxxxxxx other code xxxxxxxxxxxxxxx

if(<<something==1>>)
{
goto Label_1;
//xxxxx other code xxx
}

<<pointer variable declaration + definition here>>;


Label_1:
//xxxxxxxxxxxxother code xxxxxxxxxxxxxxxx


}

When I compiled this in 6.0, it gave me error saying that goto is
skipping the pointer variable's definition. But 7.0 did not give such a
error.

Both places, settings were error level 3, which did NOT mean treating
warnings as errors.

Any ideas, how this difference?

Thanks.

- Kedar Agarkar

 

[Ron Natalie]

[SUMMARY]
Observed a compilation error reporting differences between VC++ 6.0 and
7.0 VS .NET 2003.
Seeking opinions.

[IN DETAILS]

Here is the code abbreviated:-

main()
{

// xxxxxxxxx other code xxxxxxxxxxxxxxx

if(<<something==1>>)
{
goto Label_1;
//xxxxx other code xxx
}

<<pointer variable declaration + definition here>>;


Label_1:
//xxxxxxxxxxxxother code xxxxxxxxxxxxxxxx


}

When I compiled this in 6.0, it gave me error saying that goto is
skipping the pointer variable's definition. But 7.0 did not give such a
error.

Then 7.0 is wrong. Call microsoft and complain. You are not
permitted to jump over initializaitons of variables. The general
way to fix it is to wrap a block around the stuff between the if
and Lable_1 so that they are not in scope at the point of the jump.

 

[Victor Bazarov]

[SUMMARY]
Observed a compilation error reporting differences between VC++ 6.0 and
7.0 VS .NET 2003.
Seeking opinions.

[IN DETAILS]

Here is the code abbreviated:-

main()
{

// xxxxxxxxx other code xxxxxxxxxxxxxxx

if(<<something==1>>)
{
goto Label_1;
//xxxxx other code xxx
}

<<pointer variable declaration + definition here>>;


Label_1:
//xxxxxxxxxxxxother code xxxxxxxxxxxxxxxx


}

When I compiled this in 6.0, it gave me error saying that goto is
skipping the pointer variable's definition. But 7.0 did not give such a
error.

What's "something"? Could it be the condition inside 'if' was always
"false" and 7.0 recognized that?

Hint: ALWAYS post _real_ compilable code, no "abbreviated" versions.

Both places, settings were error level 3, which did NOT mean treating
warnings as errors.

Any ideas, how this difference?

Also remember that compiler-specific questions should be addressed to
a compiler-specific newsgroups (microsoft.public.vc.language). I am *not*
saying that this question is necessarily compiler-specific. Besides, it
cannot be answered without seeing the _real_ code.

V

 

[Howard]

[SUMMARY]
Observed a compilation error reporting differences between VC++ 6.0 and
7.0 VS .NET 2003.
Seeking opinions.

[IN DETAILS]

Here is the code abbreviated:-

main()
{

// xxxxxxxxx other code xxxxxxxxxxxxxxx

if(<<something==1>>)
{
goto Label_1;
//xxxxx other code xxx
}

<<pointer variable declaration + definition here>>;


Label_1:
//xxxxxxxxxxxxother code xxxxxxxxxxxxxxxx


}

When I compiled this in 6.0, it gave me error saying that goto is
skipping the pointer variable's definition. But 7.0 did not give such a
error.

Then 7.0 is wrong. Call microsoft and complain. You are not permitted
to jump over initializaitons of variables. The general
way to fix it is to wrap a block around the stuff between the if
and Lable_1 so that they are not in scope at the point of the jump.

It's not that it's broken, really. It's a VC++ 7 compiler option. When
compiled with /Za (to "disable language extensions"), the code below will
fail:

int a = 1;
if (a < 2)
goto Label1;
int* pa = &a;
Label1:
if (pa)
return;

But /Za is not the default for VC++ 7 (and if I recall, can break some of
their library code?). So it is accepted by the compiler.

It's just plain dumb that MS decided to allow this by default. The code
makes no sense, since it will try to test the value of a pointer which is
not defined. I haven't tried running it to see what happens. Undefined
behavior scares me!

-Howard

 

[ideas2050]

Thanks Ron and Howard.
- Kedar

[SUMMARY]
Observed a compilation error reporting differences between VC++ 6.0 and
7.0 VS .NET 2003.
Seeking opinions.

[IN DETAILS]

Here is the code abbreviated:-

main()
{

// xxxxxxxxx other code xxxxxxxxxxxxxxx

if(<<something==1>>)
{
goto Label_1;
//xxxxx other code xxx
}

<<pointer variable declaration + definition here>>;


Label_1:
//xxxxxxxxxxxxother code xxxxxxxxxxxxxxxx


}

When I compiled this in 6.0, it gave me error saying that goto is
skipping the pointer variable's definition. But 7.0 did not give such a
error.

Then 7.0 is wrong. Call microsoft and complain. You are not permitted
to jump over initializaitons of variables. The general
way to fix it is to wrap a block around the stuff between the if
and Lable_1 so that they are not in scope at the point of the jump.

It's not that it's broken, really. It's a VC++ 7 compiler option. When
compiled with /Za (to "disable language extensions"), the code below will
fail:

int a = 1;
if (a < 2)
goto Label1;
int* pa = &a;
Label1:
if (pa)
return;

But /Za is not the default for VC++ 7 (and if I recall, can break some of
their library code?). So it is accepted by the compiler.

It's just plain dumb that MS decided to allow this by default. The code
makes no sense, since it will try to test the value of a pointer which is
not defined. I haven't tried running it to see what happens. Undefined
behavior scares me!

-Howard

 

[Rolf Magnus]

[SUMMARY]
Observed a compilation error reporting differences between VC++ 6.0 and
7.0 VS .NET 2003.
Seeking opinions.

[IN DETAILS]

Here is the code abbreviated:-

main()
{

// xxxxxxxxx other code xxxxxxxxxxxxxxx

if(<<something==1>>)
{
goto Label_1;
//xxxxx other code xxx
}

<<pointer variable declaration + definition here>>;


Label_1:
//xxxxxxxxxxxxother code xxxxxxxxxxxxxxxx


}

When I compiled this in 6.0, it gave me error saying that goto is
skipping the pointer variable's definition. But 7.0 did not give such a
error.

What's "something"? Could it be the condition inside 'if' was always
"false" and 7.0 recognized that?

Even then, it should be an error. The validity of code must not depend on
the optimization behavior of the compiler.