Есть ли преимущество в использовании unsigned long для временных членов?

Question

Я заметил, что некоторые программисты используют unsigned long для tv_sec и tv_usec [когда они копируют их или оперируют с ними] timeval, когда они определены как просто long.

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

Answer 1

Использование long int для этих переменных будет работать до года 2038 , и после этого tv_sec будет переполнено на машинах, где long равно 4 байта.

timeval должен быть определен как:

The <sys/time.h> header shall define the timeval structure that includes at least the following members:

time_t         tv_sec      Seconds. 
suseconds_t    tv_usec     Microseconds. 

Вы должны заметить, что вместо long используется тип time_t, но это также 32-битное представлениев некоторых системах, хотя есть даже 64-битные представления в других системах.Чтобы избежать переполнения, time_t, вероятно, изменится на 32-разрядное целое число без знака или 64-разрядное.

Именно поэтому некоторые используют unsigned long, поскольку оно остановит переполнение до 2100+ года.Вместо этого вы должны использовать тип time_t, и вам не нужно будет думать о том, как долго ваша программа будет работать в будущем.

Answer 2

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

Что касается микросекунд, если вы вычесть два значения, вы можете перейти в отрицательные числа со знаком и в 4 + миллиарды без знака. Сравнение с 0 кажется более интуитивным.

Answer 3

tv_sec имеет тип time_t.tv_usec имеет тип long и должен быть подписан, потому что вы (в среднем 50% времени) получите отрицательные результаты в tv_usec при вычитании значений timeval для вычисления интервала времени, и вам придетсяопределите это и конвертируйте в заимствование из поля tv_sec.Стандарт (POSIX) мог бы вместо этого сделать тип без знака и потребовать от вас заранее определить обтекание, но этого не произошло, вероятно, потому что это будет сложнее использовать и противоречит существующей практике.

Также нетпричина, по диапазону, для tv_usec, чтобы быть беззнаковым, так как максимальный диапазон, который он действительно должен представлять, составляет от -999999 до 1999998 (или несколько раз, если вы хотите накопить несколько сложений / вычитаний перед перенормировкой).