16 ms·

Could the first example, with "getColor() == getColor()", in general, be a false positive if getColor() has side effects? bool getColor() { static a = 0;

Could the first example, with "getColor() == getColor()", in general, be a false positive if getColor() has side effects? bool getColor() { static a = 0; static b = 0; a++; b++; a %= 3; b %= 2; return (a && b); } or does something in the standard prevent this?

jfeser 12y ago
It could definitely be a false positive. That said, that would be pretty strange behavior for a function called getColor(). I'd expect that to return a property value, not modify some state.
deleted 12y ago
[deleted]
EpicEng 12y ago
Perhaps there is some semantic analysis involved (I don't know what tool they're using), but I have to imagine that getColor() is defined along the lines: T getColor() const; Otherwise that warning would often be at risk of emitting FP's, to the point at which it would become far less useful. Of course, even then... T getColor() { return rand(); // gotcha! }
anuragbiyani 12y ago
It's perfectly valid for the function getColor() to return different value for each invocation, e.g., think std::rand(). However, the function as you wrote, when used in the expression (getColor() == getColor()), results in undefined behavior. This is because equality operator (==) is not a sequence point in C++, and thus by calling getColor() twice, you are modifying variables a & b more than once between a pair of sequence points (see "Undefined behavior" section here: http://en.cppreference.com/w/cpp/language/eval_order http://en.cppreference.com/w/cpp/language/eval_order). In general, you cannot be sure of the order of evaluation for a statement of form say, f() == g(). The relative order in which f & g are called is unspecified. Also, the behavior can easily become undefined if you violate certain conditions in f & g (as in the case above).
- sjolsen 12y ago
  >the function as you wrote, when used in the expression (getColor() == getColor()), results in undefined behavior In C++14 (and I believe C++11), this is not correct. Specifically, §1.9/15 says, "Every evaluation in the calling function (including other function calls) that is not otherwise specifically sequenced before or after the execution of the body of the called function is indeterminately sequenced with respect to the execution of the called function;" this sentence is marked with a note that reads, "In other words, function executions do not interleave with each other." Item 4 under the "Sequence point rules" section on the page you linked says basically the same thing. I haven't looked at the C++98 standard, but I imagine it allows this, too. The two calls to "getColor" are indeterminately sequenced. As a result, the behaviour of evaluating "(getColor() == getColor())" is merely unspecified, not undefined. In fact, the behaviour is guaranteed to be equivalent to one of the possible orderings (§1.9/13: "Evaluations A and B are indeterminately sequenced when either A is sequenced before B or B is sequenced before A, but it is unspecified which").
  - anuragbiyani 12y ago
    Thanks for correcting me sjolsen. You are right, the behavior is unspecified only. I added a StackOverflow question (http://stackoverflow.com/questions/28816936/is-the-value-of-expression-f-g-when-f-g-modify-same-global-variable-und http://stackoverflow.com/questions/28816936/is-the-value-of-...) to increase the chances of someone being able to find (hopefully authoritative) information when searching for it.
- noselasd 12y ago
  The order of whether left hand or right hand is evaluated first is not specified, but calling a function will be sequenced, so there's no undefined behavior like you describe here.
AndreyKarpov 12y ago
http://cgit.freedesktop.org/libreoffice/core/commit/?id=a59848c9999f655342db4c67e3dc390cc083e511 http://cgit.freedesktop.org/libreoffice/core/commit/?id=a598...

jfeser 12y ago

It could definitely be a false positive. That said, that would be pretty strange behavior for a function called getColor(). I'd expect that to return a property value, not modify some state.

deleted 12y ago

[deleted]

EpicEng 12y ago

Perhaps there is some semantic analysis involved (I don't know what tool they're using), but I have to imagine that getColor() is defined along the lines: T getColor() const; Otherwise that warning would often be at risk of emitting FP's, to the point at which it would become far less useful. Of course, even then... T getColor() { return rand(); // gotcha! }

anuragbiyani 12y ago

It's perfectly valid for the function getColor() to return different value for each invocation, e.g., think std::rand(). However, the function as you wrote, when used in the expression (getColor() == getColor()), results in undefined behavior. This is because equality operator (==) is not a sequence point in C++, and thus by calling getColor() twice, you are modifying variables a & b more than once between a pair of sequence points (see "Undefined behavior" section here: http://en.cppreference.com/w/cpp/language/eval_order http://en.cppreference.com/w/cpp/language/eval_order). In general, you cannot be sure of the order of evaluation for a statement of form say, f() == g(). The relative order in which f & g are called is unspecified. Also, the behavior can easily become undefined if you violate certain conditions in f & g (as in the case above).

sjolsen 12y ago
>the function as you wrote, when used in the expression (getColor() == getColor()), results in undefined behavior In C++14 (and I believe C++11), this is not correct. Specifically, §1.9/15 says, "Every evaluation in the calling function (including other function calls) that is not otherwise specifically sequenced before or after the execution of the body of the called function is indeterminately sequenced with respect to the execution of the called function;" this sentence is marked with a note that reads, "In other words, function executions do not interleave with each other." Item 4 under the "Sequence point rules" section on the page you linked says basically the same thing. I haven't looked at the C++98 standard, but I imagine it allows this, too. The two calls to "getColor" are indeterminately sequenced. As a result, the behaviour of evaluating "(getColor() == getColor())" is merely unspecified, not undefined. In fact, the behaviour is guaranteed to be equivalent to one of the possible orderings (§1.9/13: "Evaluations A and B are indeterminately sequenced when either A is sequenced before B or B is sequenced before A, but it is unspecified which").
- anuragbiyani 12y ago
  Thanks for correcting me sjolsen. You are right, the behavior is unspecified only. I added a StackOverflow question (http://stackoverflow.com/questions/28816936/is-the-value-of-expression-f-g-when-f-g-modify-same-global-variable-und http://stackoverflow.com/questions/28816936/is-the-value-of-...) to increase the chances of someone being able to find (hopefully authoritative) information when searching for it.
noselasd 12y ago
The order of whether left hand or right hand is evaluated first is not specified, but calling a function will be sequenced, so there's no undefined behavior like you describe here.

AndreyKarpov 12y ago

http://cgit.freedesktop.org/libreoffice/core/commit/?id=a59848c9999f655342db4c67e3dc390cc083e511 http://cgit.freedesktop.org/libreoffice/core/commit/?id=a598...