[Mono-list] Re: [DotGNU]Qt.dll verification errors

[Paolo Molaro]

On 10/17/02 Rhys Weatherley wrote:
> The ECMA spec says that the "DataSize" member of an exception
> block should be "n * 12 + 4" for a tiny format block, or "n * 24 + 4"
> for a fat format block.  Qt.dll appears to have "n * 24" instead
> in the fat format header.  This causes pnet to drop sections because
> it thinks that they are "truncated", which technically they are.

The spec also says:

24.4.5  Method Data Section  
At the next 4-byte boundary following the method body can be extra
method data sections. These method data 
sections start with a two byte header (1 byte flags, 1 byte for the
length of the actual data)  or a four byte header  
^^^^^^^^^^^^^^^^^^^^^^^^^
(1 byte for flags, and 3 bytes for length of the actual data). The first
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^
byte determines the kind of the header, and 
what data is in the actual section:  

It may just be because I'm not a native speaker, but when there is a
header + data and someone talks about the "length of the actual data"
it quite clearly means the length refers to the length of data, not
data+header. In the table it contradict itself and says that the
DataSize needs the +4 (the header size).
In fact, a few lines below the code that parses the header I added a
comment:
	/* LAMESPEC: it seems the size includes the header */

> Mono appears to handle both correct and incorrect formats through
> dumb luck also.  Around line 1500 of mono/metadata/metadata.c:
> 
>     mh->num_clauses = is_fat ? sect_data_len / 24: sect_data_len / 12;
> 
> If the value is "n * 24" or "n * 24 + 4", the "+ 4" will be
> truncated off and Mono will do the right thing.

There is nothing about dumb luck in that code: it does always the right
thing with any of the two interpretations of the spec.
I don't remember if (at the time I wrote the code) the ms tools produced
exception headers with the actual data length or added the header size.
The fact the peverify doesn't complain probably means that the behaviour
is fine (as long as it's done in the last section).
Anyway, I'll change reflection to output the header size as currently
produced by csc since it actually doesn't change anything for mono.

lupus

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