Исходное сообщение
"Для избавления Glibc от проблемы 2038 года предложено прекра..." Отправлено crypt, 06-Мрт-23 12:56
было приятно узнать, что FreeBSD лишена проблемы by design. FreeBSD and macOS both support utmpx only, not traditional utmp. But they do support 64-bit timestamps at least on 64-bit architectures, because the ut_tv field of struct utmpx is a struct timeval, which on these systems uses 64-bit or 32-bit timestamps depending on the architecture. FreeBSD has a semi-traditional implementation of getutxent that reads a file, but the on-disk format is a separate struct that their libc manually converts to struct utmpx, so it doesn't matter that struct utmpx is different between 32-bit and 64-bit programs. (This is in contrast to glibc where struct utmp, struct utmpx, and the on-disk format are all identical.)

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	> было приятно узнать, что FreeBSD лишена проблемы by design. > FreeBSD and macOS both support utmpx only, not traditional utmp. But they > do support 64-bit timestamps at least on 64-bit architectures, because the > ut_tv field of struct utmpx is a struct timeval, which on > these systems uses 64-bit or 32-bit timestamps depending on the architecture. > FreeBSD has a semi-traditional implementation of getutxent that reads a file, > but the on-disk format is a separate struct that their libc > manually converts to struct utmpx, so it doesn't matter that struct > utmpx is different between 32-bit and 64-bit programs. (This is in > contrast to glibc where struct utmp, struct utmpx, and the on-disk > format are all identical.)
	Введите код, изображенный на картинке: