Endian-ness and RFC comms with Unicode servers (C/C++)

[Former Member]

Hi All,

Is there a best practice mechanism for handling structure and table parameters (and table parameters) when an application communicates via RFC with an Unicode server that resides on a platform with a different byte ordering?

My question relates less to the character encoding than to the alignment of non-character data.

When I set up a structure or table type for use in a function (say, the parameter <b>FIELDS</b> for function <b>RFC_GET_UNICODE_STRUCTURE</b>) I set the type to RFCTYPE_BYTE.

When communicating with the (non-unicode) dev systems in the ICC from Windows(little endian) or AIX(big endian) the integers returned from the call have the correct alignment for the client platform (i.e I can cast the raw bytes to a 4 byte int type and the value is what I expect).

This reordering of integer types within structures does not seem to occur when calling the same function from Windows on a Unicode server hosted on an AIX platform. For example when retrieving an integer that is expected to be 1 (0x01 0x00 0x00 0x00) I get 256 (0x00 0x01 0x00 0x00).

We can deal with this by detecting the byte ordering of the server system and, if it does not match the ordering of the client platform, reorder the data before casting. However, I would much prefer if my interpretation of the situation was wrong and that there was a simple way to avoid the endian-ness issue.

Best Regards,

Paul.

[Former Member]

Just a correction to the info in my question.

When reading the data from the <b>FIELDS</b> structure (RFC_FLDS_U) I had been using an incorrect offset (I was off by two bytes).

So the hex for the 4-byte integers should have been:

Little endian : 0x01 0x00 0x00 0x00 (1 on Windows)

Big endian : 0x00 0x00 0x00 0x01 (16777216 on Windows)

The issue still seems to exist though, that big endian integers (and, I assume, floats) show up in structures received from big endian Unicode SAP server by a little endian RFC application.

Sorry if the inaccurate data caused any confusion,

Paul.