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:email@example.com] Sent: Wednesday, July 10, 2002 4:46 PM To: firstname.lastname@example.org 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 ) >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.