Em 25/01/2012 06:18, John Temples escreveu:
> 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.


I may be wrong, but the C standard states that operands must be promoted
"at least" to int, or to the type of the operand with highest precision.


Also, the OP could use:

#define S2_MIN  90u
#define S2_MAX  125u
#define S2_STEP  5u



>
> 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
.