Re: possible bug in wchar.i (swig 4.0.2) ?

Gareth Francis <[email protected]>
Newsgroups gmane.comp.programming.swig
Message-ID <CAEKysgSV8z-Ew5no73jNML4KpgvOeaMXpyTYT+SYTmwy9oLS8A@mail.gmail.com>
(Nice, more C# unicode issues. Happy to investigate later if no one else
picks this up)

At a glance I can't find a test case for this case. If I recall what should
be happening is the C++ layer returns a wchar_t*, which PInvoke should
automatically convert into some form of C# string.
There were some relatively recent changes in this area, think they went
into the 4.x release, believe unicode/strings work correctly now unless
you're running under mono.

Does the 'csout' typemap for for you? (explicit getter method such as
wchar_t* getName()). Typemaps look similar so I'd expect them both to be
affected.

The call to PtrToStringUni is essentially what the wrappers do already when
creating new string objects, so should give the right encoding/work for now.

On Fri, 4 Sep 2020 at 10:17, Carlos Frederico Biscaya <[email protected]>
wrote:

> Hi guys,
>
> I have been trying to create a c# wrapper for a c++ structure that looks
> like this:
>
> struct Person {
>     const wchar* name;
> }
>
> If I include wchar.i in my project file, I get an interface that looks ok.
> BUT: When trying to compile, the getter for name will not be compilable
> because of code that looks like this:
>
> public string name {
>    get {
>        string ret = SomethingPINVOKE.Person_name_get(swigCPtr);  // the
> return value here is a System.IntPtr
>    }
> }
>
> assigning a System.IntPtr to a string is not possible and will therefore
> not build.
>
> I would suggest adapting the typemap for the getter generation so it looks
> like this:
>
> %typemap(csvarout, excode=SWIGEXCODE2) wchar_t * %{
>     get {
>       string ret =
> global::System.Runtime.InteropServices.Marshal.PtrToStringUni($imcall);$excode
>       return ret;
>     } %}
>
> The typemap for csout already contains the conversion, and maybe I am not
> correct in my understanding of the problem here, but as it is right now,
> without this change the generated code is unbuildable.
>
> Best regards,
> Fred
> _______________________________________________
> Swig-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/swig-user
>


-- 
--------------------
Gareth Francis
www.gfrancisdev.co.uk

_______________________________________________
Swig-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/swig-user
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.