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

Issue Description

Fix the latest issues reported by coverity


Metadata Update from @mreynolds:
- Issue assigned to mreynolds

7 years ago

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

7 years ago

Metadata Update from @mreynolds:
- Custom field component adjusted to Stability
- Custom field origin adjusted to Dev
- Custom field reviewstatus adjusted to review

7 years ago

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++)

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)

7 years ago

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)

7 years ago

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)

3 years ago

Login to comment on this ticket.

Metadata