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



Hi Poul,

I haven't used these APIs, but taking a quick glance at your code and comparing it to the information center... it would appear to me that you didn't "align" your data structure.

Here's the C data structure:

struct _varBind{
struct _varBind * next;
char *oid;
unsigned char asn_type;
int val_len;
union {
int * int_val;
char * str_val;
} val;
};

It may not be obvious if you're not familiar with C programming, but this DS has fields like this:

pos 1-16 = next (pointer)
pos 17-32 = oid (pointer)
pos 33-33 = asn_type (char)
pos 34-36 = not used
pos 37-40 = val_len (integer)
pos 41-48 = not used
pos 49-64 = int_val (pointer)
pos 49-64 = str_val (pointer)

The "not used" fields are due to the alignment. In C integers are aligned on 32-bit (4 byte) boundaries. Likewise, long integers are aligned on 8-byte boundaries (but there aren't any in this example) and pointers are aligned on 16-byte boundaries. Since val_len wouldn't have been on a 4-byte boundary, the system automatically moves it forward to position 37 to put it on a 4-byte boundary. Same with the union at the end... int_val and str_val need to be on a 16-byte boundary, so it's pushed forward to position 49.

Now, RPG's alignment rules are a little different. RPG will align pointers (because it has to for them to work!) but it won't align integers.

Consequently, your RPG definition looks like this:

pos 1-16 = NEXT
pos 17-32 = POID
pos 33-33 = ASNTYPE
pos 34-37 = VALLEN
pos 38-38 = not used
pos 49-64 = VALPTR

As you can see... your VALLEN does not match the C definition for val_len because it's not aligned the same way.

RPG has an ALIGN keyword that you can put on a data structure to make it align integers as well as pointers. If you specify that align keyword, you might have better results. i.e.:

D VARBIND DS ALIGN
D NEXT * INZ(*NULL)
D POID * INZ(%ADDR(OID))
D ASNTYPE 1A
D VALLEN 10I 0 INZ(50)
D VALPTR * INZ(%ADDR(VALUE))

That ALIGN keyword (on the DS line above) should force the RPG alignment to match the C alignment.

Like I said, I haven't used these APIs, and I didn't test the above theory... so I could be completely wrong. But, hey, it's something to try :)

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.