problems with negative integers? and some maths func perhaps

[simeon]

i did notice a problem perhaps a bug.?

if i write code

like... below....

//
#include <STDLIB.H>
#include <stdio.h>
#include <math.h>
..
...
int count;
count = 8;
while (count >= 0)
{
..
...
count--;
}
//


and the integer count eqiuals -1 after 9 events

this state is never reached and the subfunction while{} will never terminate
logicaly it should,
in terms of maths and other c and ansi c compilers.

can you let me know if this is a known limitation or a bug

however the way i used was this

//
#include <STDLIB.H>
#include <stdio.h>
#include <math.h>
..
...
int count;
count = 8;

while (count != -1)
{
..
...
count--;
}
//


and this works fine and the while does indeed terminate after 9 events
althought not as nice and neet and logical as the one above it, it did work ok...

perhaps picc has a flaw in its maths aspects of zero
or how it handles negative integers....? when challanged with a greater than paradymn.

all very strange and unexpected

i look foward to any reply TIA

[Ttelmah]

As written, it will not work on some other compilers either.....
The reason, it will work on some, is down to the decision about what is a 'default' integer. Some compilers default to using a signed integer, and on these it will work. The CCS default integer, is unsigned, and on any compiler where this is true, it should not work.
This is why you should use explicit types. Personally, I never use 'int', unless the size/sign will not matter. Use int8, int16, and int32, so you know what size the values are (since these are also supported in most modern compilers), and add 'unsigned', or 'signed' to each (though the former is unecessary in CCS, since it is the default, declaring it explicitly, costs nothing, and _ensures_ you get the type you want if you move the code to another compiler.

Best Wishes

[newguy]

Actually, I've noticed that it doesn't matter if the integer is declared as signed or unsigned, the compiler can't properly handle ">" or "<" in tests if you are expecting negative numbers.

I haven't tested this with the latest version of the compiler, but I know for sure that 3.178 had this flaw.

[PCM programmer]

[dyeatman]

Hmmm... thats strange, I have never seen this problem... Must have been lucky :-) Gonna go back myself and see if I can reproduce it.

Anyone else seen it?

[newguy]

I tried to replicate the problem, and I was sort of able to do it. I know for a fact that I had a devil of a time with this about a year ago and that in order to properly test if a signed integer was < 0, I'd have to test to see if the msb was set. Simply doing a "if (xxx < 0)" never worked. It's like the compiler was doing the relational stuff using only unsigned integer math.

Now that I think of it, it may have been a casting problem. I saw this happen when I was using the built-in A/D. I was reading an analog signal, and the signal can lie within a certain range. I needed to know if it was out of range. I was testing to see if the result of the reading - lower threshold was negative (below range), and it never was, even if the reading was below the lower threshold. Stupid me, I bet that I didn't use signed integers to do it, or mixed signed & unsigned integers. In fact, that's most likely what I did. I simply used unsigned integers to store the A/D reading, and didn't do the casting properly.

Anyway, here's some code that I whipped up to try and replicate the problem. I was able to duplicate what I was likely seeing in one of the cases:

[simeon]

one of the replys above about adc enabled etc
yes i use all analog in that routine


however it didnt answer my question

what ever cast an int is makes no differance here
as i type define anyway in headers

and the compiler will choose most often

i recon its a problem with the scope of the int and maths.inc

as i was using several functions at the same time
however it still should work


no matter i solved the problem anyway and the code works ok

thanks everyone for an interesting read and for taking the time you did
to solve this issue

[Ttelmah]

As I tried to say before, it is simply the way that unsigned integers work in this implementation. When you decrement an unsigned int8, from 0, it goes to 255. Hence it will never test as '<=0'. Technically, you can generate exactly the same behaviour in most C's with an unsigned type, by turning off maths error checking, and many other embedded versions do exactly the same. Historically, there was a problem with comparison (as opposed to equality) testing, in some older versions of the CCS C, but it works fine now. The reason that the comparison with '-1' works, is that '-1', is stored as 0B11111111. which is the same binary value as 255 in an unsigned. This C does not implement maths error checking. If you want this, you would have to add the extra code yourself, and the size involved, makes it undesirable in most situations.

Best Wishes