Bug or Feature?

[boriel]

Hmmm. I'm afraid not. This is a feature, the same way as in C, due to truncation. c1 is always uByte and you can't gues in compile time it's value, so there might be a chance that, effectively, c1 * 9 > 255. C does the same. What you get is (PEEK(x) * 9 bAND 0xFFh)

We already discussed this. It's not the same way as C. In fact, C does the calculation correctly. In both z88dk and gcc, this program:

Code:

#include <stdio.h>

int main (void) {
  unsigned char c = 255;        // This will have to do for PEEK 3 ;-)
  printf ("%d * 3 = %d\n", c, c * 9);
  return 0;
}

Yes, that's right. My mistake: it was already discussed in other thread.
The problem of c * 9 is that 9 is taken as <int> in C, that depends on the compiler. For z88dk, <int> is 16 bits, for example.
As discussed previously, I could implement that behaviour, but that will increase memory usage and will have a performance impact. :?

Also, using
printf ("%d * 3 = %d\n", c, c * 9);
where c is a byte/char, is not correct (might work, but it's undefined behavior, isn it?).
c * 9 promotes to <int>, and that's ok, but c is a char, so the printf instruction should read:
printf ("%d * 3 = %d\n", (int)c, c * 9);