Hey, On 12/17/08, Richard Flamsholt <[email protected]> wrote: > 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.
Sure. I just need sample assemblies. > 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. I see the issue. I need an assembly reproducing the issue, so that I can fix it by still supporting the constructions that the c++/cli compiler emits/ > Are you saying some compilers can add CustomMods in front of a Type, > too? Yes. MS c++/cli compiler does that. -- Jb Evain <[email protected]> --~--~---------~--~----~------------~-------~--~----~ -- mono-cecil -~----------~----~----~----~------~----~------~--~---
