Hi Ulrich, thanks for your reply!
> 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.
Haven't ever done one of these, but yes, it looks like time.
> 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?
We're running IBM XL C/C++ Enterprise Edition for AIX, V9.0, also rather old.
I've noticed that the settings which this note seem a little odd/irrelevant. One does need to compile for position independent code for a shared library, but that's not required for the main program. Options like gcc's -funsigned-char could break our code. So I guess there is an art in figuring out what needs to match and what doesn't, because it is internal to the libraries. Thank you for the background on UTF-16. Much as I don't care for it, I see the rationale. (I just wish there were some ASCII flavored functions so that non-unicode applications don't have to constantly shuffle field names and data through intermediate buffers and functions.)
>> 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.
When I compiled using the guideline from the note, cU("hello") gets preprocessed to u"hello" . The compiler did not like this. When I added -DSAPwithoutUTF16_LITERALS it gets preprocessed to _U16_LIT_cU "hello" which is what I expect the u16lit.pl is looking for? This compiles and links without error. I don't think this is the problem, although perhaps there are other settings I need as well.
> 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?!
RfcGetVersion() takes three pointers to unsigned ints and returns a static SAP_UC pointer. String handling does not come into play until after the call. Here's the the version test function from the .i file:
int rfc_test()
{
const SAP_UC *ptr;
char work[256] = "";
SAP_UC Uwork[sizeof(work)];
unsigned int major, minor, patch;
#line 926
ptr = RfcGetVersion(&major, &minor, &patch);
U2char(work,sizeof(work),ptr,0);
sprintf(work + __strlen(work), " (%d-%d-%d)", major, minor, patch);
set_console_log((&_iob[1]));
debug_to_fd = -1;
sap_msg(40, work, 0, "", "");
return (int)major;
}
If the truss is to be believed, the program crashed within RfcGetVersion, it never returned. So this remains mysterious as to how such a trivial function could fail. I shall keep looking and open that OSS ticket.
One other question. Are you aware of anyone using the RFC libraries with GCC instead of that platform's native CC??
Thanks!
Rich
BTW, I will get around to responding to your answer to my Locating/Linking NWRFC libraries post. 