Re: [avr-gcc-list] Got strange compilation problem

[David Bourgeois]

Indeed that's the difference which explains why one solution generates  
much shorter code than the second. I'm too ashamed too explain the stupid  
reason why my code broke :-/ so I guess both solutions were working right.
So this was the opportunity to learn more about typecasts and the  
important thing here is that ((uint8 + uint8) % uint8) takes more space  
than ((uint8_t)(uint8_var1 + uint8_var2) % uint8_var3) for the exact  
reason you explained below.

Thanks to all,
david

On Thu, 16 Feb 2006 10:48:57 +0100, Joerg Wunsch <address@hidden> wrote:

> "David Bourgeois" <address@hidden> wrote:
>
> (A full compilable example would be nice.  It's always hard to guess
> the various missing pieces when trying to reproduce other people's
> problems.)
>
> > Replacing the 2 lines
> >      length = (p->inIdx) - (p->outIdx);
> >      length %= FIFO_SIZE;
> > by
> >      length = (((p->inIdx) - (p->outIdx)) % FIFO_SIZE);
> >
> > completely broke my code.
>
> The difference between both is that in the first case, the entire
> computation is trimmed down to a uint8_t result immediately, while in
> the second case, the intermediate results are computed as `int'.  Note
> the change in signedness: the implicit promotion of a uint8_t argument
> to an int expression makes the expression signed.  I guess that's what
> broke your code.
>
> The IMHO equivalent single-line expression would be
>
> length = (uint8_t)(unsigned)((p->inIdx) - (p->outIdx)) / FIFO_SIZE;
>
> even though GCC still generates somewhat different code for that.