Re: Re: ILE C/400 calling RPGLE -- RPG400-L

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.)