Bug: Returning, assigning into array and testing against 0 fails 
Author Message
 Bug: Returning, assigning into array and testing against 0 fails

I'm having bad luck today.  It wasn't two minutes after I worked around the
value/enum compiler bugs that I stumbled into another one:

    #using <mscorlib.dll>
    using namespace System;
    static String *Zero() {return 0;}
    void main() {
        String *f[] = new String*[1];
        if ((f[0] = Zero()) == 0)
            Console::WriteLine(S"Zero() == 0");
        else
            Console::WriteLine(S"Zero() != 0");
    }

Even though Zero() returns 0, it will take the 'else' path.

-Sean



Sat, 12 Feb 2005 09:36:12 GMT  
 Bug: Returning, assigning into array and testing against 0 fails
== on Object* or on any other reference type will compare pointer values.
Non const inited strings aren't interned so the pointer values will be
different. You will need to call compare on the strings.

Ronald Laeremans
Visual C++ compiler and libraries team


Quote:
> I'm having bad luck today.  It wasn't two minutes after I worked around
the
> value/enum compiler bugs that I stumbled into another one:

>     #using <mscorlib.dll>
>     using namespace System;
>     static String *Zero() {return 0;}
>     void main() {
>         String *f[] = new String*[1];
>         if ((f[0] = Zero()) == 0)
>             Console::WriteLine(S"Zero() == 0");
>         else
>             Console::WriteLine(S"Zero() != 0");
>     }

> Even though Zero() returns 0, it will take the 'else' path.

> -Sean



Sat, 12 Feb 2005 10:00:51 GMT  
 Bug: Returning, assigning into array and testing against 0 fails


Quote:
> == on Object* or on any other reference type will compare pointer values.
> Non const inited strings aren't interned so the pointer values will be
> different. You will need to call compare on the strings.

I'm not quite sure what that reply means but..

Why is it that modifying Sean's code like this:

    #using <mscorlib.dll>
    using namespace System;
    static String *Zero() {return 0;}
    void main() {
       String *f[] = new String*[1];
        f[0] = Zero();
        if (f[0] == 0)
            Console::WriteLine(S"Zero() == 0");
        else
            Console::WriteLine(S"Zero() != 0");
    }

Behaves as any ordinary C/C++ programmer would expect?

Isn't a null a null no matter where it came from?

-cd



Sat, 12 Feb 2005 10:36:31 GMT  
 Bug: Returning, assigning into array and testing against 0 fails
I am not sure whether this is the reason but the line
if ((f[0] = Zero()) == 0)
compiles to this il code

//000018:   if ((f[0] = Zero()) == 0)
  IL_0009:  ldloc.0
  IL_000a:  ldc.i4.0
  IL_000b:  call       string
modopt([mscorlib]System.Runtime.CompilerServices.CallConvCdecl)
?A0x3d035f1e.Zero()
  IL_0010:  stelem.ref
  IL_0011:  ldloc.0
  IL_0012:  ldc.i4.0
  IL_0013:  ldelem.u4  // I changed this manually to ldelem.ref, then it
works
  IL_0014:  brtrue.s   IL_0022

whereas
if ((f[0]) == 0)
compiles to this

//000018:   if ((f[0]) == 0)
  IL_0009:  ldloc.0
  IL_000a:  ldc.i4.0
  IL_000b:  ldelem.ref
  IL_000c:  brtrue.s   IL_001a



Quote:
> == on Object* or on any other reference type will compare pointer values.
> Non const inited strings aren't interned so the pointer values will be
> different. You will need to call compare on the strings.

> Ronald Laeremans
> Visual C++ compiler and libraries team



> > I'm having bad luck today.  It wasn't two minutes after I worked around
> the
> > value/enum compiler bugs that I stumbled into another one:

> >     #using <mscorlib.dll>
> >     using namespace System;
> >     static String *Zero() {return 0;}
> >     void main() {
> >         String *f[] = new String*[1];
> >         if ((f[0] = Zero()) == 0)
> >             Console::WriteLine(S"Zero() == 0");
> >         else
> >             Console::WriteLine(S"Zero() != 0");
> >     }

> > Even though Zero() returns 0, it will take the 'else' path.

> > -Sean



Sat, 12 Feb 2005 12:29:05 GMT  
 Bug: Returning, assigning into array and testing against 0 fails

Quote:
> == on Object* or on any other reference type will compare pointer values.

That's exactly what I intended to do:  compare pointer values.

I guess String* was a bad choice for my example since it has overloaded
operators, but the same problem occurs no matter what the object type is.

This bug is triggered with the combination of returning a managed pointer
from a function, assigning it into an array and checking that result for
null.

I don't believe my original code was too far-fetched:  I wrote a loop to
fill an array with objects from a factory method.  Within that loop I would
throw an exception if the factory method returned null.  However, this bug
prevents the exception from ever being thrown; even if a null was assigned
into the array.  This caused null reference exceptions later on in the code.

-Sean



Sun, 13 Feb 2005 00:21:00 GMT  
 Bug: Returning, assigning into array and testing against 0 fails
Your analysis is spot on! Jeff Peil and I looked at this today and we came
to the same conclusion. It is an IL codegen bug in the C++ FE. We will also
verify whether it is in addition  a JIT codegen bug since specifically with
the value 0 it should work.

Ronald Laeremans
Visual C++ compiler and libraries team


Quote:
> I am not sure whether this is the reason but the line
> if ((f[0] = Zero()) == 0)
> compiles to this il code

> //000018:   if ((f[0] = Zero()) == 0)
>   IL_0009:  ldloc.0
>   IL_000a:  ldc.i4.0
>   IL_000b:  call       string
> modopt([mscorlib]System.Runtime.CompilerServices.CallConvCdecl)
> ?A0x3d035f1e.Zero()
>   IL_0010:  stelem.ref
>   IL_0011:  ldloc.0
>   IL_0012:  ldc.i4.0
>   IL_0013:  ldelem.u4  // I changed this manually to ldelem.ref, then it
> works
>   IL_0014:  brtrue.s   IL_0022

> whereas
> if ((f[0]) == 0)
> compiles to this

> //000018:   if ((f[0]) == 0)
>   IL_0009:  ldloc.0
>   IL_000a:  ldc.i4.0
>   IL_000b:  ldelem.ref
>   IL_000c:  brtrue.s   IL_001a



> > == on Object* or on any other reference type will compare pointer
values.
> > Non const inited strings aren't interned so the pointer values will be
> > different. You will need to call compare on the strings.

> > Ronald Laeremans
> > Visual C++ compiler and libraries team



> > > I'm having bad luck today.  It wasn't two minutes after I worked
around
> > the
> > > value/enum compiler bugs that I stumbled into another one:

> > >     #using <mscorlib.dll>
> > >     using namespace System;
> > >     static String *Zero() {return 0;}
> > >     void main() {
> > >         String *f[] = new String*[1];
> > >         if ((f[0] = Zero()) == 0)
> > >             Console::WriteLine(S"Zero() == 0");
> > >         else
> > >             Console::WriteLine(S"Zero() != 0");
> > >     }

> > > Even though Zero() returns 0, it will take the 'else' path.

> > > -Sean



Sun, 13 Feb 2005 13:12:39 GMT  
 Bug: Returning, assigning into array and testing against 0 fails
Yes, I misread your post. Sorry for that. Biondello was exactly right as to
what the bug is.

Ronald


Quote:
> > == on Object* or on any other reference type will compare pointer
values.

> That's exactly what I intended to do:  compare pointer values.

> I guess String* was a bad choice for my example since it has overloaded
> operators, but the same problem occurs no matter what the object type is.

> This bug is triggered with the combination of returning a managed pointer
> from a function, assigning it into an array and checking that result for
> null.

> I don't believe my original code was too far-fetched:  I wrote a loop to
> fill an array with objects from a factory method.  Within that loop I
would
> throw an exception if the factory method returned null.  However, this bug
> prevents the exception from ever being thrown; even if a null was assigned
> into the array.  This caused null reference exceptions later on in the
code.

> -Sean



Sun, 13 Feb 2005 13:13:45 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. VC5 Bug: Failed new returns 0 and other problems

2. Why explicitly test against NULL?

3. Assigning Return Types From Malloc

4. Assigning Return Type

5. assigning a value to void returning funcrions

6. SOAP returning array of objects containing arrays

7. test test test test

8. assigning values to an array

9. assigning to a char array

10. Problem: Assigning the contents of an array to a string

11. Problem: Assigning the contents of an array to a string

12. Assign data to array of structures?

 

 
Powered by phpBB® Forum Software