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