Re: Fun with C

["jimmaureenrogers@worldnet.att.net" <jimmaureenrogers@worldnet.att.net>]

On Apr 16, 3:12 pm, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
> "Nasser M. Abbasi" <n...@12000.org> writes:
>
>
>
>
>
> > On 4/16/2011 10:02 AM, George P. wrote:
> >> Spend few days chasing bug in embedded C project which can drilled
> >> down to this. Consider the following program, and all reasonable men
> >> will expect the result to be negative.  Not in C, and it is not a
> >> compiler bug :-(
>
> >> And offcorse none of the three comilers I cheched did not bother to
> >> issue a warning at least..
>
> >> #include<stdio.h>
>
> >> int main()
> >> {
> >>       unsigned n = 128;
> >>       int i = -2048;
> >>       int r;
>
> >>       r = i / n;
>
> >>       printf("R = %d\n", r);
>
> >>       return 0;
> >> }
>
> > $ gcc -Wall  t.c
> > $ ./a.out
> > R = 33554416
>
> So R = 2**25 - 16, the correct answer is -16, so the actual result is
> the correct one except for bit 24, which is 1 when it should be zero.
>
> Out of curiosity, is this actual result a predictable consequence of the
> language definition, or is it undefined behavior?
>
> --
> Ludovic Brenta.- Hide quoted text -
>
> - Show quoted text -

This is actually predictable. The C compiler implicitly converted the
negative
value to an unsigned representation of the same bit pattern. The
division was
performed on that converted value.

Note that this wonderful behavior is also expected using C++, because
of its
compatibility with C.

Jim Rogers