[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[DotGNU]cscc - Constant coercion in function calls.
From: |
Jonathan P Springer |
Subject: |
[DotGNU]cscc - Constant coercion in function calls. |
Date: |
Fri, 25 Oct 2002 23:29:04 -0400 |
User-agent: |
Mutt/1.4i |
I apologize that if the basis for this e-mail is somewhat shaky, but I
wanted to get it onto the list before Rhys disappeared for the weekend.
Consider:
class blah {
static f(unlong i) { foo(i); }
static void Main() {
blah.f(0);
}
}
Before anyone asks, this is a highly generalized case representative of
a compilation error encountered in pnetlib compiling with cscc.
The problem:
C# spec states that integer constants are of the first type into which
they will fit in this list: int, uint, long, ulong. Therefore the "0"
above is "int".
Implicit conversion rules do NOT allow implicit conversion from signed
to unsigned, even for a constant (unless I missed something?).
Therefore, the above code should fail compilation because there is no
defined f that takes a signed argument. However, most programmers
assume it will work. This problem is cropping up in pnetlib in the
numeric conversion libraries.
See pnetlib/runtime/System/Byte.cs compiled with cscc for a concrete
example.
Question for the literati: Have I mis-stated something above? Or
should the call in Main really be 'blah.f(0uL)'? I prefer the latter,
but if M$'s compiler will do implicit constant conversion from signed to
unsigned, we may need to replicate the non-compliant behavior.
I'm willing either (a) edit pnetlib all over or (b) hack cscc to resolve
this problem; however, I would like some guidance on preferred
direction.
Cheers,
-js
--
-Jonathan P Springer <address@hidden>
------------------------------------------------------------------------------
"A standard is an arbitrary solution to a recurring problem." - Joe Hazen
- [DotGNU]cscc - Constant coercion in function calls.,
Jonathan P Springer <=