А почему везде говорят, что наступление 19 января 2038 года приведёт к тому, что программы будут воспринимать текущее время как 1970 или 1901 год? В большинстве случаев, time_t — это signed int, а переполнение знаковых чисел, как известно, UB.

Здравствуйте, PlusMyTwitterFace, Вы писали:

PMT>переполнение знаковых чисел, как известно, UB.

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

Здравствуйте, niXman, Вы писали:

X>я не знаю что по этому поводу говорит стандарт, но я никогда не видел UB при переполнении знаковых чисел.
X>возможно, конечно, и существуют такие архитектуры, но я про них не в курсе..

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

Гипотетически, может выстрелить при оптимизации. Что-то вроде if(90000*90000 < 0)

Здравствуйте, PlusMyTwitterFace, Вы писали:

PMT> В большинстве случаев, time_t — это signed int

Это, вообще говоря, довольно странно. Стандарт C использует (time_t)(-1) как сигнальное значение:

7.23.2.3 The mktime function

3: The mktime function returns the specified calendar time encoded as a value of type time_t. If the calendar time cannot be represented, the function returns the value (time_t)(-1).

7.23.2.4 The time function

3: The time function returns the implementation’s best approximation to the current calendar time. The value (time_t)(-1) is returned if the calendar time is not available. If timer is not a null pointer, the return value is also assigned to the object it points to.

Получается, что в знаковом time_t представимы все времена от 1970-01-01T00:00:00Z и дальше (до переполнения), и времена до 1969-12-31T23:59:58Z включительно (и вниз до переполнения)*, а 1969-12-31T23:59:59Z непредставимо (поскольку совпадает с сигнальным значением). В беззнаковом же представим непрерывный диапазон времён от 1970-01-01T00:00:00Z до (time_t)(-2).

* Предполагаем two’s complement; в случае one’s complement или sign-and-magnitude появляется ещё значение -0, которое, впрочем, всё равно должно обозначать 1970-01-01T00:00:00Z.

Здравствуйте, PlusMyTwitterFace, Вы писали:

PMT>А почему везде говорят, что наступление 19 января 2038 года приведёт к тому, что программы будут воспринимать текущее время как 1970 или 1901 год?

Вообще-то к тому времени предполагается тотальное минимум 64 бита, а на таких платформах принят и time_t 64-битный (если unixtime, что тоже не 100%). Поэтому проблемы не будет.

PMT> В большинстве случаев, time_t — это signed int, а переполнение знаковых чисел, как известно, UB.

Это где такое "большинство случаев"? В родных для этого интерфейсах (Unix) это signed long. Ну а проблемы винды шерифа слабо волнуют.

Здравствуйте, PlusMyTwitterFace, Вы писали:

PMT>А почему
ты что спросить-то хотел?

Здравствуйте, netch80, Вы писали:

N>Ну а проблемы винды шерифа слабо волнуют.
Расскажешь это бухгалтерии, когда они тебе отрицательную зарплату насчитают.

Здравствуйте, Ops, Вы писали:

N>>Ну а проблемы винды шерифа слабо волнуют.
Ops>Расскажешь это бухгалтерии, когда они тебе отрицательную зарплату насчитают.

Не насчитают. До 2038 года сменится десяток поколений бухгалтерского софта. Сомневаюсь, что Windows доживёт в виде, хоть как-то похожим на нынешний.
Ну и мало кто там считает интервалы времени, насколько я знаю, через функции CRT.

Здравствуйте, niXman, Вы писали:

X>я не знаю что по этому поводу говорит стандарт, но я никогда не видел UB при переполнении знаковых чисел.
X>возможно, конечно, и существуют такие архитектуры, но я про них не в курсе..

На x86, если после арифметической операции встраивать команду INTO, будет исключение. Компилятор С++ ее не встраивает, но , например, Delphi это делает, если ее попросить.

Здравствуйте, niXman, Вы писали:

X>я не знаю что по этому поводу говорит стандарт, но я никогда не видел UB при переполнении знаковых чисел.
X>возможно, конечно, и существуют такие архитектуры, но я про них не в курсе..

Например http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33498

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>На x86, если после арифметической операции встраивать команду INTO, будет исключение. Компилятор С++ ее не встраивает, но , например, Delphi это делает, если ее попросить.
В С++ точно также можно компилятор попросить. В clang и gcc ключ -ftrapv. Правда используется не обязательно именно инструкция into (она вообще медленная, а на x86-64 её к тому же просто нет). Например, clang после арифметических операций делает jo на обработчик.

Здравствуйте, G65434-2, Вы писали:

X>>я не знаю что по этому поводу говорит стандарт, но я никогда не видел UB при переполнении знаковых чисел.
X>>возможно, конечно, и существуют такие архитектуры, но я про них не в курсе..

G2>Например http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33498

Это уже форменное свинство.
UB может в подобном случае относиться к тому, что получается в результате сложения, но ломать цикл? Независимо от того, насколько это верно по букве стандарта — по сути это маразм.

Здравствуйте, G65434-2, Вы писали:

G2>Здравствуйте, niXman, Вы писали:

X>>я не знаю что по этому поводу говорит стандарт, но я никогда не видел UB при переполнении знаковых чисел.
X>>возможно, конечно, и существуют такие архитектуры, но я про них не в курсе..

G2>Например http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33498

Там обсуждение даже интереснее самого примера. Хотя и пример интересен.