On Sat, 3 May 2014, Byron Jeff wrote:

> On Fri, May 02, 2014 at 11:06:10PM -0600, PICLIST wrote:
>> Further to my previous comment:
>>
>> It all makes sense when you think about it carefully.

No it doesn't. We've just learned to accept that that is the way it is :-)

Newbies that fall into the trap are the ones that are doing things=20
correctly. They learned how to do simple arithmetic with numbers before=20
they learned to program and now because C has had a standard retrofitted=20
we try to justify why they (the newbies) are wrong.

>
> It does. And the real takeaway is that when working with incompatible typ=
es
> you have to give the compiler hints as to the correct direction to go.

This is what really really irritates me - they are not incompatible!!!

If they were then the compiler should refuse to add them together. It=20
should force you to decide exactly how they should be treated.

Look this is how you compare a signed 16 bit integer to an unsigned 16 bit=
=20
integer:

int compare(int arg1, unsigned int arg2)
{
     if ((arg2 & 0x80000) !=3D 0)
     {   // arg2 > arg1
         return 1;
     }

     if ((arg1 & 0x80000) !=3D 0)
     {   // arg1 < arg2
         return -1;
     }

     // arg1 and arg2 are both in the same 15 bit range
     // return 0 if arg1 =3D=3D arg2
     // return < 0 if arg1 < arg2
     // return > 0 if arg1 > arg2
     return arg2 - arg1;
}

The only "real" extra code is in the checking of the top bits of the=20
signed and unsigned integers. Generating this trivial overhead "inline" in=
=20
a compiler is, well, trivial! It doesn't stop you using the same type in a=
=20
comparison but it does stop stupid bugs getting through. This is one=20
reason why I decided to write a non C compiler, to have the freedom to fix=
=20
some of the stupid things that C does.

Regards
Sergio Masci
--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.