(ITS#5635) slapi SLAPI_MODIFY_MODS mod->mod_op offset.

[m.d.t.evans@qmul.ac.uk]

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.