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=80426

--- shadow/80426        2007-01-02 11:34:43.000000000 -0500
+++ shadow/80426.tmp.19047      2007-01-02 22:59:16.000000000 -0500
@@ -1,14 +1,14 @@
 Bug#: 80426
 Product: Mono: Class Libraries
 Version: 1.2
-OS: 
+OS: unknown
 OS Details: RHEL kernel 2.6.9-42 on i686
 Status: NEW   
 Resolution: 
-Severity: 
+Severity: Unknown
 Priority: Wishlist
 Component: System
 AssignedTo: [EMAIL PROTECTED]                            
 ReportedBy: [EMAIL PROTECTED]               
 QAContact: [EMAIL PROTECTED]
 TargetMilestone: ---
@@ -57,6 +57,21 @@
 
 How often does this happen? 
   Each time
 
 
 Additional Information:
+
+------- Additional Comments From [EMAIL PROTECTED]  2007-01-02 22:59 -------
+Are you sure you're always getting narrow strings?
+
+The last time I looked into this behavior, your scenario wouldn't work
+because, under Unix, sizeof(wchar_t) == sizeof(int) == 4, while Mono
+would pass Win32 WCHAR strings (sizeof(WCHAR) == 2).  So wchar_t*
+would still be marshaled "wrong," as strings would marshal as UTF-16
+(WCHAR*) instead of UTF-32 (wchar_t*).
+
+This was by design.
+
+Has this changed?  Are you *sure* you're getting
+0x48,0x65,0x6c,0x6c,0x6f,0x00 and not 0x0048 0x0065 0x006c 0x006c
+0x006f 0x0000?
_______________________________________________
mono-bugs maillist  -  [email protected]
http://lists.ximian.com/mailman/listinfo/mono-bugs

Reply via email to