C 문자열, 여전히 유효한 설계인가?

논의에서는 C의 널 종료 문자열(null-terminated strings) 방식이 문자열 길이를 파악하기 위해 `strlen`과 같은 함수를 반복 호출하게 만들어 성능 저하(Performance Degradation)를 야기한다고 지적한다. 또한, 버퍼 오버플로우(Buffer Overflow)와 같은 메모리 관련 버그(Memory-related Bugs)의 주요 원인으로 꼽으며, `snprintf` 함수의 반환 값 모호성 등 API 일관성 부족(Lack of API Consistency)이 개발자 혼란을 가중시킨다고 비판한다.

길이 기반 문자열(length-based strings)은 `struct String { u8* data; u64 size; }`와 같이 포인터와 크기 정보를 함께 저장하여 문자열 길이를 O(1) 시간에 파악할 수 있다. 이는 효율적인 부분 문자열(Efficient Substrings) 생성, 바이너리 데이터 처리(Binary Data Handling) 용이성, 그리고 널 바이트(Null Byte) 처리의 명확성 등 여러 이점을 제공한다고 설명한다. 특히, 문자열 슬라이싱(String Slicing) 시 별도의 메모리 할당 없이 원본 데이터를 참조하여 메모리 관리 부담(Memory Management Overhead)을 줄일 수 있다는 점이 강조된다.

커뮤니티에서는 C 언어가 최소주의(Minimalism)와 하드웨어 직접 제어(Direct Hardware Control)를 목표로 설계되었음을 강조한다. K&R 서적을 인용하며, C는 복합 객체 직접 조작 대신 함수 호출을 통한 추상화를 제공하며, 이는 언어의 간결성(Language Simplicity)과 학습 용이성(Learnability)을 높이는 설계 철학의 일부라고 설명한다. 따라서 널 종료 문자열 역시 당시의 메모리 제약(Memory Constraints) 하에서 합리적인 선택이었다는 의견이 제시된다.

댓글에서는 `struct String { u64 size; u8* data; }`와 같이 구조체 멤버 순서 변경을 통한 패딩(Padding) 최소화, 또는 `uint8_t tag`를 사용하여 가변 길이(Variable Length)를 효율적으로 저장하는 방식 등 실제 구현에서의 최적화 방안이 논의되었다. 또한, Redis의 SDS(Simple Dynamic Strings) 라이브러리나 Rust의 `std::string_view`와 같이 데이터 격리 아키텍처(Data Isolation Architecture)를 적용한 사례가 언급되며, C 문자열의 한계를 극복하려는 다양한 시도가 있음을 보여준다.

일부 개발자들은 '문자열'이라는 개념 자체가 지나치게 광범위하며, 인코딩(Encoding), 길이 정의(Definition of Length)(바이트, 코드 포인트, 그라핌 클러스터 등), 가변성(Mutability) 등 다양한 의미론적 모호성을 내포한다고 지적한다. Rust와 같이 타입 시스템(Type System)을 통해 이러한 정보를 명시적으로 인코딩하는 것이 근본적인 해결책이 될 수 있다는 의견이 제시되었으며, 이는 AI 환각(Hallucination)과 같은 문제를 줄이는 데도 기여할 수 있다고 본다.