RFC: silence compiler warnings

[eworm-de]

For more recent GCC versions casting to (void) is not sufficient to silence the warning about ignoring return values.

In the past we assigned the return value to a variable and casted that to (void). Not really an elegant method.

How about mis-using a condition with empty body? This is just a RFC, if you are happy I will catch some more cases and update the patch.

[Explorer09]

I'll need to understand what is going on. It seems that the compiler warnings about unchecked seteuid return value make sense! From what I discovered in the htop source code, seteuid is called in multiple routines, each for different purposes. And think about it, for each routine, what if the first seteuid call fails right before, for example, creating and writing an htoprc? That file would be unreadable for the user who would run htop next time. As another example, in Process_sendSignal what if it fails to drop privileges when trying to kill a process? (It might kill something that it's not supposed to have privilege to kill.)

I think the Linux seteuid man page has described this enough:

Note: there are cases where seteuid() can fail even when the caller
is UID 0; it is a grave security error to omit checking for a failure
return from seteuid().

[eworm-de]

You are right, we should rework the code to check for errors in seteuid.

But my RFC is about something different. Suppose we have a function int foo() we want to call and ignore its return value. Obviously this gives an error:

foo();

This worked for older gcc versions, but results in the same error with more recent gcc:

(void) foo();

In the past we had something like this:

int rc;
rc = foo();
(void) rc;

It works, but requires an extra variable. This can be worked around by a condition with empty body:

if (foo()) {};

Or is there any better solution?

[Explorer09]

@eworm-de I don't think any of the solution you proposed here will work in the long term. The compiler is free to re-implement the warning so that it's emitted after code optimization phase, making any of your trick useless. The only thing that will work forever is probably -Wno-unused-result, which is usually a bad idea.

I'll personally suggest that we either fix it the proper way, or just leave the warning as is and let other people think of a proper solution in the future.