On 01/02/03 bvv wrote: > Running mint I found that there's a check done on the corlib. > interp.c has a call to funciton "mono_verify_corlib" which is > found in verify.c. > I was surprised to find that the verification involves checking if > certain "private" fields are present in various classes of corlib. > I say "private" because these fields are *NOT* part of the ECMA > standard class definitions. > > I stepped through Rotor code to see if they do they same thing, > and yes they do! > > If u try to replace Rotor's corlib with mono's corlib the checking > that Rotor does on the corlib fails because the *private* fields > that Rotor expects to find are either not available in mono's > corlib or the name of the field differs! > > Now, what i don't understand is > What's the purpose of corlib verification? > Why is corlib verification done based on such *private* fields?
The easiest and fastest way to communicate between the managed world and the unmanaged world of the runtime is to lay out the things in memory in a way that is understood by both worlds. Many types that are tightly coupled with the runtime implementation (such as String, Type, the Reflection and Reflection.Emit stuff and so on) have the same memory layout in the managed and unmanaged world: mono_verify_corlib () checks that this is the case (not all the fields and types are checked yet, though). As a trivial example, consider the System.String class: there is one field declared in the C# side of things: length. This field is accessed by the string class code, but it is also accessed (and set) by the runtime, in C code. Now, you could access it in C code by queyring the metadata for the offset of the field and accessing it with address arithmetric and an indirect load/store (in the early days of mono we used to do that and I bet we still do it for some types somewhere). It's ways better to define a C struct that has the same layout as the managed string class, so that in C code you can access the fields of the structure naturally: the code is cleaner and faster. lupus -- ----------------------------------------------------------------- [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
