[omniORB] wstrings get lost (OmniORB -> OpenOrb)?

[Duncan Grisby]

On Wednesday 13 March, brk@jenkon.com wrote:

> So it seems that nothing's getting through. Here's the exchange in GIOP
> terms:

You can see that omniORB is marshalling the wstring, so I think it
must be a problem at the OpenOrb end. Earlier on in the communication,
the omniORB trace should have said something like

omniORB: Client opened connection to giop:tcp:209.210.37.31:3155
omniORB: sendChunk: to giop:tcp:209.210.37.31:3155 38 bytes
omniORB: inputMessage: from giop:tcp:209.210.37.31:3155 20 bytes
omniORB:  send codeset service context: ( ISO-8859-1,UTF-16)

If you didn't see the thing about codeset service context, that would
explain why it's gone wrong, and we should look into why it isn't
being sent.

One guess is that maybe OpenOrb is confused by the byte order mark
that omniORB is sending:

> 1800 0000 fffe 4800 6500 6c00 6c00 6f00 ......H.e.l.l.o.
            ^^^^

The fffe is the little-endian form of feff, the UTF-16 byte order
mark. The GIOP spec requires that ugliness, despite the fact that GIOP
already knows the stream's endianness. Perhaps OpenOrb is confused by
that and drops the whole string. You might try hacking
src/lib/omniORB/orbcore/cs-UTF-16.cc around line 298 to remove the
BOM.

Another possibility is that wstrings are not null-terminated like
normal strings are -- perhaps OpenOrb has that wrong. Again, if you
hack cs-UTF-16.cc, you can try adding a null terminator.

Of course, if either of these hacks works, it shows that OpenOrb is
doing the wrong thing, so you should report it to them.

Have you tried sending a wstring from OpenOrb to omniORB?  Does that
work?

Cheers,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --