#49158 Fix latest coverity issues
Closed: wontfix Opened by mreynolds.

Issue Description

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

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 (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:

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!

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.

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.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: fixed)

Metadata