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.