[Coverity CID :210610] Argument cannot be negative in tests/posix/eventfd/src/main.c

[zephyrbot]

Static code scan issues found in file:

https://github.com/zephyrproject-rtos/zephyr/tree/4653b4e63f886a50ac7b72f8d47ba2950ab2dd0d/tests/posix/eventfd/src/main.c#L39

Category: Error handling issues
Function: test_eventfd
Component: Tests
CID: 210610

Details:

33     static void test_eventfd(void)
34     {
35         int fd = eventfd(0, 0);
36    
37         zassert_true(fd >= 0, "fd == %d", fd);
38    
>>>     CID 210610:  Error handling issues  (NEGATIVE_RETURNS)
>>>     "fd" is passed to a parameter that cannot be negative.
39         close(fd);
40     }
41    
42     static void test_eventfd_read_nonblock(void)
43     {
44         eventfd_t val;

Please fix or provide comments in coverity using the link:

https://scan9.coverity.com/reports.htm#v32951/p12996.

Note: This issue was created automatically. Priority was set based on classification
of the file affected and the impact field in coverity. Assignees were set using the CODEOWNERS file.

[pfalcon]

@tsvehagen: Can you please look into this?

[tsvehagen]

@tsvehagen: Can you please look into this?

Yes I will check it out

[tsvehagen]

@pfalcon I'm not really sure how to handle this actually. I guess it has to do with fd being used as fdtable[fd] in close(). That would mean that this warning should be seen everywhere that close is used so it seems a bit weird 🤔

[pfalcon]

@tsvehagen:

I'm not really sure how to handle this actually.

The usual note is that Coverity report can be a false positive. And reports against tests are of course less serious than the main codebase (the latter really need to be properly investigated). That said, Coverity is usually smart and can pinpoint some non-obvious things. And one can imagine that as any other software, it's also buggy sometimes, and catching that is only more fun.

And here it really looks like Coverity outsmarted itself.

I assume you have access to Coverity web UI for this issue (login via Github account works). So, it claims:

negative_return_fn: Function eventfd(0U, 0) returns a negative number. [show details]

But what makes it think so? Let's click "show detail" and find out:

1. Condition flags & -16387 /* ~(2 | 0x4000) */, taking true branch.
202        if (flags & ~EFD_FLAGS_SET) {
203                errno = EINVAL;
   2. return_negative_constant: Explicitly returning negative value -1.
204                return -1;
205        }

So, it kinda thinks that flags & -16387 is true, regardless of the flags value. Which is of course hilarious. I don't know if it got completely mad, or just got confused by bitwise arithmetic on signed values (it shouldn't).

All in all, that's really an interesting case, I didn't yet see such a situation with Coverity, gives insight of what you can expect from it. Resolution is clearly "false positive" (i.e. "ignore" in Coverity UI). (And yeah, leaving to you to double-check, in case I didn't wake up enough and missed something :-D).

[tsvehagen]

I assume you have access to Coverity web UI for this issue (login via Github account works).

@pfalcon I don't have access, it says 'Access request pending'. I guess it must be accepted by someone in the Zephyr project.

[pfalcon]

@tsvehagen: Ok, I marked it as false positive myself. Hopefully your request will be approved soon. Otherwise it's just about sharing load of "adding and maintaining code in Zephyr", I redirect reports for the code you wrote, but feel free to ask for any help. And just to be explicit, reports re: tests aren't high priority, the idea is to have them handled before the next release ;-).