что такое баги в программах

Типы багов: этимология и энтомология

1. Немного этимологии и энтомологии
Давайте посмотрим попристальней на такое знакомое и (до боли?) родное слово БАГ. Происходит оно от английского слова Bug, означающего «насекомое». Есть еще много сторонних значений, в частности английское выражение «to go bugs» — сойти с ума, что легко кореллируется со вполне русским «тараканы в голове завелись». Также вспоминаются и «жучки на линии» (тоже, кстати, по-английски – bugs). И опять мы пришли к насекомым.

Еще в 1878 году, Томас Альва Эдисон (да-да, тот самый!) в письмах к своему соратнику Пускасу писал: «It has been just so in all of my inventions. The first step is an intuition, and comes with a burst, then difficulties arise — this thing gives out and [it is] then that ‘Bugs’ — as such little faults and difficulties are called — show themselves and months of intense watching, study and labor are requisite before commercial success or failure is certainly reached». Тем же словом, инженеры называли и сбои радарной электроники во время второй Мировой Войны. Конечно, более распространена история о том, что в 1946 году разработка компьютера Марк-2 (Mark-II) были приостановлена из-за сбоя его функционирования, вызванного попаданием мотылька между контактов. Трупик мотылька был извлечен и приклеен к отчету липкой лентой с комментарием «First actual case of bug being found.» («Первый реальный случай нахождения жучка»). Как нетрудно догадаться, примерно оттуда же «растут уши» и слова «дебаггер» (debugger) – буквально «избавитель от жучков».

2. Виды багов.
Простейший (не как инфузория-туфелька, а самый простой для понимания, модно сказать «классический») баг – это несоответствие между ожидаемым результатом (ОР) и фактическим результатом (ФР). Разберем это на примере:

(это, кстати, реальный баг старого Microsoft Excel – он не учитывал приоритета математических операций, по которому умножение имеет высший приоритет по сравнению со сложением)

Все просто. Ждем одно – получаем другое. Баг.
Я не буду перечислять все подвиды бага классического – от опечаток в данных и опечаток в коде до бесконечных циклов, от использования оператора присвоения вместо оператора проверки равенства до использования неинициализированной переменной, от состояния гонки (race condition) в мультипоточных приложения до переполнения буфера, и так далее, и тому подобное – все это достаточно обыденные и ясные явления. Обратимся к малознакомой экзотике.

2.1. Гейзенбаг (Heisenbug)
Баг, названный в честь Гейзенбергского Принципа неопределенности – концепции квантовой физики. Простым (хоть слово «просто» здесь и не очень применимо) примером подобного бага будет являться ошибка, проявляющаяся, когда программа запускается на исполнение в рабочей среде, но исчезающая, когда программу запускают в дебаггере.

2.2. Борбаг (Bohrbug)
Тип бага, названный так в честь атомной модели Бора. В противоположность Гейзенбагу, он проявляется постоянно при одном и том же стечении обстоятельств. Вопрос в том, что весь набор обстоятельств бывет невозможно (или очень трудно) отследить.

2.3. Мандельбаг (Mandelbug)
Назван в честь Бенуа Мандельброта, внесшего огромный вклад в теорию фракталов. Мандельбагами называют ошибки, чьи причины настолько сложны и неясны, что фактически кажутся хаотичными и не поддающимися описаниями. (ключевое слово «кажутся»). Подобное, может быть вызвано, например, медленной реакцией системы – то есть ошибка уже произошла, но об этом вы узнаете только через некоторое время, что сильно затруднит локализацию причин.

2.4. Шрединбаг (Schroedinbug)
Шрединбаг назван в честь известного парадокса с кошкой Шредингера (или эта несчастная животина – кот?). Он заключается в том, что кто-нибудь читает код программы (работающей уже некоторое время) и восклицает «Да этого не может быть! Она просто не может функционировать!», после чего программа прекращает свое функционирование пока данная ошибка не будет исправлена. Будучи, казалось бы, абсолютно фантастической, данная ошибка попадается в реальности – спросите знакомых ветеранов- разработчиков, они подтвердят. Хотя, конечно, последующий анализ, как правило, позволяет отнести ошибку к разделам 2.1, 2.2 или 2.3, это удается не всегда.

2.5. Фазы луны
На самом деле такой ошибки не существует – это популярная отговорка тех, кто не хочет (не имеет желания и/или времени) разбираться в сложных причинах возникновения ошибки. Тем не менее, в истории существует пара примеров, когда ошибки возникали буквально из-за фаз луны. Я не буду приводить здесь эти истории, надеясь, что никому из нас не придется работать со столь сложными устройствами. Тем не менее, в любом случае, хотелось бы предостеречь всех от неосторожных умозаключений и попросить быть более внимательными, настойчивыми и скрупулезными в своей работе.

2.6. Статистический (более известный как количественный) баг
Баг возникающий при произведении программой большого количества каких-либо действий. Примером данной ошибки может служить запуск программы, которая должна равномерно расположить на плоскости некоторое количество точек. Если, например, при большом количестве точек программа не только неправильно располагает их, но и норовит расположить все на одной стороне плоскости (при этом до определенного количества точек работая прекрасно) – вуаля, количественный баг.

2.7. Демонстрационный эффект.
Ну и конечно, известный всем, «эффект первого показа», не раз случавшийся и с вашим покорным слугой. Как только приходит пора показать, например, прекрасно функционировавший на тестовом стенде юнит, обязательно происходит что-то ужасное. Причны, как правило, тривиальны – пропуск «незначительных» тест-кейсов, невнимательность к деталям и неучтенные юз-кейсы. Опять же – будьте внимательней.

На этом я закончу краткий обзор багов, буду рад Вашим замечаниям и предложениям.

Источник

Баги и ошибки — как искусство

Введение

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

Что такое “БАГ”

В программировании баг (англ. bug — жук)— жаргонное слово, обычно обозначающее ошибку в программе или системе, которая выдает неожиданный или неправильный результат. Большинство багов возникают из-за ошибок, сделанных разработчиками программы в её исходном коде, либо в её дизайне. Также некоторые баги возникают из-за некорректной работы компилятора, вырабатывающего некорректный код. Программу, которая содержит большое число багов и/или баги, серьёзно ограничивающие её работоспособность, называют нестабильной или, на жаргонном языке, “глючной”, “глюкнутой”, “забагованной”, “бажной”, “баг (а) нутой” (англ. unstable, buggy). Термин «баг» обычно употребляется в отношении ошибок, проявляющих себя на стадии работы программы, в отличие, например, от ошибок проектирования или синтаксических ошибок. Отчет, содержащий информацию о баге, также называют отчетом об ошибке или отчетом о проблеме (англ. bug report). Отчет о критической проблеме (англ. crash), вызывающей аварийное завершение программы, называют крэш репортом (англ. crash report). «Баги» локализуются и устраняются в процессе тестирования и отладки программы. Возможны ситуации, при которых ошибки остаются во внутреннем коде или программе они могут остаться не замеченными и обнаруженными уже при тестировании или выпуске программы или игры. Такие ситуации исправляются так называемыми “патчами” (англ. patch), выпускаются они как можно скорее стараясь залатать все дыры и проблемы, когда патч готов разработчик или программист выпускает “патч ноут” (англ. Patch note) список изменений и исправлений. На этом с терминологией всё, приступим к практике.

Как выглядит баг

И как его исправить

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

Место без текстур в Fallout76 – источник

Творческие решения

Но у ошибок нашли хорошую соревновательную сторону, спидраны — забеги по играм на скорость, проходить игру просто это так скучно, а вот с ошибками это совсем другое дело, сократить игру в 3 раза прыгая за текстуры, профессионалам на это дело расплюснуть, разбирать спидраны я не буду всё это уже сделали за меня, хочу лишь сказать что это удивительно как люди используют ошибки и недоработки, рассчитывают всё до пикселя и всё это основано на ошибках, багах и глитчах.

Критические ситуации

За примером далеко ходить не надо, можно вспомнить лица из Assassin’s Creed Unity, проблема была вызвана несовместимостью с некоторыми видеокартами, это ошибка была исправлена в патче первого дня но оставила свой отпечаток на и так большом пласте ненависти ввиду отсутствия оптимизации и багов, вот что об этом говорит главный творческий руководитель Ubisoft Жан Жесдон:

Если вы поиграете сейчас, со всеми исправлениями, — это будет очень красивая и хорошая игра. Иными словами, вероятно, мы подлетели слишком близко к Солнцу и утратили самоконтроль.

Именно поэтому Syndicate концентрировалась на качестве, с чем команда отлично справилась. Жан Жесдон

В заключении хотел бы сказать что баги и ошибки порадили целые сегменты в разных культурах и стали большой частью игр и игровой индустрии. _DeVloPPeR_

Источник

Что такое баги, ворнинги и исключения в программировании

Разбираемся, какие бывают типы ошибок в программировании и как с ними справляться.

Многим известно слово баг (англ. bug — жук), которым называют ошибки в программах. Однако баг — это не совсем ошибка, а скорее неожиданный результат работы. Также есть и другие термины: ворнинг, исключение, утечка.

В этой статье мы на примере C++ разберём, что же значат все эти слова и как эти проблемы влияют на эффективность программы.

Пишет о программировании, в свободное время создает игры. Мечтает открыть свою студию и выпускать ламповые RPG.

Ошибки в программировании

Словом «ошибка» (англ. error) можно описать любую проблему, но чаще всего под ним подразумевают синтаксическую ошибку — некорректно написанный код, который даже не скомпилируется:

Компилятор тут же скажет, что в коде ошибка и скорее всего не хватает запятой или точки с запятой.

Также существуют ворнинги (англ. warning — предупреждение). Они не являются ошибками, поэтому программа всё равно будет собрана. Вот пример:

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

После восклицательного знака в треугольнике — количество предупреждений

Третий вид ошибок — ошибки сегментации (англ. segmentation fault, сокр. segfault, жарг. сегфолт). Они возникают, если программа пытается записать что-то в ячейку, недоступную для записи. Например:

Вот результат работы такого кода:

Баги в программах

Мы выяснили, что баг — это не совсем ошибка, а скорее неожиданное поведение программы или результат такого поведения. Баги могут быть чем-то забавным или неприятным. Например, как в играх:

Но они могут привести и к более серьёзным последствиям. Если неправильно спроектировать работу многопоточного приложения, то потоки будут постоянно опережать друг друга. Например, сообщение об ошибке из одного потока может опоздать на миллисекунду, из-за чего второй поток подумает, что никакой ошибки не было, и продолжит работу.

Если ваш код приводит в действие какое-нибудь потенциально опасное устройство, то ценой такой ошибки может быть чья-нибудь жизнь. Такое случилось с кодом для аппарата лучевой терапии Therac-25 — как минимум два человека умерло и ещё больше пострадали из-за превышения дозы радиации.

Исключения в программах

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

Конвертировать введённое значение не всегда возможно, поэтому функция, которая занимается преобразованием, «выбрасывает» исключение (англ. exception). Это специальное сообщение говорит о том, что что-то идёт не так.

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

Одно из самых известных исключений — переполнение стека (англ. stack overflow). В честь него даже назвали сайт, на котором программисты ищут помощь в решении своих проблем.

Компилятор C++ при этом может выдать ошибку сегментации, а не сообщение о переполнении стека:

Вот аналогичный код на языке C#:

Однако сообщение в этот раз более конкретное:

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

Похожая ситуация — переполнение буфера (англ. buffer overflow). Она происходит, когда записываемое значение больше выделенной области в памяти.

Обратите внимание, что мы получили предупреждение об арифметическом переполнении (англ. integer overflow):

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

Арифметическое переполнение стало причиной одной из самых дорогих аварий, произошедших из-за ошибки в коде. В 1996 году ракета-носитель «Ариан-5» взорвалась на 40-й секунде полёта — потери оценивают в 360–500 миллионов долларов.

Как избежать всех этих ошибок

К сожалению, вручную всё это заметить и исправить не получится. Однако существуют различные инструменты и технологии, которые могут помочь.

Один из таких инструментов — отладчик. Он помогает контролировать ход работы программы, чтобы отслеживать разные показатели.

Второй, более эффективный метод — unit-тесты. Они представляют из себя набор описанных ситуаций для каждого компонента программы с указанием ожидаемого поведения.

Например, у вас есть функция sum (int a, int b), которая возвращает сумму двух чисел. Вы можете написать unit-тесты, чтобы проверять следующие ситуации:

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

Заключение

Ошибок существует слишком много. При этом самые опасные тяжелее обнаружить, что только усугубляет ситуацию.

Если вы хотите научиться писать качественный код и находить в нём ошибки, вы можете записаться на наш курс по разработке на C++.

Источник

10 Эпических багов в компьютерных программах

Программное обеспечение пишут люди, поэтому в каждой программе есть свои баги, или «недокументированный функционал», как это назвал бы маркетолог. Для тех, кто не знает, что такое баги – это когда программа делает что-то, что не должна делать или не делает то, что должна делать. Баги могут возникать из-за неправильного проектирования, не полного понимания проблемы или просто из-за человеческой ошибки – примерно, как опечатка в книге. Проблема заключается в том, что книгу читает человек, который может догадаться о том, что именно имел в виду автор, а машинный код исполняется компьютерами, которые способны делать только то, что им сказано.

Ниже представлены десять примеров тех случаев, когда последствия багов были огромными в том или ином плане:

10. Терак-25 (Therac-25)
Терак-25 – аппарат для лучевой терапии, используемый чаще всего для лечения онкологических больных. У аппарата было два режима работы. В первом режиме аппарат направлял луч электронов прямо на пациента маленькими дозами и непродолжительное время. Во втором режиме аппарат направлял интенсивный луч электронов на металлическую «цель», что позволяло фактически преобразовать луч в рентгеновское излучение, которое затем достигало пациента.

В предыдущих моделях Терака для второго режима работы были физические предохранители, которые обеспечивали наличие металлического отражателя, без которого лучи высокой энергии могли бы попасть по ошибке прямо на пациента. В новой модели физические предохранители были заменены «предохранителями» в программном обеспечении.

К сожалению, в программе был баг: иногда во время автоматических проверок на безопасность случалось «арифметическое переполнение». При таком баге система использует в вычислениях слишком большое число, которое она не может обработать. Если в этот момент оператор настраивал аппарат, предохранители не срабатывали, и металлическая пластина не помещалась на нужное место. В результате на пациента попадали лучи, интенсивность которых была в 100 раз больше, чем нужная. В шести случаях пациенты получили передозировку радиацией, 4 из этих случаев закончились смертью пострадавшего.

8. Отсутствие электричества в Северной Америке

Отключение электричества в 2003 году на северо-востоке США и в Онтарио, Канада повлияло на 55 миллионов людей и стало одной из самых крупных аварий в энергосистемах за всю историю. Авария началась в момент, когда электростанция на южном берегу озера Эри (Erie) штате Огайо прекратила свою работу по причине слишком высокого потребления электроэнергии, что повлекло за собой увеличение нагрузки на остальную электрическую сеть. Когда линии электропередач перегружены, они нагреваются, из-за чего происходит тепловое расширение проводов. Несколько линий электропередач провисли настолько, что задели деревья, из-за чего произошло короткое замыкание, в результате которого нагрузка на электросеть возросла. Все эти факторы повлекли за собой каскадный эффект, из-за которого мощность энергосистемы упала до 20% от нормального значения.

Причина аварии никак не связана с багом в программном обеспечении, но её можно было бы предотвратить, если бы не баг в программе, отвечающей за систему оповещения в центре управления энергосистемами. Две части системы «соревновались» за один ресурс и не могли разрешить конфликт (ошибка проектирования под названием «состояние гонки»), из-за этого система оповещения зависла и перестала обрабатывать сигналы тревоги. К сожалению, остановка системы оповещения была «тихой», то есть она не оповестила никого о своей поломке. Не было произведено никаких звуковых или визуальных оповещений, которые бы предупредили работников об остановке системы, которые полностью опираются на подобные оповещения для получения информации о статусе энергосистемы. Последствия аварии широко освещались в масс-медиа: многие территории оставались без электричества на протяжении нескольких дней, что повлияло на промышленность, предоставление коммунальных услуг и связи. Считается, что даже несколько смертей были результатом аварии.

7. Происшествие на авианосце USS Yorktown

К стыду программистов движущая система USS Yorktown полностью остановилась, оставив авианосец беспомощным в воде на 3 часа, когда один из членов экипажа корабля ввёл ноль в бортовую систему управления базами данных, а система попыталась произвести операцию деления на ноль. Программное обеспечение было установлено в ходе проекта по использованию компьютеров для уменьшения необходимо количества людей в экипажах некоторых кораблей. К счастью, корабль в это время участвовал в учебных манёврах, и не был в разгаре битвы, иначе последствия ошибки были бы плачевными.

Во время Холодной Войны, когда отношения между США и СССР были, мягко скажем, напряжёнными, ЦРУ, якобы, преднамеренно ввело несколько багов в программное обеспечение, продаваемое канадской компанией, которое использовалось для управления газопроводом в Сибири. ЦРУ посчитало, что Россия покупала это программное обеспечение у канадской компании в попытке получить технологию США, и это было бы прекрасной возможностью дать СССР неполноценную технологию.

Такие операции были позже открыты в результате рассекреченного «Досье Farewell» (Farewell Dossier), где помимо всего остального, утверждалось, что в газопроводе были установлены бракованные турбины. Бывший министр военно-воздушных сил США, Томас Рид (Thomas Reed) утверждает, что в систему было введено несколько багов, которые бы не проявили себя во время тестирования, но привели бы к аварии во время непосредственного использования. Настройки насосов и клапанов были изменены, что привело к внештатному давлению в газопроводе, что в свою очередь привело к самому большому неядерному взрыву в мире.

5. Потенциальное начало ядерной войны во время Холодной Войны

Станислав Петров – офицер, служивший в секретном командном пункте, неподалёку от Москвы, в котором была расположена система раннего предупреждения. В одну из ночей, когда Петров был на дежурстве, ему поступило предупреждение о том, что США запустило 5 межконтинентальных баллистических ракет Минитмен (Minuteman). Согласно доктрине обоюдного уничтожения, превалирующей во время Холодной Войны, в ответ на атаку США, СССР должен был отомстить такой же атакой.

Если атака была настоящей, офицер должен был быстро отреагировать на неё. Однако, Петрову показалось странным, что США атаковало бы таким малым количеством боеголовок: хотя и эти ракеты бы нанесли огромный ущерб и большие человеческие потери, они бы не смогли нанести непоправимый ущерб СССР. Помимо этого, радары, расположенные на земле ничего не показывали, хотя они и не могли заметить ничего за линией горизонта из-за кривизны Земли, что объяснило бы задержку в наземных радарах.

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

4. Вредоносная защита от копирования на дисках Sony

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

Некоторые считают, что музыкальная компания Sony BGM в 2005 году зашла слишком далеко, когда они ввели новую форму защиты от копирования на некоторых аудио дисках. Когда диск проигрывался на компьютере под управлением операционной системы Windows, в систему внедрялся «руткит» (rootkit). Руткит – программное обеспечение, которое глубоко встраивается в операционную систему и изменяет некоторые из её фундаментальных процессов. Хотя руткиты, не всегда являются вредоносными, они зачастую используются для незаметной установки вредного и трудноудаляемого программного обеспечения – вирусов, троянов и т.д. В случае с Sony BMG целью было управлять тем, как Windows использует их аудио диск и не дать скопировать диск или сконвертировать звуковые дорожки в MP3 формат, что помогло бы снизить уровень пиратства для их продукции.

Руткит достиг своей цели, но из-за того, что он пытался скрыться от пользователя, это позволило и другому вредоносному программному обеспечению скрывать своё присутствие на компьютерах пользователей. Плохо продуманная имплементация и растущая уверенность пользователей, что Sony BMG не имело права пытаться незаметно управлять их компьютерами, привело к тому, что схема провалилась. Многие компании, занимающиеся компьютерной безопасностью, классифицировали руткит, как вредоносный код, а Sony BMG пришлось отвечать за свои действия в суде и отозвать партию аудиодисков с руткитом.

3. Баг в ракетном комплексе Пэтриот (Patriot)

Во время операции «Щит пустыни» (Desert Shield) США приняло на вооружение ракетный комплекс «Пэтриот» для защиты от ракетных ударов и вражеской авиации – в этом случае, от иракских ракет SCUD. Управляющее программное обеспечение ракет Пэтриот использует скорость своей цели и текущее время для предсказания траектории движения цели. Учитывая, что цели могут достигать скорости в 1.5 км/с, эти вычисления должны быть очень точны.

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

Отвечавшие за это люди, не совсем поняли что такое «регулярная» перезагрузка и система работала на протяжении 100 часов. Когда Ирак запустил свою ракету в сторону аэродрома США в Дахране (Dhahran), система Пэтриот определила запуск. Однако, к тому времени, внутренние часы уже были смещены на 0.34 секунды, поэтому, вычисленная ПО траектория оказалась ошибочной и система посчитала, что вражеской ракеты больше не существует и отменила попытку сбития ракеты. Ракета долетела до своей цели, в результате чего 28 американских солдат погибло, и 98 было ранено.

2. Проблема 2000 года

Баг Тысячелетия (Millennium Bug) или Проблема 2000 года – самый известны баг в этом списке и многие из нас слышали о нём в то время. Вкратце, этот баг был результатом «близорукости» компьютерных профессионалов в десятилетии, предшествующем 2000 году. Во многих компьютерных системах для обозначения даты использовалось две цифры, к примеру, 98 вместо 1998 года – это казалось достаточно логичным решением и использовалось даже до компьютеров.

В ответ на эту проблему, софтверные компании быстро обновили свои продукты, задействованные в управлении банковскими структурами, больничным оборудованием и другими важными сферами. Для подтверждения того, что баг может повлиять на компьютеры всего мира, в феврале 1999 года был создан «Интернациональный центр по разрешению проблемы 2000 года». Задачей центра была координация работы, необходимой для подготовки к новому тысячелетию. В конце концов, Новый Год прошёл без каких-либо проблем, помимо обычного похмелья.

Сложно сказать было ли успешное разрешение проблемы результатом проведённой работы или сама проблема была изначально преувеличена – скорее всего, и то и другое.

1. 2038 год

Хотя мы успешно преодолели 2000 год, проблемы ещё не закончились. Не все компьютеры одинаково работают с датами. Большинство операционных систем семейства UNIX представляют даты в виде прошедшего количества секунд с 1 января 1970 года. К примеру: 1 января 1980 года представляется, как 315532800 секунд после 1 января 1970 года. Это число хранится в компьютерах, как беззнаковое 32-битное целое число, которое может держать максимальное значение в 2147483647. Это означает, что компьютер может хранить 2147483647 в качестве даты, чего хватит только до 19 января 2038 года, после чего у нас опять могут появиться проблемы.

Баг может принести намного больше вреда, если учитывать что UNIX используется во встраиваемых системах, в которых связь между «железной» и софтверной частью намного сильнее – к примеру, в роботах, используемых на конвейерах, в часах, в рутерах и т.д.

Кому-то ещё надо подумать, что мы будем делать 1 января 10000 года. Но это уже явно не нам.

Источник