library configuration: output parameter, must use

[Daniel Marjamäki]

Now that you can specify the output parameters of a function .. the next step could be to specify if a output value must be used.

For instance, the first argument for strcpy must be used after the function call otherwise the function call is redundant.

Do you have some suggestions for how this can be configured?

[Markus Elfring]

• Should data from output parameters be generally used after it was determined that a function call succeeded?
• Would you care for the use case that such a function argument can be treated as a return value if the function return type would be “void”?

[Daniel Marjamäki]

Should data from output parameters be generally used after it was determined that a function call succeeded?

I do not think such configuration could be used if there is any conditionals.

Would you care for the use case that such a function argument can be treated as a return value if the function return type would be “void”?

I guess that is a typical use case.

[Markus Elfring]

I do not think such configuration could be used if there is any conditionals.

I imagine that this design variant can be an usual one when a general agreement can be achieved at all for the proper usage of function return values.

I guess that is a typical use case.

I would find it surprising if programmers would choose to use an output parameter instead of working with a function return value directly.

[versat]

To use something similar as for the return value i suggest <use-outval/>.
I think Cppcheck should only complain if the value is not used in code paths that handle a successful function execution. So we need an element to configure when a function call can be seen as a success.
For example:
<success>always</success> if a function never fails.
<success>retval==0</success> if a function returns 0 on success.
Microsoft SAL works a bit similar. It is also possible and necessary / useful to specify how a successful function execution can be detected.

As a first step we could only implement the <use-outval/> configuration and allow to only specify it for functions that always succeed.

[Markus Elfring]

To use something similar as for the return value

I propose to take additional case distinctions better into account.

i suggest <use-outval/>.

I find an empty XML element insufficient for the safe description of constraints in the discussed use cases.

I think Cppcheck should only complain if the value is not used in code paths that handle a successful function execution.

This desire is reasonable. - But it is too limiting for programming interface designs which can be technically possible.

So we need an element to configure when a function call can be seen as a success.

I imagine that there are data modelling challenges to consider because there are programming languages where exceptions will be thrown (or raised) because of error conditions.

[versat]

I propose to take additional case distinctions better into account.

Which ones exactly?

I find an empty XML element insufficient for the safe description of constraints in the discussed use cases.

Why exactly?

This desire is reasonable. - But it is too limiting for programming interface designs which can be technically possible.

Many functions "return" undefined values in output arguments if they are not successful. Why exactly should this not be differentiated? There would be many false positives otherwise.

I imagine that there are data modelling challenges to consider because there are programming languages where exceptions will be thrown (or raised) because of error conditions.

For example C++, yes that is a good point and should also be configurable. For functions that signal failure via exceptions something like <success>no_exception_thrown</success> or so could be specified. But that whole "success" thing is just an idea yet, not a finished concept.

[Markus Elfring]

Which ones exactly?

I am proposing to reconsider the software situation (and data models) also for the handling of function return types in more detail for a while.

Many functions "return" undefined values in output arguments if they are not successful.

I agree.

• How would you like to represent corresponding facts then?
• Will execution failure information be occasionally stored also in these output parameters?

Why exactly should this not be differentiated?

I suggest to increase case distinctions here.

For example C++, yes that is a good point and should also be configurable.

Would you like to take care of a key word like “noexcept”?