Bug fact: Following code cannot get right results.
#include "SST89x5xxRD2.H" signed char x,y,z; void main() { x = -15; y = x / 4; z = x % 4; while(1); }
y = -4 and z = -3, while y should be -3...
Reason: Compiler automatically generates RRC for division by power of 2. For a SIGNED CHAR, this could produce unexpected rounding results.
Solution: If a signed char is divided by power of 2, DO NOT use RRC in this case.
OK, advice taken, but your report won't go much further when posted to a public discussion forum instead of the normal support channel.
According to my book (Harbison and Steele): "Prior to C99, C implementations could choose to truncate toward or away from zero if either of the operands were negative. The div and ldiv library functions were always well defined for negative operands."
Since C51 is not (fully?) C99 compliant, it looks like this is not a bug at all.
Yes, C implementations could choose to truncate toward or away from zero.
But as KeilC51 library functions choose truncating TOWARD ZERO, isn't it a bug as the compiler truncates AWAY FROM ZERO in this rare situation?
But as KeilC51 library functions choose truncating TOWARD ZERO
Where are you using the KeilC51 library functions?
It's not a bug, because the compiler is allowed to act as it chooses.
"as KeilC51 library functions choose truncating TOWARD ZERO, isn't it a bug as the compiler truncates AWAY FROM ZERO in this rare situation?"
No.
As already noted, the compiler can do whatever it likes for the division. The library function is well-defined - but there is no requirement for it to be the same!
Accroding to C89 standard, "If the quotient a/b is representable, the expression (a/b)*b + a%b shall equal a" . y*4+z = -19 != x, so it is a bug.
But did you enter the whole expression and check the result of that?
So, did you report your bug to Keil support? What did they come back with?
Maybe someone more proficient at interpreting the standards could comment?
so it is a bug.
Now I'm no expert at this. The way I read the standard is that what you think and state is a bug is certainly not, but the results produced by the division and modulus operator must satisfy the expression you gave.
If they don't then it suggests that the way they truncate the result is inconsistent. That might be a problem.
Henry, why do you have to be such a *** head?
You already answered that here: http://www.keil.com/forum/19291/
"Richard is just being Richard."