리눅스 커널, 6년·360개 넘는 패치 끝에 strncpy 제거

• 리눅스 커널이 드디어 strncpy API를 제거함

  • 이 작업은 Linux 7.2에 들어갈 예정이고, 마지막 per-CPU 아키텍처별 strncpy 구현까지 제거됐다고 함
  • 걸린 시간은 6년, 관련 커밋은 약 362개 이상임. C API 하나 없애는 데 이 정도가 든다는 게 커널 스케일임

• strncpy가 문제였던 이유는 이름과 실제 동작이 개발자 기대를 자주 배신했기 때문임

  • NUL termination 주변 의미가 직관적이지 않아서 버그의 지속적인 원인으로 지목돼 왔음
  • destination을 불필요하게 zero-fill하는 동작 때문에 성능 면에서도 손해가 있었음

• 대체 API는 복사 목적에 따라 나뉨

  • NUL로 끝나는 destination에는 strscpy() 사용
  • NUL 종료와 zero-padding이 모두 필요한 경우엔 strscpy_pad() 사용
  • NUL 종료가 아닌 고정 폭 필드에는 strtomem_pad() 사용
  • 명시적 padding이 있는 bounded copy에는 memcpy_and_pad() 사용
  • 길이를 이미 알고 있는 메모리 복사는 그냥 memcpy() 사용

• 흥미로운 포인트는 ‘하나의 범용 함수’ 대신 의도를 드러내는 API 여러 개로 쪼갰다는 점임

  • 문자열인지, 고정 폭 메모리 필드인지, padding이 필요한지에 따라 호출자가 선택하게 만듦
  • 리뷰어 입장에서도 “이 복사가 NUL 종료를 기대하는가?”를 코드에서 바로 읽을 수 있음

---

기술 맥락

• 리눅스 커널이 한 선택은 strncpy를 더 조심해서 쓰자는 게 아니라 아예 제거하는 쪽이에요. 왜냐하면 이 함수는 이름만 보면 안전한 문자열 복사처럼 보이지만, 실제 NUL 종료 규칙이 헷갈려서 리뷰로 계속 잡아내기 어렵거든요.

• 대체 API를 여러 개 둔 이유는 복사의 의도를 타입처럼 드러내기 위해서예요. NUL 종료 문자열이면 strscpy, zero-padding까지 필요하면 strscpy_pad, 고정 폭 필드면 strtomem_pad처럼 목적별로 갈라야 실수가 줄어요.

• 6년과 362개 커밋이라는 숫자는 레거시 API 제거가 얼마나 현실적인 비용을 먹는지 보여줘요. 특히 커널처럼 아키텍처별 구현과 오래된 호출부가 많은 코드베이스에서는 ‘나쁜 API 금지’보다 ‘모든 사용처를 안전하게 바꾸는 작업’이 진짜 본게임이에요.