Configuration: returnValue safeValues

[Daniel Marjamäki]

I added a new attribute for <returnvalue> where you can specify the return values of a function.</returnvalue>

It should not be used if the return value depends on the input parameters.

I imagine that it can be used if the function reads some external data (clock, network, file, ...) and produce output.

You can be somewhat "aggressive" about this configuration... Right now there is only a command line flag to switch this on/off. But that is only temporary... I ultimately want that this will be controlled by the user in the GUI project. The GUI will list all imported functions with such configuration and the user will have a checkbox to select which functions he wants to use this analysis for.

[Daniel Marjamäki]

Maybe the name should be changed. Feel free to suggest something better.

[versat]

I am not sure if i get it.
While adding configurations for the QDate functions i thought it could be useful to add the range of return values for some functions.
For example for int QDate::month() const;. It returns the number of the month (1-12) or 0 if the date is not valid.
So is it correct to change the configuration as following:
Old:

  <!-- int QDate::month() const -->
  <function name="QDate::month">
    <noreturn>false</noreturn>
    <returnValue type="int"/>
    <use-retval/>
    <const/>
  </function>

New:

  <!-- int QDate::month() const -->
  <function name="QDate::month">
    <noreturn>false</noreturn>
    <returnValue type="int" safeValues="0:12"/>
    <use-retval/>
    <const/>
  </function>

The word safe in safeValues irritates me a bit. What does safe mean here?
When is a returned value not safe? Can a function return unsafe values (for example negative ones) and safe values (positive ones) and should only the safe values be configured via safeValues?

[Daniel Marjamäki]

The word safe is misleading.

This option can be used when it is potentially not known (even by the developer) what the function will return. The typical use case I envision is a function that reads arbitrary input from a file or network and returns it. Imagine fgetc if it reads data from a "untrusted" file.

The QDate::month() return value is not arbitrary (for instance, if you call it twice then the return value will always be the same) so therefore I do not think it should be configured.

I can see that the name safe is not good.. do you have some better ideas?

unknown-result?

Sometimes when a function like fgetc is used, you know that the file is OK somehow. As a developer you might know that the file only contains alphanumeric characters for instance. Therefore Cppcheck will not blindly use the values in the configuration file. The user must still explicitly tell Cppcheck to use the configuration values.

[versat]

I roughly got the idea, but i still do not fully understand it.

The QDate::month() return value is not arbitrary (for instance, if you call it twice then the return value will always be the same) so therefore I do not think it should be configured.

Hmm, if rand() is called with the same seed the values are not really arbitrary/unpredictable also. But two calls will normally not return the same and the value is at least not easily predictable , i guess that is the point.
QDate::currentDate().month() could return two different values if called twice. But it is not really unpredictable.

If i see more examples i maybe get a better idea.

As far as i understand it currently unknown maybe really is a better word than safe.
I have no better idea for a name yet.

[Daniel Marjamäki]

Hmm, if rand() is called with the same seed the values are not really arbitrary/unpredictable also.

Yes. Cppcheck can't even assume this for rand().