Про целочисленные типы

[vitus_wagner]

Интересно, что количество бит в самом большом целочисленном типе, поддерживаемом современными компиляторами (int128_t), уже сравнялось с максимальным значением самого маленького (signed char).

Это к вопросу о том, как интерпретировать x << -1.

Мне пришли в голову две «естественные» интерпретации:

1. x << -1 = x >> 1.
2. x << -1 = x<< ((usigned что-то)-1) = x << 255 или x << 65535 и так далее.

В обоих случаях 1 << -1 = 0.

Но не все компиляторы с этим согласны. (понятно что по стандарту это undefined behavoir).

Comments

[qkowlew.livejournal.com]

Всё, для чего в копмпиляторе не определено точное поведение, но при этом может быть написано программистом, откомпилировано и исполнено, это источник:
- ошибок обновления компилятора. Так как сегодняшняя версия компилирует один код, а завтрашняя - другой. Просто из-за того, что поведение undefined - никто не тестировал.
- ошибок обновления кода. Опять же - при редактировании собственной программы автор не задумывается о данном кусочке, ичто он изменит работу.
- ошибок несовместимости архитектур ПРОЦЕССОРА - "на x86 работаем, на x64 нет" хотя бы
- ошибок различия сред исполнения. Пример из реальной жизни - одна и та же ДОС/Win95 программа, запущенная в досбокс в современной Windows. Ещё смешнее - одна и та же программа, запущенная в английской и русской версиях операционки. Достаточно ОДНОГО национального символа в одном пути к файлу чтобы получить потрясающие спецэффекты.

[vitus_wagner]

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

А через двадцать лет появляется новый компилятор который на это говорит "фу". Я тут было дело недавно правил подобного рода конструкцию в catdoc. Не помню зачем я ее написал во времена turbo C 2.0, но вот CLang на 64-битной архитектуре жрать отказался.

Но вообще когда у тебя "на x86 работаем, а на x64 нет", это полбеды. Вот когда "на x86 работаем, на x64 работаем, на ARMv5 работаем, а на ARMv7 внезапно нет"...

[livelight]

В языке Си есть и активно используется куча всего такого, для чего не определено единое для всех платформ поведение. Например, int имеет такой размер, какой удобно платформе, что уже неприятно, если вдруг данные, которые вчера влезали, сегодня не влезают, не говоря уже о записи их на внешние устройства для чтения кем-нибудь. Элементы массива struct'ов компилятор может по своему желанию выровнять на границу слова. Аналогично - какой-нибудь long внутри struct, особенно если архитектура процессора не позволяет ему адресовать невыровненные слова. Учитывая обычные для Си операции вида "привести указатель к char* , прибавить сколько-то, откастовать полученное к другому типу указателя и что-нибудь сделать с полученным", простор для непереносимостей вообще гигантский. Так что - только java, только хардкор :)

[metaclass.livejournal.com]

stdint.h спасет от всего.

[livelight]

От выравниваний не спасёт :)
От разных endianness тоже, кстати.

И вот такой код

struct A {
whatever1 x;
whatever2 y;
whatever3 z;
} a[2];

write(fd, a, sizeof(a));

может нанести немало неожиданностей даже для типов whatever... из этой библиотеки.

[qkowlew.livejournal.com]

Даже в пределах одного x86 процессора не спасает, как только вступает в действие генерация кода с адресной арифметикой. Turbo C 2.0, модель памяти Huge. Я в ней писал и компилил ФИДО тоссер и мопутствующие ему программы, если что. ;-)

[vitus_wagner]

Какой stdint.h в Turbo C 2.0? Насколько я помню, stdint.h появился в стандарте C99.