[Mono-list] Wrapper additions

Paolo Molaro lupus@ximian.com
Thu, 20 Sep 2001 13:20:21 +0200

On 09/20/01 Dietmar Maurer wrote:
> > I think we shouldn't use the string type to pass char* data back and forth
> > to unix APIs. The problem is: string is supposed to be unicode chars, but
> > what encoding does that API use? latin1? utf8?
> UTF8, or the same char set which is used for system calls?
> > We don't know and the lame
> > attribute MS added (CHAR_SET_ANSI) is only usable with their APIs.
> > We should probably use byte[] and have the caller decide the proper encoding.
> > Comments welcome.
> I thought its the task of PInvoke to convert from unicode to the system char set
> and back? Passing a byte[] only moves the problem to another location.

Yes, but hopefully to a location that knows better.
For example, we may have library A that takes char* strings in latin1
encoding and a library B (say, Gtk+ 2.0) that takes char* strings in utf8
encoding. The resulting C# code is:

	[DllImport("A", EntryPoint="afunc"]
	public unsafe static extern void afunc (string arg);

	[DllImport("B", EntryPoint="bfunc"]
	public unsafe static extern void bfunc (string arg);

How can the P/Invoke code know when it has to convert a UCS-2 string to
utf8 or latin1? Even if the Charset argument of DllImport could be changed
to be more flexible, it still applies to a whole function, not to a single
argument/return type. What if a function takes two char* arguments, one in
latin1 and one in utf8? Only the caller may know that, unless the DllImport
attribute spec is changed to take this issues into account and I really hope
the ECMA folks will consider some solutions for this.

> > opendir () return a pointer and you can't cast it (portably) to
> > an int. Use gpointer (the same issue is in mono_wrapper_getenv and
> > mono_wrapper_environ).
> The problem is in the perl script. Here is a patch:

Oh, thanks!


lupus@debian.org                                     debian/rules
lupus@ximian.com                             Monkeys do it better