Another C-to-PB datatype question

[Sam Whiteman]

Hello, everyone.

I cried wolf with what I thought was a datatype conversion issue yesterday, and Tom H. kindly prodded me to proofread and find that it was a typo in my function alias. I hope you'll still take me seriously with this next issue, which I've scoured for typing errors.

Still dealing with the same DLL, C headers and working C code.

Here's a function as declared in C:

ldap_search_ext_s LDAP_P((
LDAP *ld,
LDAP_CONST char *base = "o=blsnyc",
int scope,
LDAP_CONST char *filter,
char **attrs,
int attrsonly,
LDAPControl **serverctrls,
LDAPControl **clientctrls,
struct timeval *timeout,
int sizelimit,
LDAPMessage **res ));

Where:

- LDAP, LDAPControl, and LDAPMessage are opaque structures (handles) that should require only DWORDs to hold 'em (I have the LDAP struct working fine as a DWORD in PB).

- timeval is technically a struct of two longs, though I'm passing it as a NULL in C:

typedef struct timeval {
long tv_sec;
long tv_usec;
};

- attrs is a "a NULL-terminated array of strings," though again I just want to pass a NULL and so am considering it opaque like the first two. This *may* be the trouble spot, though. Anyway, read on and see if you agree.

I have this working in C:

#define LDAP_SCOPE_SUBTREE 0x0002
#define LDAP_NO_LIMIT 0

int rc;
char *searchBase;
char *attribute, *dn;
LDAP *ld;
LDAPMessage *searchResult;

rc = ldap_search_ext_s(
ld,
searchBase,
LDAP_SCOPE_SUBTREE,
"(objectclass=*)",
NULL,
0,
NULL,
NULL,
NULL,
LDAP_NO_LIMIT,
&searchResult );

So I tried the following in PB:

DECLARE FUNCTION ldap_search_ext_s LIB "LDAPSDK.DLL" ALIAS "ldap_search_ext_s" (BYVAL LDAP AS DWORD, _
szSearchbase AS ASCIIZ, _
BYVAL lScope AS LONG, _
szFilter AS ASCIIZ, _
pAttrs AS DWORD, _
BYVAL lAttrsonly AS LONG, _
pServerctrls AS DWORD, _
pClientctrls AS DWORD, _
pTimeout AS DWORD, _
BYVAL lSizelimit AS LONG, _
pLDAPMessage AS DWORD) AS LONG

%LDAP_SCOPE_SUBTREE = &H0002
%LDAP_NO_LIMIT = 0

DIM ldap AS DWORD
DIM hr AS LONG

DIM szSearchbase AS ASCIIZ * 256
DIM lScope AS LONG
DIM szFilter AS ASCIIZ * 256
DIM pAttrs AS DWORD
DIM lAttrsonly AS LONG
DIM pServerctrls AS DWORD
DIM pClientctrls AS DWORD
DIM ptimeout AS DWORD
DIM lSizelimit AS LONG
DIM pLDAPMessage AS DWORD

szSearchbase = "o=blsnyc"
lScope = %LDAP_SCOPE_SUBTREE
szFilter = "(objectclass=*)"
pattrs = %NULL
lAttrsonly = 0
pServerctrls = %NULL
pClientctrls = %NULL
pTimeout = %NULL
lSizelimit = %LDAP_NO_LIMIT

hr = ldap_search_ext_s (ldap, _
szSearchbase, _
lScope, _
szFilter, _
pAttrs, _
lAttrsonly, _
pServerctrls, _
pClientctrls, _
ptimeout, _
lSizelimit, _
pLDAPMessage)

However, no joy: I get the API error %LDAP_PARAM_ERROR, which isn't very well-documented but which evidently means some kind of datatype error.

Note that the ldap handle must be passed BYVAL to avoid a GPF (shown by its successful use in other functions). (I also know that there are some unnecessary initializations of variables, but I was trying to parallel the C very closely for now.)

Anybody see what I'm too dumb and bleary-eyed to catch? Geez, I really hope it's not another simple typo.

Thanks in advance,

Sam

------------------

[Sam Whiteman]

Addendum: I misedited one part of my post:

ldap_search_ext_s LDAP_P((
LDAP *ld,
LDAP_CONST char *base = "o=blsnyc",

is actually:

ldap_search_ext_s LDAP_P((
LDAP *ld,
LDAP_CONST char *base,

Obviously, the value assignment is actually at declaration:

int rc;
char *searchBase = "o=blsnyc";
char *attribute, *dn;
LDAP *ld;
LDAPMessage *searchResult;

Just cut-and-pasted wrong, problem as real as before, please don't run away.

-Sam

------------------

[Tom Hanlin]

The PB code is passing pointers to nulls in a few places where it
needs to pass null pointers-- that is, rather than a pointer to zero,
it needs to have pointers that are zero.

szFilter = "(objectclass=*)"

hr = ldap_search_ext_s( _
ldap, _
szSearchBase, _
%LDAP_SCOPE_SUBTREE, _
szFilter, _
BYVAL %NULL, _
0, _
BYVAL %NULL, _
BYVAL %NULL, _
BYVAL %NULL, _
%LDAP_NO_LIMIT, _
pLDAPMessage)


------------------
Tom Hanlin
PowerBASIC Staff

[Sam Whiteman]

Tom,

Ugh. Yes, the BYVAL makes exact sense. In typical form. "I thought I'd tried that already."

Thanks again,

Sam

------------------

[Tom Hanlin]

No fear. "Programmer" is a verb, not a noun: it's a process of learning.

------------------
Tom Hanlin
PowerBASIC Staff