m.d.t.evans@qmul.ac.uk wrote:

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.

That's the LDAP_MOD_BVALUES flag. There's no bug here, this ITS will be closed.