Electron wrote: > Hello! > > a is a signed int and contains -100 > b is an unsigned int and contains 500 > > a?b returns FALSE!! > > Why on earth? :P > > I can cast b to signed int and get the correct results, > but leaving as is instead the result surprises me a lot, > as I have no idea why -100?500 should be false, it's like > if the compiler casts a to an unsigned type automatically > (and this was clearly not requested by the programmer). > > If we keep them as they are, i.e. the first signed and the > second unsigned, then why should a?b return false??? > > This is very confusing really. > > Now I have to correct all of my code, looking for > comparisons between signed and unsigned ints, and cast > both variables to the type I mean. :-/ > > Is there any other situation I have to be careful about > when mixing signed and unsigned types? > > Please do not reply the obvious "generically the use of > unsigned types is not adviceable, why don't you stick > with only signed types? you will be much safer". THANKS. > > Cheers, > Mario The short answer (Having worked on the development of about 30 C compiler projects and a handful of compilers for other languages) is C as a language is the accumulation of 40 years of tradition, conventional wisdom, and compiler dependent implementations. The good thing is that is a powerful low level language that has survived that long. In the embedded systems world the code is rarely ported but the common syntax and expectations make it a powerful tool for application development. C is a living language has been adapted to many very diverse architectures, multiple address spaces, homogenous and heterogeneous multiple processor systems and it still has survived. The compare issue that you point out has been around for a long time. We released a C compiler in the early 90's that dealt with compares in a mathematically sound way between signed and unsigned numbers and the customer response was clear. Conventional implementations were more important that mathematically sound. They had found ways around the limitations and the mathematically sound solutions broke their solutions. It was an interesting lesson in the C language, with all its quirks it is a dialect understood by application developers. Walter.. --=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 .