Type conversions в CodeVision, unsigned char->float Опции

[Gogan]

Есть вот такой проргамный код для АВР(например):

unsigned char a = 100;
float b = 20;

далее в программе

if( b < -a ){...}

так вот оказывается, в таком случаее условие выполняется.
Если кастовать вот так :

if( b < - (int) a ) {...}

тогда все ок. Объясните почему? Я не могу понять, что с чем сравнивается, если не кастовать, и почему так происходит?

[ReAl]

unsigned char a = 100;
float b = 20;

далее в программе

if( b < -a ){...}

так вот оказывается, в таком случаее условие выполняется.
Если кастовать вот так :

if( b < - (int) a ) {...}

тогда все ок. Объясните почему? Я не могу понять, что с чем сравнивается, если не кастовать, и почему так происходит?

На мой взгляд, компилятор не прав. Согласно стандарту С он должен оба эти if-а обрабаотывать одинаково и так, как второй. Есть такая штука, как integer promotion rules (integer promotions), согласно им любой целочисленный тип, который меньше int-а, должен приводиться к int перед вычислением выражений. Даже для

Код

char a,b,c;
a = b + c;

- привести к int, сложить, результат усечь и присвоить a.
Это требования к "абстрактной машине", дальше можно дать свободу и не делать приведение к int, но только в случае, если от такого неделания результат не изменится.
В данном случае -a это уже подвыражение с унарным минусом, перед его вычислением компилятору надо было привести a к int (что во втором примере сделано вручную), потом применить минус, потом, согласно правилам автоматических преобразований типов, результат привести к float и сравнить.
Так что тут компилятор не имел права делать -a в пределах байта.

eeprom unsigned char edata[20][8]={{90,0,...},{}...};
unsigned int a;

далее в тексте
a=edata[0][0]+edata[0][1]<<8;

т.е. интегер хранится в двух первых байтах, сначала младший потом старший. Компилер выдал, что edata[0][1]<<8 получится в любом случае 0. Я переписал
a=(int)edata[0][0]+edata[0][1]<<8;

опять неправильно. Компилер не ругался, но результат был 90х256=23040. Правильным вариантом оказалось:
a=edata[0][0]+(int)edata[0][1]<<8;

Выбрось каку!!!
Правильный компилятор (соответствующий стандарту) во всех трёх приведённых тобой вариантах должен был дать одинаковый результат, впрочем, не тот, который ты ожидаешь
Приведение к int делать вообще не нужно, оно должно было быть сделано согласно integer promotions самим компилятором.
А вот дальше - у оператора сложения приоритет выше, чем у операции сдвига (с моей точки зрения, приоритет сдвигов должен бы быть между приоритетами *% и +-, но K&R когда-то решили иначе и стандарт есть стандарт), поэтому
a + b << 8;
должно вычисляться всегда как
( a + b ) << 8;

А то, что хотелось сделать, следует записывать как
a + ( b << 8 );


p.s. Не понимаю, как можно пользоваться компилятором, настолько не соответствующим стандарту...
Или он позиционируется как "компилятор С-подобного языка программирования" ???

[Палыч]

Приведение к int делать вообще не нужно, оно должно было быть сделано согласно integer promotions самим компилятором.

ISO9899 п.6.3.1.1 абз.2

The following may be used in an expression wherever an int or unsigned int may be used:
— An object or expression with an integer type whose integer conversion rank is less than the rank of int and unsigned int.
— A bit-field of type _Bool, int, signed int, or unsigned int.
If an int can represent all values of the original type, the value is converted to an int; otherwise, it is converted to an unsigned int. These are called the integer promotions. All other types are unchanged by the integer promotions.

Так, должно или может быть сделано?