Comments 16
Как предотвратить системную ошибку? Заменить все 32-битные процессоры на 64-битные.
А при чём тут процессор? 64-битный так же обнулит старшие если само значение 32-битное. А 32 вполне корректно отработает 64 если программа об этом в курсе.
Вот и я удивился — вроде в PVS Studio должны работать грамотные люди… а такой ляп допустили...
Как дурно на Вас Java (или что там кроссплатформенное?) влияет. Ничего, что размер целого зависит от платформы?
т.е. надо заменить и процессор, и программы для 64 архитектуры использовать.
т.е. надо заменить и процессор, и программы для 64 архитектуры использовать.
Внезапно… А ничего, что когда имеешь дело с общими и достаточно специфичными данными обычно используешь переменные необходимого для работы с ними размера. Не «кросплатформенные», а именно конкретные. Иначе они у вас просто в структуру не влезут. Т.е. будь у нас хоть 128-битный проц — всё равно в структуру больше чем 32 бита не влезет, увы. Это сейчас всё в тестовые форматы сериализуют, там пофиг на размер. А так уж повелось, что много где до сих пор используется именно 32бит unnix time представление. (зачем там используется знаковое — отдельный вопрос). В программе вы можете считать в каком удобно размере, но вернуть системе не получится.
Ну и, помнится под досом на древних XT никаких проблем с работой с 32-битными переменными не было (ну разве что приходилось считать по частям). 64 при острой необходимости тоже считали, просто делили на 4 куска вместо 2х.
Ну и, помнится под досом на древних XT никаких проблем с работой с 32-битными переменными не было (ну разве что приходилось считать по частям). 64 при острой необходимости тоже считали, просто делили на 4 куска вместо 2х.
Ерунду говорите, базы данных давно работают с 64-битными метками и 128-битными значениями даже на 32-битных архитектурах. Ну и что, что значение за один так не посчитается.
То-то есть куча багов со временем, которая только на 32битных платформах…
Например? Сходу могу вспомнить и более старые. Например компактное раздельное(отдельно часы, минуты, секунды) хранение времени в FAT (если мне не изменяет память) позволяло установить в метке времени более чем 59 минут или секунд. Чем активно пользовались разные вирусы в качестве метки заражения.
Моя очередь.
https://bugzilla.redhat.com/show_bug.cgi?id=1057047#c5
Проблемы с функциями времени, при этом «so I cannot back-port the perl changes to support 32-bit platforms.» и указаны типы данных на 32 битных и 64 битных платформах. Они отличаются. Так что «Заменить все 32-битные процессоры на 64-битные» (это то что в треде, что мы обсуждаем) вполне себе годный совет.
https://bugzilla.redhat.com/show_bug.cgi?id=1057047#c5
Проблемы с функциями времени, при этом «so I cannot back-port the perl changes to support 32-bit platforms.» и указаны типы данных на 32 битных и 64 битных платформах. Они отличаются. Так что «Заменить все 32-битные процессоры на 64-битные» (это то что в треде, что мы обсуждаем) вполне себе годный совет.
Возможно на 64-битных системах работа со временем более удобна и выше вероятность не набагать, но это не означает, что решением является переход на 64-битные системы. Такой шаг всего-лишь позволит упростить кодовую базу… что для работы со временем, безусловно, полезно… но всё же не необходимо.
Полезно, необходимо… Это практический совет.
Совершенно никакой разницы. Весь баг исключительно в неверно выбранном размере переменной. Вероятность так накосячить платформонезависима.
Размер выбирался исходя из кучи параметров, в том числе производительности систем того времени и удобства работы с такими данными… На тот момент — это был оправданный шаг, сейчас мы вынуждены думать о том, как это легаси обойти...
В основном исходя из размера и того,. что 640кб...
Производительность на счётчике секунд несущественна даже на машинах того времени, с удобством никаких проблем тоже нет.
На асм вместо add используем call add64 какой-нибудь, на С компилятор сам вполне способен подставить нужное. Арифметика с плавающей точкой так и работала (сопроцессоры тогда ещё не были мейнстримом). В зависимости от флагов или собирал нативный код или подменял на соответствующие вызовы эмулятора.
Ну и изначально речь была не об этом, а о том, что собственно разрядность процессора тут вообще никаким боком.
Производительность на счётчике секунд несущественна даже на машинах того времени, с удобством никаких проблем тоже нет.
На асм вместо add используем call add64 какой-нибудь, на С компилятор сам вполне способен подставить нужное. Арифметика с плавающей точкой так и работала (сопроцессоры тогда ещё не были мейнстримом). В зависимости от флагов или собирал нативный код или подменял на соответствующие вызовы эмулятора.
Ну и изначально речь была не об этом, а о том, что собственно разрядность процессора тут вообще никаким боком.
Тот факт, что они отличаются имеет мало отношения к типу процессора. Использование переменных недостаточной или платформозависимой размерности — проблема исключительно кривизны рук автора.
И тот факт, что для починки иногда достаточно перекомпиляции на другой платформе этого факта не отменяет совершенно. Тем более что на другой платформе всё точно так же внезапно и без предупреждения может сломаться. А ещё есть системные переменные, которые имеют размерность жестко заданную системой. И никакой процессор вас не спасёт если система понимает только 32-бит формат.
И да, повторюсь. Ни что не мешает использовать 64-битные переменные на 32-бит платформе. Ну вот вообще ни что. Кроме упомянутого выше фактора.
И тот факт, что для починки иногда достаточно перекомпиляции на другой платформе этого факта не отменяет совершенно. Тем более что на другой платформе всё точно так же внезапно и без предупреждения может сломаться. А ещё есть системные переменные, которые имеют размерность жестко заданную системой. И никакой процессор вас не спасёт если система понимает только 32-бит формат.
И да, повторюсь. Ни что не мешает использовать 64-битные переменные на 32-бит платформе. Ну вот вообще ни что. Кроме упомянутого выше фактора.
Почитал всю эту ветку комментов (14 на момент ответа). Объясните непрограммисту, почему время — это так сложно для всемогущих компьютеров?
Ну вообще время — довольно хитрый предмет и проблем с ним хватает. Тут была статься (вроде даже не одна) но не смог найти.
Однако в контексте данного треда сложность только одна. Исторически сложившийся общепринятый формат хранения времени, размерности которого скоро станет недостаточно для корректной работы. И именно хранения, (и обмена соответственно) а не расчёта. Собственно в статье есть пример аналогичной проблемы «2000 года», когда хранение только 2х цифр года вызвало ошибки при переполнении.
Ну и как обычно в таких ситуациях — проблема со старым софтом, который не в курсе, что счётчик надо бы расширить.
Однако в контексте данного треда сложность только одна. Исторически сложившийся общепринятый формат хранения времени, размерности которого скоро станет недостаточно для корректной работы. И именно хранения, (и обмена соответственно) а не расчёта. Собственно в статье есть пример аналогичной проблемы «2000 года», когда хранение только 2х цифр года вызвало ошибки при переполнении.
Ну и как обычно в таких ситуациях — проблема со старым софтом, который не в курсе, что счётчик надо бы расширить.
Sign up to leave a comment.
Истории о новогодних багах