Doubt with LOOP FOR (now in PIC C COMPILER)

Question

Doubt with LOOP FOR (now in PIC C COMPILER)

Navigation

#1 by (2 votes)

1

How about friends again, they already answered my question, but I work on a compiler of C, now I'm programming on pic C compiler, but it marks me that the second loop becomes infinite (it's always true, it executes normal, but at end begins to turn on the LEDs very randomly), just changing the variable ja SIGNED if it works (I'm doing the classic example of the "fantastic car") I do not understand why, someone will know what is due ??

#include<16f886.h>
#fuses xt,nowdt
#use delay(clock=4M)
#use standard_io(b)

int vec[8]={1,2,4,8,16,32,64,128};
int j=0,i=0;

void main(){
    {
    for(i=0;i<=7;i++)
    {
        output_b(vec[i]);
        delay_ms(200);
    }

    for(j=7;j>=0;j--)
    {
        output_b(vec[j]);
        delay_ms(200);

    }     
}

/// The error: Warning 203 "Vector.c" Line 19 (1,1); Condition always TRUE // Memory usage /// 0 errors, 1 warning

How they answered me in my last question if it works (j> = 0), but as long as j is SIGNED, it is worth mentioning that this concept of placing the signed I found in an example similar to mine, and I do not know why it works, can someone explain it to me? . Thanks in advance

loops c

asked by GabrielMT 05.01.2018 в 18:40

source

1 answer

Field input text stands out from the div Show character frequency in a string

score 2 · Accepted Answer

Although you do not indicate it , the warning occurs here:

for( j = 7; j >= 0; j-- )

and is a result of

int j = 0;

As you indicate, if you use signed , the warning (which does not error) disappears.

The explanation is very simple: your compiler uses unsigned int by default, and data of that type can never be negative ; It is impossible.

Without going into technical details, for unsigned data types (32-bit assumptions):

int x = 0;

--x;

printf( "%u\n", x );

4294967296

I think that with this image ( taken here ) is better understood:

You can think of them as if they were cyclical: when they reach the last possible value, they start again at the beginning. And the other way around: when you get to the first one, you start again with the last one.

With that in mind, you already know why negative values are not possible in unsigned types

That's why the compiler warns you: since there are no negative values, j >= 0 will always be fulfilled .

That's why it does not say anything to you if you use signed . By definition, those types without sign , so there may be negative values ... that are less than 0 .