[Mono-dev] 1003 Ways To Break A Runtime

Paolo Molaro lupus at ximian.com
Wed Feb 22 10:53:36 EST 2006

On 02/21/06 Jim Purbrick wrote:
> > No. Say you have:
> > 
> > class A {}
> > class B : A {}
> > class C : B {}
> > 
> > Merging B and C will result in a B type, not Object.
> > The spec says: the closest common supertype.
> > If you need to merge C and string, then the closest
> > supertype is Object.
> But, if all objects are subtypes of Object, any 2
> object types will merge, so its always possible to
> merge 2 stacks with equal numbers of object types?

It is always possible to merge two references to Object.
This doesn't mean that the later uses of this object are
verifiable. Say that a callvirt is done on the object
to MyMethod (): this call won't be verifiable, because Object doesn't
define a MyMethod () method.
You may try that writing a test and running peverify on it.
That said I don't remember what exactly the MS runtime does in these
cases, but I think it will compile the method if you have full trust,
but insert a cast before the call so that you get an exception at
runtime if the object is not of the right type.

Hope this clears things up.

> > > 7) When does coercion happen?
> >
> > Coercion should happens every time there is a store,
> > so calls, stloc, starg, stfld, stsfld, stelem, box, 
> > stobj, cpobj, stind.
> OK, done. Are there other tests needed for these
> opcodes? Do the slot type and stack type also have to
> match according to the verification type compatibility
> rules?

Not sure what you mean by slot type. The type of the target
field/local/etc must be compatible with the stack type of the values
that is going to be stored to it.


lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better

More information about the Mono-devel-list mailing list