Different types have the same signature in CIL

Question

I have one field defined in CIL, like this:

.field public int32 modopt(void*) fld 

I will compile this into an assembly. Now I change it to:

 .field public int32 modopt(int16) fld 

How is it now possible that ILDASM reports (if indicated as hex) both of these fields like this?

 Field #1 (04000001) ------------------------------------------------------- Field Name: fld (04000001) Flags : [Public] (00000006) CallCnvntn: [FIELD] Field type: CMOD_OPT 1b000001 I4 Signature : 06 20 06 08 

This code looks for both fields exactly the same (in fact, I created a second field to match the registered signature). The signature obviously corresponds to the second field, but the signature of the first field should look like this: 06 20 0f 01 08 ! What am I missing here?

Edit:

C # cannot emit this type of field, throwing an exception regarding pointer types and arrays that are not supported for custom type modifiers, so this seems to solve the signature mismatch. But the question of why ILDASM allows you to create an invalid signature that it cannot decompile remains.

Edit # 2:

It seems that ILASM is actually creating the correct IL, there is a difference in the hexadecimal dump that I skipped last time:

 //the first assembly TypeSpec #1 (1b000001) ------------------------------------------------------- TypeSpec : Ptr Void Signature: 0f 01 //the second assembly TypeSpec #1 (1b000001) ------------------------------------------------------- TypeSpec : I2 Signature: 06 

Thus, there is an error in the hexadecimal dump of ILDASM indicating an incorrect signature of the element (although I wonder where 06 came from in the wrong signature).

Answer 1

Try creating the field signature manually based on the specification . To begin with, the field signature is defined in §II.23.2.4. For our case, with one custom modifier, this would be:

 FIELD CustomMod Type 

Since FIELD is defined as 0x06, we have:

 06 CustomMod Type 

Our custom modopt modifier, so we get (based on §II.23.2.7):

 06 CMOD_OPT TypeDefOrRefOrSpecEncoded Type 

CMOD_OPT is 0x20 (§II.23.1.16):

 06 20 TypeDefOrRefOrSpecEncoded Type 

We want to refer to TypeSpec 0x1b000001, which is encoded as 0b110 (10 for TypeSpec , 1 for 0x000001, §II.23.2.8). Then it is “compressed” into one byte 0x06 (§II.23.2):

 06 20 06 Type 

Finally, the type is int32 , which is ELEMENT_TYPE_I4 = 0x08 (§II.23.2.12 and §II.23.1.16):

 06 20 06 08 

So, we get exactly the same signature as in ILDasm.