Please do not reply to this email- if you want to comment on the bug, go to the URL shown below and enter your comments there.
Changed by [EMAIL PROTECTED] http://bugzilla.ximian.com/show_bug.cgi?id=78422 --- shadow/78422 2006-05-16 20:27:46.000000000 -0400 +++ shadow/78422.tmp.16273 2006-05-17 06:32:29.000000000 -0400 @@ -3,13 +3,13 @@ Version: unspecified OS: unknown OS Details: Status: NEW Resolution: Severity: Unknown -Priority: Normal +Priority: Wishlist Component: C# AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] QAContact: [EMAIL PROTECTED] TargetMilestone: --- URL: @@ -40,6 +40,37 @@ I am unsure of the last working revision. The bug was just reported to me today on infrequently recompiled code. I'll try to binary search tomorrow -g + +------- Additional Comments From [EMAIL PROTECTED] 2006-05-17 06:32 ------- +Hmm, no need to search :-) I believe the patch that changed it was: + + 2006-04-19 Raja R Harinath <[EMAIL PROTECTED]> + + * expression.cs (Cast.ResolveLValue): Remove. The result of a + cast is never an lvalue. + +Changing your code to: + + *(int *)((int)p) = 0; + +i.e., removing the redundant (int) cast, makes it work. + +Section 14.6.6 (Cast expressions) says: The result is always +classified as a value, even if E denotes a variable. + +--- + +Now, either CSC is buggy, or there may be some funky cast +disambiguation rules that may make CSC treat your code as: + + (int) ( *(int*)((int)p) = 0 ) + +while we treat it as + + ( (int) ( *(int*)((int)p) ) ) = 0 + +If you really want to keep your code, with the redundant (int) cast, I +welcome you to fix mcs ;-) _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
