dotgnu-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[DotGNU]Enum declaration; Conflicts and Blame for Interoperability Probl


From: Marcus
Subject: [DotGNU]Enum declaration; Conflicts and Blame for Interoperability Problems
Date: Tue, 7 Jan 2003 04:18:07 -0600
User-agent: KMail/1.5.9

My reason for posting this is two-fold. I have a specific problem with
compatibility between Mono and Pnet, and I want to point out that situations
like this are not a unusual occurrence.

The problem occurred as part of my testing to assess how well Qt#
interoperates with Mono and Pnet. I discovered that when classes containing
enums were compiled into libraries by the Mono C# Compiler (mcs), Pnet's C#
Compiler (cscc) did not handle the enum's member properly. Specifically, with
a declaration like this

class QFont {
public enum Weight { Light = 25, Normal = 50, DemiBold = 63, Bold = 75, Black
= 87 } }

Pnet believed that the type of QFont.Weight.Bold was "int" instead of
"QFont.Weight". The problem came down to the fact that cscc was expecting
enums to be declared the way that csc and the examples in ECMA 335 do:

.class nested public auto sealed ansi Weight extends [mscorlib]System.Enum
{
        .field public specialname rtspecialname int32 value__
        .field public static literal valuetype QFont/Weight Light =
int32(0x00000019)
        .field public static literal valuetype QFont/Weight Normal =
int32(0x00000032)
        .field public static literal valuetype QFont/Weight DemiBold =
int32(0x0000003F)
        .field public static literal valuetype QFont/Weight Bold =
int32(0x0000004B)
        .field public static literal valuetype QFont/Weight Black =
int32(0x00000057)
}

whereas mcs produces

.class nested public auto sealed ansi Weight extends [mscorlib]System.Enum
{
        .field public specialname rtspecialname int32 value__
        .field public static literal int32 Light = int32(0x00000019)
        .field public static literal int32 Normal = int32(0x00000032)
        .field public static literal int32 DemiBold = int32(0x0000003F)
        .field public static literal int32 Bold = int32(0x0000004B)
        .field public static literal int32 Black = int32(0x00000057)
}

Note that the static fields have type "int32" in mcs's version but
 "valuetype" in csc's.  In ECMA Partition II, Section 13.3, the normative
 text is not entirely clear on this  point. So I was not sure who was "right"
 or "wrong." I decided to talk to both Pnet developers and Mono developers.
 The problem now is that the Mono developers claim that their declaration is
 correct and in compliance with the spec, whereas the Pnet are equally
 adamant that Mono is wrong and that Mono should fix their C# compiler.

I honestly do not know who is right or wrong in this situation. What I do
 know is that I cannot compile code with Mono's C# compiler and expect it to
 link using Pnet's compiler, nor the way way around. Even worse, the one
 compiler that does work correctly with both systems is Rotor's csc.
 Ironically, to develop software for both Free CLI's, the most compatible
 compiler is a non-Free one.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]