http://d.puremagic.com/issues/show_bug.cgi?id=3086
Summary: TypeInfo opEquals returns incorrect results
Product: D
Version: 1.045
Platform: x86
OS/Version: Linux
Status: NEW
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: nfx...@gmail.com
If a and b are TypeInfo, a==b can return true, even if a and b refer to
different types (and object instances). Both Phobos and Tango are affected.
The code example at the end of this report demonstrates this. The second
assertion fails, because opEquals() returns true when comparing two different
TypeInfos. This is because opEquals compares the two TypeInfo by their
toString() results. The returnd string doesn't contain any information about
the delegate parameters, ths delegates with the same return type are considered
equal.
I wonder if TypeInfo.opEquals() shouldn't only compare the addresses of the
TypeInfo objects. The string comparision seems pointless, even if you use DLLs.
With DLLs, you should either not attempt to use objects from another instance
of the runtime, or you should use proper solutions like DDL, which enables to
DLLs to share the same runtime. The string comparision hack is hard to get
right, because the compiler needs just another method to encode the complete
information about a type as string. (A better hack would be to compare the
mangled symbol names.)
//program will execute successfully if bug is fixed
class X {
void a() {}
void b(int z, short c) {}
}
void main() {
auto z = new X();
TypeInfo a = typeid(typeof(&z.a));
TypeInfo b = typeid(typeof(&z.b));
//doesn't fail (ok)
assert(a !is b, "1");
//fails (which is wrong, because both TypeInfos are different!)
assert(a != b, "2");
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
