On Tue, 24 Jan 2012, PICdude wrote:

> I can see now what it's thinking here, that 125 will fit in a signed
> byte, so it uses that.  And if I change the statement to "if (S2 >=3D
> 130)", then it knows that a signed byte won't work, so it interprets
> it as unsigned, and works correctly.  But this is so not intuitive.

It may not be intuitive, but it's documented in the C18 user's guide.
By default, C18 behaves in a non-standard way with regard to integer
promotions.  You can request standard C behavior with a command-line
switch.

> When the compiler does the math on the defines and comes up with 130,
> it should know then that a signed byte won't work.

That's not how C works.  Even if you enable standard behavior in C18,
you'll still run into situations like this.  When you add two ints,
the addition is performed with int precision.  If the addition doesn't
fit in an int, you have an overflow.  It doesn't matter that you're
comparing the result to a "long" or assigning it to a "long".  If you
need an operation to be performed with higher precision, you must
explicitly tell the compiler that.

Incidentally, the fact that you're using #defines here isn't relevant
to the problem.  The preprocessor just does a simple text substitution
with these.

--
John W. Temples, III
--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.