Деление int на size_t Опции

[sonycman]

Возникла непонятка.
Использую деление переменной типа int на значение, возвращаемое функцией sizeof():

int t;
...
t = t / sizeof(buf);
if (t < 0) ...
else ...

Так вот - знак t может быть различный, но после деления на sizeof() компилятор считает, что знак результата становится положительный и отбрасывает ветку кода для обработки отрицательного значения. Даже функция деления используется беззнаковая.
Если вместо sizeof() подставить константу, то всё начинает работать как положено.

Что я делаю не так, подскажите?

[sonycman]

Программа и так компилируется в плюсах, какого-то специального варнинга не видел.
Если вместо sizeof() использовать const unsigned char size = 20, то проблем со знаком нет, результат получается со знаком.
Не глюк ли это компилятора? Как еще это можно обьяснить?

[AHTOXA]

Программа и так компилируется в плюсах, какого-то специального варнинга не видел.

Если там gcc, то за это предупреждение отвечает флаг -Wsign-compare.

[sonycman]

Если перейдете на С++ (язык с более строгим контролем соответствия типов данных) , то компилятор по-хорошему должен выдать сообщение об ошибке и потребовать явного приведения к типу. Всякого рода умолчания тут вредны.

Это именно C++.
А в чём именно ошибка? Int делим на Short (или любой другой тип без знака). В результате будет Int. Это ошибка?

И надо учитывать, что sizeof возвращает не unsigned char, и даже не unsigned int, а size_t.

Функция у sizeof() - вернуть константу, то есть самое обычное число без знака. Каким образом её результат может влиять на знак выражения типа: -100/х = y?

Если там gcc, то за это предупреждение отвечает флаг -Wsign-compare.

Проверил на других компиляторах: IAR и CodeVision не страдают этой ошибкой и генерят код в соответствии с математическими правилами и моими ожиданиями.
А вот GCC в AtmelStudio и для ARMов точно также отбрасывает знак и считает, что результат может быть только положительный.
Прискорбно

[AHTOXA]

А вот GCC в AtmelStudio и для ARMов точно также отбрасывает знак и считает, что результат может быть только положительный.
Прискорбно

Это не прискорбно, это - в соответствии со стандартом.
Вот что говорится в ISO/IEC 9899:1999 6.3.1.8 Usual arithmetic conversions:

Otherwise, the integer promotions are performed on both operands. Then the following rules are applied to the promoted operands:

• If both operands have the same type, then no further conversion is needed.
• Otherwise, if both operands have signed integer types or both have unsigned integer types, the operand with the type of lesser integer conversion rank is converted to the type of the operand with greater rank.
• Otherwise, if the operand that has unsigned integer type has rank greater or equal to the rank of the type of the other operand, then the operand with signed integer type is converted to the type of the operand with unsigned integer type.
• Otherwise, if the type of the operand with signed integer type can represent all of the values of the type of the operand with unsigned integer type, then
  the operand with unsigned integer type is converted to the type of the operand with signed integer type.
• Otherwise, both operands are converted to the unsigned integer type corresponding to the type of the operand with signed integer type.

Ваш вариант - последний (поскольку int не может вместить всех значений size_t, size_t - не может вместить всех значений int, то побеждает size_t, как беззнаковый.)

[zhevak]

... и еще вот тут есть интересные рассуждения про size_t

http://www.embedded.com/electronics-blogs/...-size-t-matters

Переведу-ка я ее на русский, да опубликую не сегодня-завтра в своем блоге.
Полезное ведь дело, однако, да.