Hi Richard,
first of all: I think you should better open an OSS ticket for this. Looks like a tricky problem. The component to start with would be BC-OP-AIX. (The compiler settings for compiling SAP software on the different platforms are not taken care of by the various application teams, but centrally by one "platform team". They have OS and compiler experts from IBM in their team, so should be able to solve this problem fastest.)
Nevertheless I have a few comments that might be helpful.
- The compiler settings in the note are the ones that were used to compile the NW RFC library. They refer to IBM XL C/C++ compiler version 8.0, which is already quite old (2005). What is the OS and compiler version in your landscape?
- It could be that with newer compiler versions the extra step with u16lit.pl is no longer necessary. I know for example that this is the case on Linux: starting with gcc 4.8 (if I remember correctly), gcc supports UTF-16 string literals out-of-the-box, so the workaround between preprocessor and compiler step is no longer necessary. But the IBM team should be able to tell you, whether this is the case for the compiler version you are using. (That would explain the errors you get, when trying to compile the u16lit.pl output...)
(Perhaps I need to give a bit of background on this topic: when SAP switched to Unicode, there were several different "Unicodes" around: Windows had 2-byte per char, most Unixes had 4-byte per char and Linux used UTF-8, which is the worst, because it may be anything between 1 and 5 bytes per char, depending on the character... Therefore SAP intodruced a "platform-independ" Unicode type, 2 byte UTF-16, so that SAP systems running on different platforms all have the same data format and can smoothly communicate with each other. And those platforms/compilers, that did not support UTF-16, needed "special treatment".) - > The compilation of our program fails because the preprocessor pass does not treat the cU()
> macro correctly. It looks as if it creates 16-bit unicode literals when it shouldn't
This I don't understand: the whole purpose of this macro is to create 16-bit Unicode literals...! My first guess is that the -DSAPwithoutUTF16_LITERALS that you added, is causing the crashes. RfcGetVersion() is returning a string, so in your case it must somehow try to return 4-byte per char into a buffer that has allocated only 2-byte per char, leading to buffer overflow and SIGSEGV?!
Best Regards, Ulrich