y10k - ¿Solución del año 2038 para Linux embebido(32 bit)?
y2k38 64 bits (3)
Las rutinas de conversión de tiempo "simplemente" tendrían que usar 2038-01-19: 03: 14: 07Z como base para el tiempo de Unix Epoch si la marca de tiempo está por debajo de un cierto valor.
Es decir, si su sistema se vuelve productivo en el 2010-01-01, puede asumir que ninguna marca de tiempo, que no se haya desbordado, está por debajo de 1262300400 (que es el tiempo de la época de Unix para esa fecha).
Si se encuentra una marca de tiempo inferior, considere que se ha desbordado y use 2038-01-19: 03: 14: 07Z como tiempo base. Las comparaciones también deben tenerse en cuenta.
No es una solución limpia, pero se puede hacer con un esfuerzo moderado. Mejor cambie a las marcas de tiempo de 64 bits (que no necesitan absolutamente un sistema de 64 bits, por cierto).
Esta pregunta ya tiene una respuesta aquí:
- ¿Qué debemos hacer para prepararnos para 2038? 10 respuestas
¿Cuál es la manera correcta de manejar los tiempos en el código C para Linux incorporado de 32 bits (ARMLinux) para garantizar que el código continúe funcionando correctamente después de las 03:14:07 UTC del 19 de enero de 2038 (cuando un tiempo firmado de 32 bits se desborda) ? Dado que time_t está firmado con 32 bits en el sistema que debo usar, ¿cuáles son las alternativas?
Una cantidad considerable de googlear no ha descubierto nada de uso práctico. Todo el mundo parece suponer que para entonces todos estaremos utilizando sistemas operativos de 64 bits, pero esto no es cierto en el caso de los sistemas integrados.
En el sistema que debo usar, __kernel_time_t se define como un long . Lo que presumiblemente significa que no hay una instalación del núcleo para el tiempo de 64 bits. La versión de uClibc es 0.9.29.
No puedo creer que yo sea el único con este problema, y no quiero reinventar la rueda.
No hay balas de plata, trucos o soluciones inteligentes. Utilice un sistema operativo que tenga 64 bit time_t o no use time_t y cualquier sistema operativo que dependa de él (que incluya sistemas de archivos, temporizadores, la mitad de la red y otros) o planee actualizar el software en los próximos 20 años.
Hay al menos dos sistemas similares a Unix con 64 bit time_t en máquinas de 32 bits: OpenBSD y NetBSD. OpenBSD tuvo algunas charlas explicando el razonamiento detrás de esto: http://www.openbsd.org/papers/eurobsdcon_2013_time_t/index.html
Supongo que el ABI de su sistema integrado define hasta 32 bits.
No hay ningún requisito para que el tipo time_t esté firmado. ¿Podrías posiblemente dejarlo unsigned long y comprarte a ti ya tus descendientes 68 años adicionales de tranquilidad? Cambiar esto requeriría volver a compilar el kernel, la biblioteca C y todos los programas y bibliotecas que usan time_t ... ¡no para los más débiles de corazón! Puede que también lo defina por long long , pero esto cambiaría muchos diseños de estructura y es aún más desafiante.