01 Mar, 2011, Vigud wrote in the 21st comment:
Votes: 0
Quote
Yes – you found a potential runtime problem.
I didn't, the compiler did and warned about it.
01 Mar, 2011, Rarva.Riendf wrote in the 22nd comment:
Votes: 0
There is not even a runtime problem, as it will never crash in this example….there is only an unexpected result….
01 Mar, 2011, Tyche wrote in the 23rd comment:
Votes: 0
Rarva.Riendf said:
There is not even a runtime problem, as it will never crash in this example….there is only an unexpected result….

*boggles*
01 Mar, 2011, Rarva.Riendf wrote in the 24th comment:
Votes: 0
What I mean is (I jut looked at the code though..did not actually run it, I may be mistaken): the code does not crash, does not leak memory, does not write in the memory in the wrong place etc.
ie: the code should run fine, does not pose any threat. It does not what it looks like it should, but in the end…it works perfectly fine.
01 Mar, 2011, David Haley wrote in the 25th comment:
Votes: 0
By the way, the issue is moot in C++ where you have proper bools, and the compiler knows how to convert types to bool.

Vigud, why do you believe that people are saying that there is no potential problem here? You seem to have gotten upset about somebody saying that there was no obvious actual problem, and then you gave an example potential problem. Yes, nobody ever denied that. Why did you ignore the question asking you to say where it was denied that there could be a problem here?

This seems to be some kind of issue where you have to prove that you were right, and others wrong, even though the other people weren't saying what you say they're saying…

In any case, all potential (and actual :wink:) usefulness here seems to have been exhausted.
01 Mar, 2011, Tyche wrote in the 26th comment:
Votes: 0
Rarva.Riendf said:
Tyche said:
Rarva.Riendf said:
There is not even a runtime problem, as it will never crash in this example….there is only an unexpected result….

*boggles*
What I mean is (I jut looked at the code though..did not actually run it, I may be mistaken): the code does not crash, does not leak memory, does not write in the memory in the wrong place etc.
ie: the code should run fine, does not pose any threat. It does not what it looks like it should, but in the end…it works perfectly fine.

Are you suggesting that overflow is not a runtime problem? What is it then?
01 Mar, 2011, Vigud wrote in the 27th comment:
Votes: 0
David, we're reading two completely different topics, it seems. I don't know what you're talking about, really (I'm far from upset, for example). Anyway, do we need to discuss this? I think not.

Oh, and by the way – if the bool was typedef'd as int, there would be absolutely no problem with bools.
01 Mar, 2011, Rarva.Riendf wrote in the 28th comment:
Votes: 0
I would say that most of the time, they are only algorithmic problem.
You could put a long into an int and never have any problems if you never actually use the long capacity once your math is done (you could need the long for an intermediate result, but know that the final result will end up in the int range as an example. And it is the reason why this is only a warning: it is not an error, just that may be a problem but that also could be perfectly wanted. That is also why you have a file where you can supress the warning to avoid seeing them, all depends on what you are doing.
01 Mar, 2011, Runter wrote in the 29th comment:
Votes: 0
The very reason it's a warning instead of an error is because it may be kosher.
02 Mar, 2011, Vigud wrote in the 30th comment:
Votes: 0
Care to provide an example?
02 Mar, 2011, David Haley wrote in the 31st comment:
Votes: 0
An example where usage is kosher? Simple: just do your int math within the char numeric range… if you find yourself in such a circumstance, then the warning is just noise. (Of course, avoiding the warning means you do not have to depend on remembering to stay in the correct numeric range…)
02 Mar, 2011, Vigud wrote in the 32nd comment:
Votes: 0
I meant code that would produce the same warning and make sense at the same time.
02 Mar, 2011, David Haley wrote in the 33rd comment:
Votes: 0
I just told you. Take your own example and change the numbers such that the math stays within the appropriate numeric range, but leave the types as-is. If necessary, depending on how smart the compiler is, muck around with control flow from one function to the other such that the compiler doesn't know to do constant folding optimization.
02 Mar, 2011, Vigud wrote in the 34th comment:
Votes: 0
After changing the numbers to lower values, I'm unable to get the warning. Please help.
02 Mar, 2011, David Haley wrote in the 35th comment:
Votes: 0
Sorry, but I'm not going to entertain your socratic wasting of time. I told you what else might be necessary depending on the compiler. If the compiler can guarantee that the math is in the right range, it will not complain. If it cannot make that guarantee, it will complain. I'll leave that obvious exercise to the reader.
02 Mar, 2011, Vigud wrote in the 36th comment:
Votes: 0
Ok.
02 Mar, 2011, Tyche wrote in the 37th comment:
Votes: 0
Rarva.Riendf said:
I would say that most of the time, they are only algorithmic problem.
You could put a long into an int and never have any problems if you never actually use the long capacity once your math is done (you could need the long for an intermediate result, but know that the final result will end up in the int range as an example. And it is the reason why this is only a warning: it is not an error, just that may be a problem but that also could be perfectly wanted. That is also why you have a file where you can supress the warning to avoid seeing them, all depends on what you are doing.


This particular message indicates that the compiler has determined that an overflow WILL occur, not MAY occur. That's because it involves a constant. The warning has to be explicitly suppressed. The subtle difference is it in almost every case it is an error, unless one is writing obfuscated C. The only reason that the compiler will not flag it as an error, is because the C standard allows it.
02 Mar, 2011, Tyche wrote in the 38th comment:
Votes: 0
Vigud said:
Care to provide an example?

#include <stdio.h>
int main(int argc, char **argv) {
char a = 4168;
char b = 4197;
fprintf(stderr, "%c%cllo World!\n", a, b);
return 0;
}


Sorry, not one that I would defend. :-)
02 Mar, 2011, David Haley wrote in the 39th comment:
Votes: 0
Clearly, you'll get warned about constants if you're dealing with constants. If you're not dealing with constants, you will get other conversion size warnings. Sorry if that wasn't clear earlier (the dangers of obviousness eh?).
20.0/39