Для получения триального ключа
заполните форму ниже
Team License (базовая версия)
Enterprise License (расширенная версия)
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Запросите информацию о ценах
Новая лицензия
Продление лицензии
--Выберите валюту--
USD
EUR
GBP
RUB
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Бесплатная лицензия PVS-Studio для специалистов Microsoft MVP
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Для получения лицензии для вашего открытого
проекта заполните, пожалуйста, эту форму
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Мне интересно попробовать плагин на:
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Ваше сообщение отправлено.

Мы ответим вам на


Если вы так и не получили ответ, пожалуйста, проверьте папку
Spam/Junk и нажмите на письме кнопку "Не спам".
Так Вы не пропустите ответы от нашей команды.

>
>
А существуют ли в реальности 64-битные …

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

08 Ноя 2009

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

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

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

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

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

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

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

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

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

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

Популярные статьи по теме
Статический анализ как часть процесса разработки Unreal Engine

Дата: 27 Июн 2017

Автор: Андрей Карпов

Проект Unreal Engine развивается - добавляется новый код и изменятся уже написанный. Неизбежное следствие развития проекта - появление в коде новых ошибок, которые желательно выявлять как можно раньш…
PVS-Studio ROI

Дата: 30 Янв 2019

Автор: Андрей Карпов

Время от времени нам задают вопрос, какую пользу в денежном эквиваленте получит компания от использования анализатора PVS-Studio. Мы решили оформить ответ в виде статьи и привести таблицы, которые по…
Как и почему статические анализаторы борются с ложными срабатываниями

Дата: 20 Мар 2017

Автор: Андрей Карпов

В своей предыдущей статье я писал, что мне не нравится подход, при котором статические анализаторы кода оцениваются с помощью синтетических тестов. В статье приводился пример, воспринимаемый анализат…
Эффект последней строки

Дата: 31 Май 2014

Автор: Андрей Карпов

Я изучил множество ошибок, возникающих в результате копирования кода. И утверждаю, что чаще всего ошибки допускают в последнем фрагменте однотипного кода. Ранее я не встречал в книгах описания этого …
Как PVS-Studio оказался внимательнее, чем три с половиной программиста

Дата: 22 Окт 2018

Автор: Андрей Карпов

PVS-Studio, как и другие статические анализаторы кода, часто выдаёт ложные срабатывания. Но не стоит спешить считать странные срабатывания ложными. Это короткая история о том, как PVS-Studio вновь ок…
Технологии, используемые в анализаторе кода PVS-Studio для поиска ошибок и потенциальных уязвимостей

Дата: 21 Ноя 2018

Автор: Андрей Карпов

Краткое описание технологий, используемых в инструменте PVS-Studio, которые позволяют эффективно обнаруживать большое количество паттернов ошибок и потенциальных уязвимостей. Статья описывает реализа…
PVS-Studio для Java

Дата: 17 Янв 2019

Автор: Андрей Карпов

В седьмой версии статического анализатора PVS-Studio мы добавили поддержку языка Java. Пришло время немного рассказать, как мы начинали делать поддержку языка Java, что у нас получилось и какие дальн…
Любите статический анализ кода!

Дата: 16 Окт 2017

Автор: Андрей Карпов

Я в шоке от возможностей статического анализа кода, хотя сам участвую в разработке инструмента PVS-Studio. На днях я был искренне удивлён тому, что анализатор оказался умнее и внимательнее меня.
Главный вопрос программирования, рефакторинга и всего такого

Дата: 14 Апр 2016

Автор: Андрей Карпов

Вы угадали, ответ - "42". Здесь приводится 42 рекомендации по программированию, которые помогут избежать множества ошибок, сэкономить время и нервы. Автором рекомендаций выступает Андрей Карпов - тех…
Характеристики анализатора PVS-Studio на примере EFL Core Libraries, 10-15% ложных срабатываний

Дата: 31 Июл 2017

Автор: Андрей Карпов

После большой статьи про проверку операционной системы Tizen мне было задано много вопросов о проценте ложных срабатываний и о плотности ошибок (сколько ошибок PVS-Studio выявляет на 1000 строк кода)…

Комментарии (0)

Следующие комментарии
Этот сайт использует куки и другие технологии, чтобы предоставить вам более персонализированный опыт. Продолжая просмотр страниц нашего веб-сайта, вы принимаете условия использования этих файлов. Если вы не хотите, чтобы ваши данные обрабатывались, пожалуйста, покиньте данный сайт. Подробнее →
Принять