[omniORB] omniORBpy sometimes corrupts wide strings

[Andrew Novikov]

> > omniORBpy doesn't always marshal wstrings correctly. For instance, if
> > one defines:
> 
> Can you post a complete example that exhibits the problem?  The patch

Yes, I've made one. It is attached to this letter. When I run it on my
Fedora Core 1 machine I see this:

$ ./wstrtest_clt.py IOR:0100 ... 0
Traceback (most recent call last):
  File "./wstrtest_clt.py", line 18, in ?
    ifr.foo(s)
  File "./wstrtest_idl.py", line 61, in foo
    return _omnipy.invoke(self, "foo", _0_wst.Iface._d_foo, args)
omniORB.CORBA.COMM_FAILURE: Minor: COMM_FAILURE_WaitingForReply,
COMPLETED_MAYBE.

and this:

$ ./wstrtest_i
IDL object wst::Iface IOR = 'IOR:0100 ... 0'
omniORB: From endpoint: giop:tcp:10.99.77.9:43869. Detected GIOP 1.2
protocol error in input message. Connection is closed.

When I set traceLevel to a higher value it becomes clear that ORB
corrupts strings during marshaling.

> you suggest is only correct in a limited set of circumstances.
> Depending on the platform and the Python configuration options, it may
> not work.

I have had an opportunity to observe it ;) That patch worked fine on FC
1 and failed on SuSE (obviously because SuSE ships python compiled with
unsigned short strings as apposed to RH with native wchar_t strings). I
attached a more portable patch to this letter.
-- 
Andrew Novikov <anovikov at artezio.ru>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.tar.gz
Type: application/x-compressed-tar
Size: 1726 bytes
Desc: not available
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20040316/7e089c70/test.tar.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: omniORBpy-wstring-marshal.patch
Type: text/x-patch
Size: 1319 bytes
Desc: not available
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20040316/7e089c70/omniORBpy-wstring-marshal.bin