[Mono-dev] 1003 Ways To Break A Runtime

Jim Purbrick jimpurbrick at yahoo.co.uk
Mon Feb 20 19:13:19 EST 2006

Hi Paolo/All,

I've started using templates parameterized by types
and opcodes as it makes the tests much easier to write
and check.

I've written tests for shifts, stack merging and
coercion this way and started converting the old tests
and now have 15 shell scripts which generate 1003
tests :-)


> > 1) It looks like object values should always 
> > merge as System.Object is always a supertype of 
> > both?
> 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?

If so, why all the special rules about compatibility
of arrays and interfaces etc.? Are they not objects
for the purposes of stack merges? Are the type
compatibility rules also used elsewhere? (If so,

> > 2) Should shift op tests be based on "Table 6:
> > Shift Operations" (which makes sense) or "Table 5:
> > Integer Operations" (which 3.58 and 3.59 refer to 
> > under "Correctness and Verifiability").
> I'd say Table 6. 


> > 6) How do i generate by-ref and ref any fields in
> > CIL for the 1.6 coercion tests for stfld?
> Use:
> 	.field int32& val1
> and
> 	.field [mscorlib]System.TypedReference val2
> They are not allowed, so I'm not sure ilasm will
> compile them.

ILASM doesn't seem to like them.

> > 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



Win a BlackBerry device from O2 with Yahoo!. Enter now. http://www.yahoo.co.uk/blackberry

More information about the Mono-devel-list mailing list