> Пример, говорю, приведи.С точки зрения элементарной логики: допустим ты хочешь считать интервалы без гимора.
Куда класть результат и с каким типом? По логике вещей разница времен - просится в time_t, потому что кто б его знает что еще на этой системе вместо time_t может время хранить без глюков (кто-то обещал какие-то соотношения размеров типов?). С знаковым time_t все просто: вычитаем одно из другого, результат тоже time_t. Знак - индикатор что было раньше, модуль - величина интервала. Но с unsigned это не катит, по сразу 2 причинам.
> В ядре, например, есть макросы типа:
> #define time_after(a,b) \
> (typecheck(unsigned long, a) && \
> typecheck(unsigned long, b) && \
> ((long)(b) - (long)(a) < 0))
Этот макрос может возвращать только 1 и 0. Проверять тип, когда проблема в самом определении типа - смысл? Это safety check что макрос не используют по левому. Даже если по такому макросу поменять операнды местами и вычитать из большего меньшее, чтобы избежать overflow - хорошо, мы получим "насколько удалены события". Но тогда надо где-то сбоку (ну не в unsigned time_t же?) надо хранить дополнительные сведения о том ЧТО было раньще. Это возможно, но там чуть ли не struct просится. Становится заметно сложнее. А если time_t знаковый, знак операции и несет описание что раньше. При том, поскольку времена отдаваемые системой больше ноля (что есть отрицательное "абсолютное" время?), результат вычитания должен помещаться в time_t, а знак - индикатор того что раньше.
Грубо говоря, signed time_t может хранить и ЧТО раньше и НАСКОЛЬКО именно. А unsigned - так не может. Потому что unsigned.
> и вроде бы в вечность никто ещё не ушёл.
Этот макрос вообще лишь говорит что было раньше. Это замечательно, только не о сохранении сразу и "что раньше" и "насколько именно". Сразу оба этих понятия можно и вроде бы технически валидно засунуть в signed time_t, но совершенно не катит c unsigned.
