# А существуют ли в реальности 64\-битные ошибки?

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

Во\-первых, можно начать с того, что любой код, написанный на Си\+\+, уже неправильный сам по себе\. Правильным будет только код, состоящий из пустой функции main, и то я не уверен\. Невозможно написать идеальную корректную программу на Си/Си\+\+\. Ведь надо учесть, что программа должна работать на 12\-, 16\-, 32\-, 64\-, \.\.\.\-битной системе\. Программа, по возможности, не должна динамически выделять память, так как кое\-где ее очень мало\. Еще надо, чтобы в ней не использовались функции типа scanf, ведь программу может понадобиться поместить в контроллер, где нет устройства ввода\. В программе не должно использоваться приведение типов\. Любое приведение типа, это потенциально какая\-то ошибка на какой\-то платформе\. Еще возможно лучше писать программу с помощью триграфов\. А то вдруг\.\.\. 

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

Итак, любой код неправилен сам по себе с точки зрения идеального программиста с золотыми руками, находящегося в вакууме\. Но можно считать, что определенный код корректен при определенных условиях\. При изменении условий \(окружения\) код может становиться некорректен\. В чем он становится некорректен \- зависит от внешних изменений\. Поиск возникших ошибок при смене среды исполнения, можно собрать в группу и успешно диагностировать\. В то время как подход "в программе все неправильно" не рационален\.

Рассмотрим пример\. Имеем программу, переносимую в контроллер, который не будет иметь консоли\. В программе есть некоторое количество cout, cin, printf, scanf\. Необходимо найти эти функции и "обезвредить"\. Допустим, осуществляться ввод будет через порты, подсоединенные к какой\-нибудь ручке на ящике прибора\. Не имеет смысла говорить, что код плох, что программист, писавший его, плох, раз он сразу не предусмотрел, что консоли может не быть и единым движением нельзя отключить все эти места\. Это нам не поможет\. И нет смысла заниматься идеальным рефакторингом для создания идеальной программы\. Надо просто найти и поправить нужные места\. Можно придумать статический анализатор в духе диагностики "проблем ввода\-вывода в контроллерах"\. И он будет полезен\! Хотя, если по\-честному, конечно все из\-за неидеального кода\. 

Пример выше сильно натянут, но просто хочется продемонстрировать, что когда человек пишет код, он не может предусмотреть все\. Не знает он, что его код через 5 лет будет засовываться в контроллер, переноситься на 64\-битную систему или адаптироваться для подводной лодки\. Предусмотреть что\-то заранее весьма непросто\.

Программисты имеют и поддерживают такой код, какой у них есть\. В нем может быть полно магических чисел, ТЫСЯЧИ выражений, где вместе используются знаковые и беззнаковые типы, могут быть отключены многие предупреждения, из\-за необходимости использования БОЛЬШИХ старых сторонних библиотек\. И заниматься полномасштабным рефакторингом таких проектов, чтобы они стали красивее, переносимее и так далее, никто не будет\. А того кто будет настаивать \- пожалуй, начальству следует уволить\. 

 В реальном мире надо решать реальные задачи\. Надо добавлять новую функциональность, поддерживать работоспособность на существующих системах\. Если понадобится \- перенести код на 64 бита\. Но при переносе кода на 64\-битную систему, будет решаться именно эта задача, а не как сделать код максимально переносимым\. И вот здесь возникает практическая задача найти определенные магические числа \(но не все\), найти опасные выражения со знаковыми и беззнаковыми типами \(но не все\)\.

Моя позиция покажется многим неверной, как будто я призываю писать плохой код, а затем призываю использовать различные костыли \(которые сам и продаю\), чтобы его местами подправить\. Я просто практик\. И еще я называю многие вещи своими именами\. 

В большинстве своем код программ ПЛОХ\. И более или менее работает, потому, что ему везет\. К сожалению, программисты упорно не хотят это признавать\. Любая "встряска кода" \(смена компилятора, среды исполнения и так далее\) вскрывает пласт определенных типов ошибок\. Я понимаю, что нет "64\-битных" ошибок\. Есть просто ошибки в коде\. Они всегда есть\. Но определенные ошибки проявят себя именно на 64\-битной системе\. Я рассказываю о таких ошибках и надеюсь это полезно разработчикам\. И именно такие ошибки я называю "64\-битные ошибки"\.