Fix the latest issues reported by coverity
Metadata Update from @mreynolds: - Issue assigned to mreynolds
14094 - dereference after null check in cl_cache.c 13685 - dereference before null check in cb_search.c 13680 - Explicit null dereferenced in memberof.c 13682 - Bad use of null-like value in ticket48005_test.py
Metadata Update from @mreynolds: - Custom field type adjusted to defect
<img alt="0001-Issue-49158-fix-latest-coverity-issues.patch" src="/389-ds-base/issue/raw/files/4ca8250c45b2278f3d53aeb991f5ca38d2266476a97f263afd10c037dd71be9c-0001-Issue-49158-fix-latest-coverity-issues.patch" />
Metadata Update from @mreynolds: - Custom field component adjusted to Stability - Custom field origin adjusted to Dev - Custom field reviewstatus adjusted to review
Of course, it's ok with your fix, but we usually avoid unnecessary NULL checking? "cb_search.c" 394 int 395 chainingdb_next_search_entry ( Slapi_PBlock *pb ) 658 if (referrals != NULL) { 659 slapi_ldap_value_free( referrals ); 660 }
"memberof.c" Not sure we need to do something on all, but there are more similar for statements... :) $ egrep groupattrs memberof.c | egrep "\<for\>" for (i = 0; configCopy.groupattrs[i] && ret == LDAP_SUCCESS; i++) for (i = 0; config->groupattrs && config->groupattrs[i] && rc == LDAP_SUCCESS; i++) for (i = 0; configCopy.groupattrs[i]; i++) for (i = 0; configCopy.groupattrs[i] && ret == LDAP_SUCCESS; i++) { for (i = 0; config->groupattrs && config->groupattrs[i]; i++) for (i = 0; configCopy.groupattrs && configCopy.groupattrs[i]; i++) for (i = 0; config->groupattrs[i]; i++) for (i = 0; config->groupattrs[i]; i++) for (i = 0; config && config->groupattrs[i]; i++) for (i = 0; config && config->groupattrs[i]; i++)
Patch revised:
<img alt="0001-Issue-49158-fix-latest-coverity-issues.patch" src="/389-ds-base/issue/raw/files/56560ef110d2b0982fe1da2d38b100a4941bed680549504f1909ae235c5e0d9e-0001-Issue-49158-fix-latest-coverity-issues.patch" />
You could probably make the null check separate, because you don't want to check this condition every single loop? However, the compiler may optimise this away somehow.
Metadata Update from @nhosoi: - Custom field reviewstatus adjusted to ack (was: review)
Looks good. Thank you, Mark!
I thought this was optimized, but maybe not. Lets address that in a separate issue if needed.
ecfbfc8..f77e777 master -> master
d589950..d8338ef 389-ds-base-1.3.5 -> 389-ds-base-1.3.5
75cde2c..8a758af 389-ds-base-1.3.4 -> 389-ds-base-1.3.4
Metadata Update from @mreynolds: - Custom field version adjusted to 1.3.4 - Issue close_status updated to: fixed - Issue set to the milestone: 1.3.4.11 - Issue status updated to: Closed (was: Open)
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/2217
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: fixed)
Login to comment on this ticket.