Skip to Content
author's profile photo Former Member
Former Member

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

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.

Add a comment
10|10000 characters needed characters exceeded

Related questions

1 Answer

  • author's profile photo Former Member
    Former Member
    Posted on Feb 01, 2005 at 05:18 PM

    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.

    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.