Efecto 2038: El nuevo "Efecto 2000"

Hay nueva fecha para el colapso de muchos dispositivos electrónicos y sistemas informáticos y será, según muchos expertos en la materia, cuando pasen 7 segundos de las 3:14 de la madrugada del martes 19 de enero del 2038. Resulta que el sistema tradicional de los sistemas operativos estableció el 1 de enero de 1970 como el momento en el que empezar la cuenta del calendario y desde ese momento del inicio de los tiempos (informáticos) hasta la fatídica fecha del 2038 habrán pasado justo 2.147.483.647 segundos.

[#1 superjavisoft]

Me veo, gritando en la nochevieja:

- Efecto 2038! Efecto 2038!...

Que recuerdos de adolescente, gritando la gente Efecto 2000.

[#2 qasax]

#1 Jajajaja ya somos dos

[#4 Peachembela]

entonces tendremos todos los computadores apagados el 19 de enero de 2038 y los encenderemos al día siguiente para que así no nos pase nada.

[#6 qasax]

#3 Imagino que el mismo que en los GPS, asique serán los "segundos oficiales". ¡Supongo!

[#7 qasax]

#4 ¡El error seguiría ahí! Estaríamos en el 1901 sólo que un día mas tarde.

[#8 Serorum]

¿Cómo tuvieron ese error?

[#9 GanaderiaCuantica]

Habrá corralito. Caerán todos los sistemas de los bancos con Cobol

[#10 Ed_Hunter]

Como parece que para entonces ya habremos migrado todos a sistemas de 64 bits, con lo que no habría problemas hasta dentro de unos 292 mil millones de años.

Por otra parte Linus ya ha parcheado la versión de 32 bits de Linux para retrasar el problema tanto como en los sistemas de 64 bits, por lo que actualizando el kernel ya tienes arreglado el efecto 2038.

[#11 x.y.z]

#0 spam www.meneame.net/user/qasax/history

[#12 pozoliu]

Recordemos ese gran momento Simpson www.youtube.com/watch?v=Vwvix4ahHEk

[#13 chavi]

#5 Porque muchos programadores son así....

[#14 box3d]

Estoy acojonado con la cantidad de veces que he visto castear El timestamp Unix a "int" y, a pesar de los warnings, dejarlo ahí y pa cliente.

Nota: int "a secas" es de 32bit en la mayoría de plataformas de 32/64 bit

[#15 PauMarí]

#13 #5 porque muchos simplemente trabajan de programadores, no són programadores...

[#16 --193513--]

Buen, ya mismo tendremos que enviar a John Titor a los 70 a por una maquina de ibm

[#17 kucho]

#8 crear algo en informatica y que dure 70 años... tu me diras...

[#18 xizor]

#9 pues precisamente los de Cobol no van a fallar.

[#19 squanchy]

#10 ¿Y javascript? Lo mismo para esa fecha tienen un objeto Date que sirva para algo y puedo dejar de usar la librería moment.

[#20 --8899--]

#10 En realidad no es tan sencillo: no puedes hacer que una llamada a sistema que antes devolvía un entero de 32 bits pase, de golpe, a devolver uno de 64 bits sin que rompan todas las aplicaciones que lo usan, por lo que lo que se ha hecho es añadir una nueva llamada que es la que devuelve el valor de 64 bits. Esto significa que las aplicaciones que llamen a la función vieja fallarán en 2038, por mucho que hayas actualizado el kernel.

Afortunadamente, tal y como está hecho, en general es suficiente con recompilar el código, sin tener que tocar nada.

[#21 --8899--]

#14 Y, sin embargo, en mi opinión, "int" debería siempre coincidir en tamaño con el puntero, de manera que poniendo "int" a secas puedas hacer siempre operaciones con punteros sin riesgo, y sólo usando short int, long int y long long int especificar un tamaño concreto.

[#22 GanaderiaCuantica]

#18 Y me lo creo. Es más, dudo que falle algo en 2038. Pero tenía que hacer el chiste. Muchas horas sin leer una crítica a Cobol.

[#23 mmcnet]

#20 Eso de recompilar sin tener que tocar nada .... Un programa que usa enteros de 32 bits para guardar la hora tiene que cambiar la definición de tipos y revisar muchas cosas (cambia el tamaño de variables, estructuras, arrays ).. no es tan sencillo.

[#24 xizor]

#22 pues casi todo lo que esté en C/C++ sobre Unix fallará. Y probablemente lo de Java también, pero eso lo digo con la boca pequeña porque aunque el tipo de Java para las fechas si aguanta más años no estoy seguro de dónde saca el valor, que si es del sistema operativo y este es Unix, pues también fallará. Y aunque se parchee, hay mucha base de datos y mucho fichero que en sus campos tiene la fecha en segundos desde el 1970, así que....

[#25 --8899--]

#23 Claro, pero se supone que tendría que utilizar un tipo "time_t" (que es el definido dentro de la estructura timeval), el cual será de 32 o 64 bits según sea necesario. Ese tipo, si no me equivoco, ya existía antes, y era equivalente a un int "a secas", pero en las nuevas versiones se redefine a un int de 64 bits. Si luego el programador almacena un time_t en un int "porque es lo mismo", ahí ya es un error del programador.

[#26 box3d]

#21
Castear `void*` a `int` es pecado.
Utiliza `uintN_t` Como debe ser.

[#27 --8899--]

#26 Y, hasta donde se, hacer

void *loquesea = 40;

también lo es... Así que ya me dirás como lo hacemos si quiero hacer operaciones con punteros. Obviamente el puntero base será siempre un puntero concreto, pero el valor a sumar tiene que ir en un int o tipo similar.

Edito: acabo de probar, y como suponía, no se pueden sumar dos punteros. Luego NECESITAS usar un tipo entero para operaciones con punteros, y por eso es lógico que haya uno cuyo tamaño coincida con el de un puntero.

[#28 box3d]

#27
`(void*) + int` no se puede, tienes que darle tipo, por ejemplo `(uint8_t*) + int` es válido.

Y como `void*` acepta cualquier puntero, puedes hacer aritmética sin animaladas de puntero-a-int.

void* p = 0xDEADBEEF;
p = ((uint8_t*)p) + 1;
//^Cast de puntero-a-puntero es seguro

Y "de gratis" te permite incrementar con bytes, words, dwords o qwords cambiando el tipo del cast por 8,16,32,64..

[#29 --8899--]

#28 Ay por dios...

Pero vamos a ver... es que eso NO es de lo que hablaba al principio. No se trata de sumar algo a un void, sino de qué usar para sumar algo a un puntero, o para recorrer un bloque. Si, por ejemplo, quiero recorrer un bloque de memoria byte a byte, teniendo un puntero a char, necesito utilizar una variable de tipo entero (sea del tamaño que sea) para llevar la cuenta, o para sumarle directamente (si, por ejemplo, quiero hacer acceso aleatorio en base a algún parámetro dentro del bloque de memoria). Esa variable debería tener, al menos, el mismo tamaño que un puntero (32 bits en un sistema de 32 bits, 64 bits en un sistema de 64 bits) para estar seguro de que siempre podré recorrer todo el bloque de memoria sea cual sea su tamaño. Ese es el problema. Por eso decía que tendría sentido que "int" (a secas) tuviese un tamaño dependiente de la arquitectura: porque así se podría usar ese tipo para esta clase de variables, y luego utilizar intXX_t o uintXX_t para cuando necesites un tamaño concreto.

¿Me he explicado por fin?

EDITO: en la práctica, para eso está el tipo size_t. Es a lo que me refería: un tipo para esta clase de operaciones. Pero en mi opinión debería poder hacerse con uno de los tipos estándar.

[#30 mmcnet]

#25 La clave está en el "se supone". Yo he visto de todo.

Por otro lado, piensa en un programa que tenga bastante tiempo, que se tenga que compilar contra librerías antiguas que no tengan versión de 64 bits, bien por que ya no se mantienen, o porque hubo un salto de versión sin compatibilidad hacia atrás.

Hay muchos casos en los que podría haber peoblemas, y si el programa es grande, hay que revisarlo y hacer todas las pruebas (de sistema, como mínimo), para poder confiar en el, aunque esté todo bien.

[#31 box3d]

#29 en industrias donde puede morir gente, usar un "tipo estandard" està prohibidísimo. Precisamente para evitar cosas como los comportamientos no definidos o comportamientos definidos por la implementación. Si quieres que El software sea portable has de hacer lo mismo.

Además, no necesitas una variable de x tamaño para recorrer datos via puntero, tan solo necesitas saber el tamaño máximo a leer (otro requisito de software crítico) así que si vas a leer un máximo de +/- 32K, hasta un int16 te arregla hasta en una arquitectura de 64b