# glibc 는 아직 Y2038 대응이 기본값이 아님

> Clean Markdown view of GeekNews topic #5645. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=5645](https://news.hada.io/topic?id=5645)
- GeekNews Markdown: [https://news.hada.io/topic/5645.md](https://news.hada.io/topic/5645.md)
- Type: news
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2021-12-30T10:19:02+09:00
- Updated: 2021-12-30T10:19:02+09:00
- Original source: [ariadne.space](https://ariadne.space/2021/12/29/glibc-is-still-not-y2038-compliant-by-default/)
- Points: 6
- Comments: 1

## Topic Body

- 2038-01-09 3:14:07 UTC가 지나면 32-bit time_t 가 오버플로우 됨

- 리눅스 커널은 몇년전에 내부적으로 64-bit로 교체했고, Alpine 은 3.13부터 64-bit time_t로 바꿨음

- GNU glibc 는 2.34부터 64-bit time_t를 지원하기 시작은 했지만, 접근 방식이 기술적으로 완전치 않음

- musl 이나 다른 UNIX C library 구현들은 새 코드에서 time_t가 항상 64-bit이고, 기존 32-bit 코드에 대한 호환성 스텁들이 제공

ㅤ→ 시간이 지나면서 자동으로 Y2038 호환이 되게 되어있음

- Microsoft 는 msvcrt 에서 한걸음 더 나아가 기본으로 64-bit time_t를 사용하고, _USE_32BIT_TIME_T 매크로를 쓰면 예전 32-bit 함수에 접근 가능

- GNU glibc 는 정확히 위 두가지의 반대 방식을 취함

ㅤ→ 명시적으로 -D_TIME_BITS=64 로 요청해야 사용 가능

ㅤ→ 언젠가는 이 기본값이 바뀔수도 있겠지만, 지금까지도 전혀 하지 않음

ㅤㅤ⇨ 비슷하게 2GiB 보다 큰 파일을 처리하는데 필요한 -D_FILE_OFFSET_BITS=64 는 아직도 명시해야함

ㅤ→ 또한 32비트 시스템에서는 -D_TIME_BITS=64 를 써서 빌드하면 안됨(즉 Y2038 호환이 불가능함)

## Comments



### Comment 8179

- Author: xguru
- Created: 2021-12-30T10:19:49+09:00
- Points: 1

아직 16년쯤 남았습니다만, 리눅스는 오래 교체 되지 않는 장비에도 많이 들어가는 터라..