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

1. А существуют ли в реальности 64-
битные ошибки?
Автор: Андрей Карпов
Дата: 08.11.2009
Я часто слышу в различных интерпретациях фразу "Приведенные примеры показывают не код,
неправильный в плане переносимости на х64 системы, а код, неправильный сам по себе".
Захотелось немного пообсуждать и пофилософствовать в блоге на эту тему. Просьба отнестись к
этой записи с долей юмора.
Во-первых, можно начать с того, что любой код, написанный на Си++, уже неправильный сам по
себе. Правильным будет только код, состоящий из пустой функции main, и то я не уверен.
Невозможно написать идеальную корректную программу на Си/Си++. Ведь надо учесть, что
программа должна работать на 12-, 16-, 32-, 64-, ...-битной системе. Программа, по возможности,
не должна динамически выделять память, так как кое-где ее очень мало. Еще надо, чтобы в ней
не использовались функции типа scanf, ведь программу может понадобиться поместить в
контроллер, где нет устройства ввода. В программе не должно использоваться приведение типов.
Любое приведение типа, это потенциально какая-то ошибка на какой-то платформе. Еще
возможно лучше писать программу с помощью триграфов. А то вдруг...
В общем, я к тому, что идеально верных программ на Си/Си++ не бывает. Можно стремиться, но
сделать такую программу нельзя. В реальном мире при написании программ выбирают какой-то
приемлемый уровень корректности и предположения об окружающей среде исполнения и в
рамках этой модели пишут программу.
Итак, любой код неправилен сам по себе с точки зрения идеального программиста с золотыми
руками, находящегося в вакууме. Но можно считать, что определенный код корректен при
определенных условиях. При изменении условий (окружения) код может становиться
некорректен. В чем он становится некорректен - зависит от внешних изменений. Поиск возникших
ошибок при смене среды исполнения, можно собрать в группу и успешно диагностировать. В то
время как подход "в программе все неправильно" не рационален.
Рассмотрим пример. Имеем программу, переносимую в контроллер, который не будет иметь
консоли. В программе есть некоторое количество cout, cin, printf, scanf. Необходимо найти эти
функции и "обезвредить". Допустим, осуществляться ввод будет через порты, подсоединенные к
какой-нибудь ручке на ящике прибора. Не имеет смысла говорить, что код плох, что программист,
писавший его, плох, раз он сразу не предусмотрел, что консоли может не быть и единым
движением нельзя отключить все эти места. Это нам не поможет. И нет смысла заниматься
идеальным рефакторингом для создания идеальной программы. Надо просто найти и поправить
нужные места. Можно придумать статический анализатор в духе диагностики "проблем ввода-
вывода в контроллерах". И он будет полезен! Хотя, если по-честному, конечно все из-за
неидеального кода.

2. Пример выше сильно натянут, но просто хочется продемонстрировать, что когда человек пишет
код, он не может предусмотреть все. Не знает он, что его код через 5 лет будет засовываться в
контроллер, переноситься на 64-битную систему или адаптироваться для подводной лодки.
Предусмотреть что-то заранее весьма непросто.
Программисты имеют и поддерживают такой код, какой у них есть. В нем может быть полно
магических чисел, ТЫСЯЧИ выражений, где вместе используются знаковые и беззнаковые типы,
могут быть отключены многие предупреждения, из-за необходимости использования БОЛЬШИХ
старых сторонних библиотек. И заниматься полномасштабным рефакторингом таких проектов,
чтобы они стали красивее, переносимее и так далее, никто не будет. А того кто будет настаивать -
пожалуй, начальству следует уволить.
В реальном мире надо решать реальные задачи. Надо добавлять новую функциональность,
поддерживать работоспособность на существующих системах. Если понадобится - перенести код
на 64 бита. Но при переносе кода на 64-битную систему, будет решаться именно эта задача, а не
как сделать код максимально переносимым. И вот здесь возникает практическая задача найти
определенные магические числа (но не все), найти опасные выражения со знаковыми и
беззнаковыми типами (но не все).
Моя позиция покажется многим неверной, как будто я призываю писать плохой код, а затем
призываю использовать различные костыли (которые сам и продаю), чтобы его местами
подправить. Я просто практик. И еще я называю многие вещи своими именами.
В большинстве своем код программ ПЛОХ. И более или менее работает, потому, что ему везет. К
сожалению, программисты упорно не хотят это признавать. Любая "встряска кода" (смена
компилятора, среды исполнения и так далее) вскрывает пласт определенных типов ошибок. Я
понимаю, что нет "64-битных" ошибок. Есть просто ошибки в коде. Они всегда есть. Но
определенные ошибки проявят себя именно на 64-битной системе. Я рассказываю о таких
ошибках и надеюсь это полезно разработчикам. И именно такие ошибки я называю "64-битные
ошибки".