RE: [C400-L] Calling some vendor "C" code from RPGIV

["Westdorp, Tom" <Tom.Westdorp@xxxxxxxxxxxxxxxxxx>]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
--
[ Picked text/plain from multipart/alternative ]
Still working on this with some intermediate success.  Out of 4 parms, looks
like three are working okay but...

The first parm is the string that will get digested.

Proto currently looks like this:
D Sha1            PR                  ExtProc('sha1')
D  Buffer                         *   Value
D  BfrLength                    10u 0 Value
D  iv                           10u 0 Dim(5)
D  Digest                       10u 0 Dim(5)

RPG Usage is:
D p_PIN#          s               *
D pdiv            s             10u 0 Dim(5)
D r_digest        s             10u 0 dim(5)
PIN# = PIN + x'00';
p_PIN# = %addr(PIN#);
Sha1(p_PIN#: 4 : pdiv : r_digest);

I walked away from *varsize in case of a problem with the stored length, I
hard coded the length to avoid difficulties in one side or the other
not/counting the null terminator.

Results are:
In the RPGIV program running debug:
PIN# = '1211'
P_PIN# = SPP:FB9124C12F001B48
eval p_pin#:x 10 gets 00000     F1F2F1F1 00...... ........ ........   -
1211............

in the C program:
buf    = SPP:FB9124C12F001B48
eval buf:x 10 gets    00000     80000000 00...... ........ ........   -
Ø...............

buffer = SPP:FB9124C12F001B48
eval buffer:x 10 gets 00000     80000000 00...... ........ ........   -
Ø...............

C gets the right pointer, but the data at that pointer got changed????  In
no visible lines of code.  Just F22'd down into the function.  The C program
gets the right length, gets the 5 element array (I see it get loaded into C
variables) and eventually returns an answer in r_digest that I can see.
But since it's not based on the initial string... bzzzt.

The initial string will not change, and I've tried it as a const without
success.

Any ideas anyone?

Thanks!

-----Original Message-----
From: Simon Coulter [mailto:shc@flybynight.com.au]
Sent: Wednesday, July 10, 2002 4:46 PM
To: c400-l@midrange.com
Subject: Re: [C400-L] Calling some vendor "C" code from RPGIV

Hello Tom,

You wrote:
>void sha1( void *buf, unsigned long len, unsigned long *iv, unsigned long
>digest[5] )
>and I'm trying to figure out the prototype.
>D Sha1            PR
>D  Buffer                    32767a   Const Options(*Varsize)
>D  BfrLength                    10i 0 Const
>D  IV                           10i 0 Const
>D  Digest                       10i 0 Dim(5)

Based on the above C prototype I would code:
D Sha1            PR
D  Buffer                    32767a   Const Options(*Varsize)
D  BfrLength                    10U 0 Value
D  IV                           10U 0
D  Digest                       10U 0 Dim(5)

>So I guess I do something RPGIV like:
>Sha1( PIN# : %len(PIN#) : ???? : Digest );
>where Digest is an RPGIV array of 8a dim(5)?

No.  According to the above C prototype, Digest is an array of unsigned
long integers (i.e., 10U 0) with 5 elements.

>I have no idea what the *buf and *iv things mean.

You have to read the complete definition.  The * means a pointer but you
have to read the stuff to the left of the * to know what data type the
pointer references.

void *buf means a pointer to a buffer i.e., the address of some storage of
arbitrary length.

unsigned long *iv means a pointer to an unsigned long integer.

When C uses pointers to integers it usually means the called
procedure/function intends to change the value in that storage.  Hence the
lack of CONST on my prototype definition above.

You also need to 'know' that C expects most things to be passed by value
hence the use of VALUE on my prototype.  Arrays are passed by reference.
Pointers are passed by value but that is the same as a variable passed by
reference hence the use of a large *VARSIZE buffer rather than a pointer.
It is not apparent from the C prototype whether the C procedure intends to
alter the contents of the buffer (i.e., what does sha_update do with the
buffer?) but given the C prototype it would be possible to change the
contents of buffer so you probably ought to remove CONST from the buffer
definition.  (To make it clear that the contents of buffer is not to be
changed they should have coded const void * buf or better const void *
const buf).

If this isn't clear then let me know and I'll do a Prototypes-101 append
explaining how to transform the supplied C prototype of sha1 into RPG IV.

Regards,
Simon Coulter.