noreturn configuration

[Daniel Marjamäki]

It is suggested to add <noreturn>maybe</noreturn> in this ticket:
https://trac.cppcheck.net/ticket/9295

I believe we could discuss it here in the forum. Imho, it will be more visible when people say something interesting.

I am not against better control in the configuration. However I do not see how it helps Cppcheck to write maybe. That just means it has to fallback to the safe choise I guess.

[Daniel Marjamäki]

If <noreturn>maybe</noreturn> is configured then in the software verification we can assume that the execution continues..
so there is a point.

[versat]

Another point for adding a third option, like <noreturn>maybe</noreturn>, in my opinion is that it is explicitly specified for the function then.
At the moment we simply skip any noreturn configuration if it is unknown or it depends on the implementation or so.
When reviewing library configuration files it must be verified every time that a noreturn configuration has not been forgotten by fault but was intentionally not added. This needs at least time for research or even asking somewhere in Trac, the forum or so. That is a bit annoying and could be easily fixed by this third option.
The noreturn configuration then could be made obligatory, so we can be sure that our library configurations is complete with regards to noreturn.

Additionally --check-library will not issue a message, for example for every assert(), that a noreturn configuration is missing. That could reduce the messages to look through.

My Trac ticket about assert() missing a noreturnconfiguration:
https://trac.cppcheck.net/ticket/8329

[versat]

Regarding your comment in Trac:
IMHO if it is not clear whether the function returns or not and as a result it is not clear if the warning should be issued or not it would be acceptable to issue an inconclusive warning.
That way false positives (and maybe false negatives too) could be avoided a bit better for such constructs.

[Paul Fultz]

The maybe attribute doesn't seem to make sense to me. It seems like what we want is to specify what inputs the function is noreturn:

<noreturn>
    <when>
        <arg nr=0>SIGFPE</arg>
    </when>
</noreturn>

I wrapped in the <when> tag so it could specify mutiple combinations of different args.

The only issue is that these values could rely on valueflow. It should work better with Impossible values since it can delete the possible values at a later pass. However, if the value is never known then we can't really decide, but I am not sure if that would lead to an FP, though.

[Daniel Marjamäki]

some such xml syntax would make it possible to have better analysis.

However, if the value is never known then we can't really decide, but I am not sure if that would lead to an FP, though.

we can make a safe choice in the normal analysis then. in "verification" we can allow FPs.

My Trac ticket about assert() missing a noreturnconfiguration: https://trac.cppcheck.net/ticket/8329

i don't know why we warn there. How does it help with noreturn configuration in that piece of code.

[Paul Fultz]

we can make a safe choice in the normal analysis then. in "verification" we can allow FPs.

If by safe choice you mean we assume its noreturn, its seems overkill. We dont assume noreturn for b ? 0 : throw "". Rather we should progate that the value of b after such statement is false. We can do the same for noreturn functions that require certain values.

i don't know why we warn there. How does it help with noreturn configuration in that piece of code.

I dont know why we warn either, but it seems correct to have assert be a conditional noreturn as well. We can add a valueFlowAfterNoReturn pass to propagate the values for these functions(similiar to valueFlowAfterCondition).