On 01/07/03 Gopal V wrote: > > Paragraph 13.3 in Partition II says basically the same things, but adds > > soon after: > > > > shall be distinct from their underlying type. For all other purposes, > > ^^^^^^^^^^^^^^^^^^^^^^ > > including verification and execution of > > code, an unboxed enum freely interconverts with its underlying type. > > > ..... > > will implement Reflection.Emit, it'll have to support this stuff anyway, > > just like the MS runtime does. > > So this is like saying Reflection.Emit API is to blame here ?. I wonder > what output MCS running on MS .NET would give ... (would it be the same ?).
Running mcs with the ms runtime produces the same output as with the mono runtime (but a few bugs that we fixed in our version of reflection.emit). > Hmm... since CSCC does not use Reflection.Emit, I think we'll not be affected > by this bug at all ... and field boxing has already been added for resolving It is not a bug. _If_ the issue is an API issue with Reflection.Emit you'll be affected as well when you'll implement it, the fact that cscc doesn't use Reflection doesn't matter one bit. Unless, of course, you implement a different API. > I don't like the idea of complicating the image loading routines and > modifying at load time. The runtime doesn't have any huge issues as Rhys said he already fixed it for pnet. > I think Qt# is digging up quite a few bugs ... (and some "virtual" bugs, > like this one).. It looks like Reflection.Emit API isn't as hot as they > were made up to be ... It looks like this was an issue in pnet, just like the PropertyMap one, so please take the flame bait somewhere else. lupus -- ----------------------------------------------------------------- [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
