[Mono-list] Reflection and .NET Metadata

[Allen Copeland]

I wrote in three weeks ago asking about how mono loaded assemblies in
Linux or other Operating Systems.

I have a question for you all about validating a .NET metadata parser.
 The ECMA-335 specification outlines every aspect of the spec;
however, even with a spec it's possible to get it wrong. Given your
presence within Mono's development, I figured you might be able to
tell me what I can do to validate the parser I'm writing.

When I wrote in on March 23rd, I was just eleven days into my journey
through .NET Metadata.  Using a bit of code generation, the current
setup involves the use of a state-machine generator which constructs
the Table Stream ( #~ stream ) initial parse method, table interfaces
and readers.  It goes through and checks the tables being read in,
reads their counts, and sets up flags associated to the encoding/table
sizes.  Once the tables are created, it goes through and sets their
individual states.  The states are simple numeric values which relate
to the various imports of the given table.  As an example, the
TypeDefTable has 16 states, because there are four possible types of
variable lengths: fields, methods, strings and type defs.  In the
order they were listed, each occupies a state machine bit, when the
state is 1, 3, 5, 7, 9, 11, 13, or 15 Fields are Four bytes long,
otherwise they are two (field occupies bit zero of the machine state),
methods would occupy bit one, thus when the state is 2, 3, 6, 7, 10,
11, 14 or 15 the indexes are four bytes, otherwise two.  The trend
continues with the string heap (bit two) and table def or ref or spec
(bit three) indices.

The concept above is fairly simple, the project I'm working on focuses
on reading metadata in, but now I need a way to validate its results
(all 38 tables and signature types, now I need to work on IL).  The
structure of these are immutable, because of the initial focus of
reading the data (that and the idea of altering an existing library
doesn't sit well with me.)

The reason I'm wanting to validate this data is I was testing it on
StandAloneSignatures on every dll contained within the .NET BCL and I
kept getting odd information: pinned fields, byref types that had
custom attributes following them, method refs that have stdcall and
cdecl calling conventions, and so on.  I don't know how to validate
whether these are correct results, so I figured I'd turn to someone
for insight since the CLI spec doesn't indicate such up front (if it
does, I missed something...)

Any insight you can provide is appreciated.

PS: Here's a link to the code relative to the example table described.
http://abstractionproject.codeplex.com/SourceControl/changeset/view/12133#216915

If it doesn't select the file in your browser, the path is:
SLF\TypeSystems\Ecma-335 Common Type
System\_Internal\Cli\Metadata\Tables\CliMetadataTypeDefinitionTable.cs

PPS:
The code uses a method call to do a right-shift, embarrassingly the
code generator I wrote is a bit old and originally was focused on
supplementing Microsoft's CodeDOM, and then focused on replacing it,
but certain aspects of its code were still dependent on it: thus no
Bit Shifting binary operators.