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

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

CL programs handle "1A" and "1N" fields differently than RPG does, unless
your RPG program specifies ExtProc(*CL:myProcName).  Alternately, if you
had specified a TYPE(*CHAR) LEN(2) field as the return value in your CL
program, the problem would have gone away.

With C, the difference would be due to widening.  You can also control
that with a ExtProc() keyword.  More info is here:

http://publib.boulder.ibm.com/iseries/v5r2/ic2924/books/c092508421.htm#HDRDEXTPRC

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

No.  Return values are always passed by VALUE.   You either return the
value of a variable, or you return the value of a pointer.  You cannot
pass return values by reference.


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

Parameters and return values are not the same thing.   Return values are
ALWAYS by value.  Parameters in RPG are reference by default.

> (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?

Yes, you're missing something :)  You've got parameters and return values
mixed up. :)   Return values are always by value.  Though, you can return
a pointer which is very similar to returning a variable by reference...

> (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?

See above.


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

And here you're talking about parameters, again, different from return
values.   You're passing the parms by reference, which is actually passing
a pointer.  My guess is that a pointer is always a scalar type, so there's
no conflict.


> 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 have no argument with using int to do bitwise operations.  However, I
don't think you should lie to the compiler and tell it that the procedure
expects a character field when in fact it expects an integer.  The RPG
prototype should match the C prototype, which should match the procedure
interface.

If you want to convert back & forth between char and int, you can do so
easily in RPG with a data structure, and easily in C with a union or by
using memcpy().

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

That's fine, but do it in a straightforward, self-documenting way, rather
than relying on quirks of the way that parameters are passed.