Full_Name: Martin Evans
Version: 2.4.10
OS: Linux/F9
URL:
Submission from: (NULL) (138.37.8.59)
In a slapi pre-modify function (SLAPI_PLUGIN_PRE_MODIFY_FN) you can get a null
terminated array of LDAPMod modifications. Like so:
/* get list of mods */
if (slapi_pblock_get(pb,SLAPI_MODIFY_MODS,&mods) || !mods) {
LOG("[%i] Error retrieving LDAPMods.\n",conn_id);
return (PLUGIN_STOP);
}
DEBUG("[%i] Got LDAPMods.",conn_id);
If you loop over these and extract the mod_op values which are held in
mod->mod_op, the values seem to be offset by 128. i.e. an add operation, which
should have a value of 0 (LDAP_MOD_ADD) has a value of 128. A delete operation,
should have 2 (LDAP_MOD_DELETE) it seems to be set to 130.
The numbers differ only in the 8th bit. So I'm wondering if there is a strange
signed/unsigned int conversion thing going on somewhere.
For info, I need to do the following to fix those values in my slapi code so
that my comparisons of mod->mod_op match the #defined macros
LDAP_MOD_(ADD|DELETE|&c):
while((mod=*mods)){
/* workaround for bad mod_op values */
if(mod->mod_op>127){
DEBUG("[%i] mod_op value (%i) is offset, fixing.",conn_id,mod->mod_op);
mod->mod_op-=128;
}
if(mod->mod_op==LDAP_MOD_ADD) {
...
}
}
Thought I'd report it.
Cheers,
Martin.