On Dec 17, 12:24 pm, "Jb Evain" <[email protected]> wrote: > Anyway, the bug is fixed in svn.
Well, no - I don't think it's solved. The patch I submitted solve the bug I described. Any non-compliant compilers will have to be addressed, too, and you are of course in a much better position to judge how to do that, but it doesn't make this bug any less real. The problem of inappropriately doing a ReadCustomMods() again is that it will parse a completely unrelated token-value (a type) which will be interpreted as a modreq/modopt if the type's value happens to be 0x1f or 0x20. And if the modopt/modreq-attribute is added for a method then its signature will no longer match - at least not when called from external assemblies. So basically a round-trip through Cecil can randomly break some methods' signatures. Not good. Are you saying some compilers can add CustomMods in front of a Type, too? (Not allowed: only if a Type starts with a PTR-token is an optional set of CustomMods allowed). It's okay to support broken compilers, but only to the extent it doesn't cause problems for proper code produced by compliant compilers. /Richard --~--~---------~--~----~------------~-------~--~----~ -- mono-cecil -~----------~----~----~----~------~----~------~--~---
