C++26 표준 라이브러리 하드닝: 메모리 안전을 위한 새로운 표준
C++26: Standard Library Hardening Experiments
C++26은 표준 라이브러리에 '하드닝(hardening)' 개념을 도입하여, 벡터의 operator[]와 같은 검사되지 않은 연산에서 발생하던 정의되지 않은 동작(UB)을 계약 위반(contract violation)으로 전환합니다. 이 글은 P3471, P3697, P3878 제안서를 기반으로 하드닝의 핵심 아이디어, 적용 범위, 그리고 GCC, Clang, MSVC에서의 활성화 방법을 설명합니다. 또한 하드닝이 완전한 메모리 안전을 제공하지는 않지만, 일반적인 프로그래밍 오류를 탐지 가능한 종료 오류로 바꾸는 표준화된 기반을 제공한다는 점을 강조합니다.
C++26 하드닝은 C++를 갑자기 메모리 안전하게 만들지 않으며, sanitizer, 정적 분석, 좋은 API 설계, 또는 신중한 검증을 대체하지 않습니다. 대신, 몇 가지 일반적이고 위험한 표준 라이브러리 전제 조건 위반을 조용한 정의되지 않은 동작에서 탐지 가능하고 종료되는 실패로 바꾸는 표준화된 기준선을 제공합니다.
HN 토론
41- steveklabnik
이 모든 것에 대해 한 가지 궁금한 점은, 제가 알기로는 이 모든 것이 C++26에 포함된 것으로 알고 있는데, 아직도 https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p43... 같은 논문이 나오고 있다는 것입니다.
> C++26 초안은 아직 최종 투표를 거치지 않았습니다.
이 논문은 Bjarne이 공동 저자이므로, 확실히 사소한 거짓은 아닐 거라고 확신하지만, 어쩌면 제가 세부 사항을 놓치고 있는 것일 수도 있습니다. Bjarne이 이 문제로 C++26에 거부권을 행사하겠다고 위협했다는 것을 알고 있는데, 실제로 행사하지는 않았다고 생각했는데요.
이 절차를 저보다 조금 더 잘 아는 분이 계시면 맥락을 좀 알려주실 수 있나요?
- Cieric
마지막에 그에 대한 작은 힌트가 있지만, 저는 컴파일 시간 계약 어서션(contract assertion)이 더 보편화되기를 정말로 바랍니다. Spark, Dafny 같은 일부 언어들이 그런 일을 하고 0으로 나누기 같은 것에 대해 암시적 계약을 생성한다는 것을 알고 있습니다. 저는 이런 것들을 하는 나만의 커스텀 언어를 실험해 왔고, 매일 직장에서 C++로 돌아가는 것은 그 때문에 약간 실망스럽습니다.
- pama
30년 늦었지만, 그걸로 만족합니다. 계약(contract)은 예외보다 유용하고 덜 지저분해 보입니다.