glibc n’active toujours pas la prise en charge de Y2038 par défaut

• Après le 2038-01-09 3:14:07 UTC, time_t sur 32 bits déborde

• Le noyau Linux est passé en interne au 64 bits il y a quelques années, et Alpine est passé à time_t sur 64 bits à partir de la 3.13

• GNU glibc a commencé à prendre en charge time_t sur 64 bits à partir de la 2.34, mais son approche n’est pas techniquement aboutie

• musl et d’autres implémentations de bibliothèque C UNIX utilisent toujours un time_t sur 64 bits pour le nouveau code, avec des stubs de compatibilité fournis pour l’ancien code 32 bits

→ cela permet une compatibilité Y2038 automatique avec le temps

• Microsoft va plus loin avec msvcrt en utilisant time_t sur 64 bits par défaut, tout en permettant l’accès aux anciennes fonctions 32 bits via la macro _USE_32BIT_TIME_T

• GNU glibc adopte exactement l’approche inverse des deux cas ci-dessus

→ il faut en faire explicitement la demande avec -D_TIME_BITS=64

→ cette valeur par défaut changera peut-être un jour, mais cela n’a toujours pas été fait à ce jour

⇨ de la même façon, il faut toujours préciser -D_FILE_OFFSET_BITS=64, nécessaire pour traiter des fichiers de plus de 2 GiB

→ de plus, sur les systèmes 32 bits, il ne faut pas compiler avec -D_TIME_BITS=64 (autrement dit, la compatibilité Y2038 est impossible)

[xguru]

Il reste encore environ 16 ans, mais Linux est aussi beaucoup utilisé dans des équipements qui ne sont pas remplacés avant longtemps…