Habr[Перевод] Риски перехода на 64-битный time_t
Один из разделов статьи Overview of cross-architecture portability problems я посвятил проблемам, возникающим из-за использования 32-битного типа time_t. Это архитектурное решение, до сих пор влияющее на использующие glibc системы с Gentoo, приведут к тому, что у 32-битных приложений в 2038 году начнут возникать ужасные сбои: они будут получать ошибку -1 вместо текущего времени и не смогут выполнять stat() файлов. Одним словом, возникнет полный хаос. Считается, что решением будет переход на 64-битный тип time_t. Musl уже перешёл на него, а glibc поддерживает его как опцию. Многие другие дистрибутивы, например, Debian, совершили этот переход. К сожалению, дистрибутивам на основе исходников, например, Gentoo, сделать это не так просто. Поэтому мы по-прежнему обсуждаем эту проблему и экспериментируем, пытаясь понять, как пользователи максимально безопасно могли бы выполнить апгрейд. К сожалению, это совершенно нетривиально. Во-первых, мы говорим о переломном изменении ABI — ситуация «всё ли ничего». Если в API библиотеки используется time_t, то всё связанное с ней должно использовать ту же ширину типа. В этом посте я бы хотел подробно рассмотреть этот вопрос: почему это плохо и что мы можем сделать, чтобы повысить безопасность.
