Деление 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, как беззнаковый.)

[sonycman]

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

Тогда обязан был быть ворнинг или даже еррор, так как в результате такого преобразования разрушается значение Int.
Но никакого предупреждения компилер не дает.

Вероятно, более продвинутые компиляторы понимают, что в моём случае sizeof() даёт размерность, которая умещается в простом char, и, соответственно, не преобразуют Int.
Для GCC это непосильная задача

[AHTOXA]

Вероятно, более продвинутые компиляторы понимают, что в моём случае sizeof() даёт размерность, которая умещается в простом char, и, соответственно, не преобразуют Int.
Для GCC это непосильная задача

1. sizeof() возвращает size_t, независимо от значения.
2. int/size_t возвращает size_t. (при условии sizeof(int) == sizeof(size_t) )
Это требование стандарта.
Вы считаете, что несоблюдение компилятором стандарта языка говорит о том, что этот компилятор "более продвинутый"?

Кстати, есть вариант, что в этих продвинутых компиляторах int просто длиннее, чем size_t, и поэтому всё получается нормально без нарушения стандарта.

[sonycman]

1. sizeof() возвращает size_t, независимо от значения.
2. int/size_t возвращает size_t. (при условии sizeof(int) == sizeof(size_t) )
Это требование стандарта.
Вы считаете, что несоблюдение компилятором стандарта языка говорит о том, что этот компилятор "более продвинутый"?

Кстати, есть вариант, что в этих продвинутых компиляторах int просто длиннее, чем size_t, и поэтому всё получается нормально без нарушения стандарта.

А что, Вы будете спорить, что IAR и прочие коммерческие компилеры - более продвинутые?
Это видно и на моём примере
А в защиту GCC можно сказать только - что он "блюдёт" стандарты.

[AHTOXA]

Вот уж не ожидал, что приведённое мной объяснение может вызвать такую реакцию.
Подумайте ещё вот о чём. Существует ненулевая вероятность, что в какой-то из следующих версий IAR данное несоответствие стандарту устранят...

[sonycman]

Вот уж не ожидал, что приведённое мной объяснение может вызвать такую реакцию.
Подумайте ещё вот о чём. Существует ненулевая вероятность, что в какой-то из следующих версий IAR данное несоответствие стандарту устранят...

Да обычная реакция. Когда в очередной раз слышишь, что маразм из разряда -2/1=2 - это стандарт.

Не только IAR "игнорирует" ваш стандарт, но и CodeVisionAVR.
Я еще Keil не проверял, возможно, он тоже из разряда "недоделанных"

Может быть, отличия в результатах компиляции - вовсе не различная трактовка стандартов, а работа оптимизации?

[AHTOXA]

Это не мой стандарт, это стандарт языка Си.
И лучше такой стандарт, чем никакого. Странно, что вы, вроде бы достаточно опытный разработчик, этого не понимаете.
А уж ссылки на CodeVisionAVR - это вообще нонсенс, поскольку давно известно, что CodeVisionAVR - это компилятор "языка, похожего на Си":)
Вы лучше проверьте "взрослые" компиляторы.
(И посмотрите в IAR, чему там равны sizeof(int) и sizeof(size_t), вдруг и IAR соблюдает стандарт).

[sonycman]

(И посмотрите в IAR, чему там равны sizeof(int) и sizeof(size_t), вдруг и IAR соблюдает стандарт).

Оба равны двум, что неудивительно. Только у одного 2+2 равно 4, а у второго - 5.
Думаете, какой из них больше соблюдает стандарт?

ЗЫ: сейчас докачаю Кейл и проверю там, на АРМ.

ЗЗЫ: Упс, обновил AtmelStudio на последнюю версию 6.1 (стояла 6.0), ничего в тексте не менял, пересобрал проект - появилось знаковое деление и обработка отрицательных значений.
То есть исправили багу и теперь поведение GCC стало аналогичным IAR.
Попробуйте теперь объяснить, как необходимо правильно трактовать разные умные стандарты

Ставить Кейл пока не стану, уверен, что его код будет аналогичен IAR.