× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 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.