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: -------