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=79312 --- shadow/79312 2006-09-07 18:59:33.000000000 -0400 +++ shadow/79312.tmp.23463 2006-09-07 20:37:08.000000000 -0400 @@ -362,6 +362,25 @@ 0x00006f8c <GetPVoid+16>: mr r3,r0 ; <-- return value in r3 0x00006f90 <GetPVoid+20>: lwz r1,0(r1) 0x00006f94 <GetPVoid+24>: lmw r30,-8(r1) 0x00006f98 <GetPVoid+28>: blr End of assembler dump. + +------- Additional Comments From [EMAIL PROTECTED] 2006-09-07 20:37 ------- +> 1. Since "IntPtr" is defined as struct, why doesn't it fall to +> the same incorrect bindings as any other struct? Is it a +> special-case at the p/invoke code? + +System.IntPtr is just the metadata of intptr, which is one +of the base types of the common typing system, along with +byte, sbyte, int16 ... These type are blittable, i.e. +no marshaling is required. + + +> 2. Can I use a MarshalAs attribute to force the proper return +> value semantics? +> I've tried this but could not get desired behavior. + +No. Struct (composite) return values are always marshaled as +defined by the ABI. + _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
