times () системный вызов.Переполненное возвращаемое значение - PullRequest
0 голосов
/ 05 февраля 2019

Какое значение будет возвращено, если возможный диапазон clock_t (он же со знаком) будет переполнен?

Давайте предположим, что я использую версию ядра 2.6, а arch равен x86 (32 бита).sizeof (длинный подпись) = 4 байта.Максимальное значение = 2147483647.

В соответствии с man-страницей - здесь , системный вызов times () возвращает количество тактов, прошедших с произвольной точки в прошлом.

В разделе «Примечания» упоминается следующее: «В Linux« произвольная точка в прошлом », из которой измеряется возвращаемое значение times (), изменялась в зависимости отверсии ядра. Начиная с Linux 2.6, эта точка (2 ^ 32 / Гц) - за 300 секунд до времени загрузки системы ".

Итак, я не понимаю, какое значение в десятичном представлении будет начинатьсяточка (предположим, HZ = 100).И какое возвращаемое значение будет после переполнения.

1 Ответ

0 голосов
/ 05 февраля 2019

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

times () возвращает количество тактов, прошедших с тех порпроизвольная точка в прошлом.Возвращаемое значение может выходить за пределы возможного диапазона типа clock_t.В случае ошибки (clock_t) -1 возвращается, и значение errno устанавливается соответствующим образом.

, поэтому он может переполниться, да, и когда это произойдет, он перейдет с + 2 147 483 647 на −2 147 483 647 , если возвращаемое значение равно без знака long и продолжают тикать в положительном направлении.Однако целые числа со знаком не определены после переполнения, это связано с тем, что компиляторы обрабатывают их по-разному для оптимизации, здесь .

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...