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



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 ]
Thanks Simon,  I think I get you and will give it a shot.

-----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.
--------------------------------------------------------------------
   FlyByNight Software         AS/400 Technical Specialists
   http://www.flybynight.com.au/

   Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
   Fax:   +61 3 9419 0175   mailto: shc@flybynight.com.au   \ /
                                                             X
                 ASCII Ribbon campaign against HTML E-Mail  / \
--------------------------------------------------------------------

_______________________________________________
This is the C programming iSeries / AS400 (C400-L) mailing list
To post a message email: C400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/c400-l
or email: C400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/c400-l.


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.