|
Thanks for the responses to my question. It has been many years since I've done C, and that was on a PC. I will try expecting a structure in the 'C' code. (BTW, I'm using MEMCPY to avoid the null terminated string issue.) >> You have 5I0 which is a "short" in C, not an "int". >> -Bob Using 5I 0 worked for returning an INT, possibly because of the widening C does for me. I will try it as a 10I 0 to make it actually be an 'int'. (Originally, I returned an indicator. That was fine for RPG but even CL got weird responses, let alone the 'C' routines. That all cleared up when I switched to an 'int'. RPG Indicators are '0' / '1' char values, are they not? <The same as CL logicals?> Are they actually a pointer to a char?) >> When calling a procedure, an RPG programmer has a choice -- but it's >> reference if you do not specify "value". I used a pointer in the C prototypes for the 'unsigned int' and 'char' return values because RPG is sending the return values by reference, which is by pointer. I can not put VALUE on the PR line to tell RPG the returned data is to be passed by value. (We're developing for V4R3, as several clients are still at that level.) Am I missing something here? I was surprised to see the 5I 0 worked, as I took it that RPG was returning it as a reference but C was expecting a value. Does the ILE environment do this conversion for me auto-magically, so by putting a pointer in the 'C' prototype I'm actually trying to use a pointer with the value that I was trying to point at, not the pointer TO that value? (I saw something about intermediate values, but I thought that was only for CONST and VALUE options. Or did I miss the boat altogether and RPG always returns by VALUE, regardless of the way the parms are passed? >> In this case, it's not just poor practice. It won't work at all if you prototype one to return an >> integer and the other to return a string. The system handles integers ("scalar" types) and strings >> ("aggregate" types) differently, so even though they're both 4 bytes, they aren't returned the same >> way. Same for passing by value. In the case of my one 'C' procedure that is called by RPG, the RPG is prototyped to have 2 parms, each 4A, while the 'C' is prototyped with 2 pointers to unsigned ints. For a while it was the ONLY routine that worked. The reason I used 4A in RPG was because that is what the compiled translated the 4H (Hexadecimal) fields in the DDS to be. While the 'C' compiler made them into char[4], I wanted to do bit-wise operations on the whole, and it was easier to just treat them as unsigned ints. Perhaps I had a bad teacher, but this was touted at the time to be the way to code 'C'. I could change the procedure to expect character arrays, but I'd have to cast them as unsigned ints anyway to do the bit manipulations over the entire 4 bytes, would I not? (As I said earlier, it has been many years since I've done 'C', and I have no C manuals to reference except the IBM ILEA C/400 pdfs.)
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.