This is one of the reasons I had when I left use of CCS eons ago. Andy Bob Ammerman on 10/17/2000 09:13:16 AM Please respond to pic microcontroller discussion list To: PICLIST@MITVMA.MIT.EDU cc: (bcc: Andrew Kunz/TDI_NOTES) Subject: Re: Signed Int vs Int ----- Original Message ----- From: M. Adam Davis To: Sent: Tuesday, October 17, 2000 8:40 AM Subject: Re: Signed Int vs Int > Bob Ammerman wrote: > > This is _not_ true. In ANSI "C", a comparison of an 'int' and an 'unsigned > > int' is performed as a 'unsigned int' comparison, _not_ a 'signed long' > > comparison. > > If so, what is the conversion? You can't represent 250 (or even 128) in a > signed int. I suppose that there is no conversion, it just refers to the uint > as an int, in which case it becomes -6. Yes, there is no conversion. The bits are just reinterpreted as signed. ANSI says an 'int' is at least 16 bits! If your compiler calls an 8-bit variable an 'int' that is YANAC (yet another non-ansi construct). Actually, ANSI says that _all_ arithmetic is done at at _least_ int (16-bit) precision. Not very friendly in the microcontroller world. Compilers can do 'char' (8-bit) arithmetic and still call themselves ANSI when the final result of the 8-bit operation is certain to be the same as that in a 16-bit operation. For example: unsigned char a; unsigned char b; unsigned char c; c = a + b; The standard says this should be treated as: c = (unsigned char) ( (int) a + (int) b); ie: 'a' and 'b' are promoted to 16-bit signed values and added together. The result is then truncated to 8 bits and stashed in 'c'. In this case the compiler _can_ use 8-bit arithmetic because it'll _always_ come up with the same value for 'c' that it would have obtained with 16-bit arithmetic followed by truncation. > Well, this is a reason for good coding practices. Always cast variables when > they are dissimilar... Portability is better then, as well. This is a pretty good idea. Be careful tho' that you don't force your compiler into 16-bit math by casting. > -Adam > > -- Bob Ammerman RAm Systems (contract development of high performance, high function, low-level software) -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! use mailto:listserv@mitvma.mit.edu?body=SET%20PICList%20DIGEST -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! use mailto:listserv@mitvma.mit.edu?body=SET%20PICList%20DIGEST