Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Coverity fixes #1296

Merged
merged 4 commits into from
Sep 3, 2023
Merged

Coverity fixes #1296

merged 4 commits into from
Sep 3, 2023

Conversation

natoscott
Copy link
Member

No description provided.

@Explorer09
Copy link
Contributor

I remember you argued about "non-null-pointer-assert" being just "line noise in the code".

@natoscott
Copy link
Member Author

natoscott commented Sep 1, 2023

Yes, that's correct. That's not what this change is doing.

By NULL-pointer-assert we refer to the following ...

assert(ptr != NULL);
if (ptr->x ...) {
   ...
}

In this scenario, the assert line is not useful (IMO) because the very next line of code performs the same function, for both debug and non-debug builds.

@Explorer09
Copy link
Contributor

@natoscott Well, I mean while some assert lines are not useful by themselves, they might convey the intent of the programmers. This way I can see when the lack of null pointer check is intentional, and not a developer's oversight.

I know the proper way to mark the pointer as being non-null is to use __attribute__((nonnull)). The assert statement is an old way to mark the same intent. It's not just useless code noise and that's my point.

@natoscott
Copy link
Member Author

Sure, I understand your POV. A comment can often be a better way to go in that situation though.

Copy link
Member

@BenBE BenBE left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Some minor changes still pending.

linux/Platform.c Outdated Show resolved Hide resolved
unsupported/Platform.c Outdated Show resolved Hide resolved
Coverity scanning shows we end up passing an integer into the
Row_setPidColumnWidth routine which requires a pid_t - update
each platform to return the correct type (and never return -1
as a failure code, this was being ignored).
Coverity scanning shows a couple of locations where a NULL
pointer dereference could happen; updated code to ensure it
cannot.
Coverity scanning struggles to follow our 'super' handling
under certain circumstances.  Adjust the code to ensure we
keep good coverage even though this is a false positive.
Coverity scanning rightly warns that a usually-checked return
status was being ignored in two locations.  These two are in
cases where it's safe to ignore, so I've adjusted the code to
maintain coverage even though they are false positives here.
@natoscott natoscott merged commit eb86bdf into htop-dev:main Sep 3, 2023
12 checks passed
@natoscott natoscott deleted the coverity-fixes branch September 3, 2023 23:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants