그래서 제가 올리겠습니다.
설레발 멈춰…?
19쪽 분량의 이 새로운 보고서에서는 메모리 안전 취약점이 있는 프로그래밍 언어의 두 가지 예로 C와 C++를 제시했다. 안전하다고 판단되는 프로그래밍 언어의 예로는 러스트를 언급했다. 참고로 2022년 11월에 발표된 NSA 사이버 보안 정보 시트는 메모리 안전성을 고려한 프로그래밍 언어로 러스트와 함께 C#, 고, 자바, 루비, 스위프트를 명시한 바 있다.
8개의 좋아요
생각해볼 여지가 많은 부분인 것 같습니다. 개인적으로는 C와 C++이 문제가 있다는 것보다는, 안전한 런타임 환경에서 실행되는 코드를 만들 수 있도록 환경을 개선해야 한다는 것이 좀 더 적절한 접근이 아닌가라고 생각합니다.
가령 이전과 동일한 C/C++ 코드라고 하더라도, 네이티브 기계어로 컴파일된 결과물을 실행하는 것이 아니라, 웹 어셈블리 같은 샌드박스 환경 위에서 실행될 수 있도록 코드를 만든다던가 하는 접근법이 필요하지 않을까 하고요! 메모리 안정성을 보장한다는 다른 언어들 역시 결국은 어떤 형태로든 샌드박스 위에서 실행되는 것이라고 볼 수 있는 것 같습니다. 
참고로 C/C++ 코드를 WASM으로 컴파일하는 것은 이미 잘 알려진 구현체가 있습니다. (Emscripten) – C/C++ 모듈을 웹어셈블리로 컴파일하기 - 웹어셈블리 | MDN
5개의 좋아요
자바천국 대한민국 에서는 그다지 중허지 않은 뉴스 인가 봅니다.
2개의 좋아요
지속적으로 C++로 개발을 하고 있는 사람으로서 얘기를 하자면
적어도 Visual Studio 2022 에서는 오류 가능성이 있는 코드들이 있으면 매우 거슬립니다.
빌드시에 뜨는 경고도 많지만 IDE자체에서도 녹색 밑줄이 한가득 보입니다.
여기서 이제 더 짜증이 나는 건 C++은 Ctrl+. 리팩토링이 거의 안 먹는다는 거죠.
거기다 한 술 더 떠서 가이드라인 안내가 뜨는데. 명확하게 어떻게 수정하라는 안내도 없이 경고로 뜹니다.
찾다보니 gsl이란놈을 받아서 추가하고 수정해야 하는데. 이거 엄청 짜증 나더라고요.
여하튼 결론은 기존과 다른 귀찮음을 감수하고 그냥 알려주는 것만 전부 수정해도 에러 확률이 80%는 줄어들 것으로 예상합니다.
가장 많이 나오는 것 몇 가지만 적자면
class 기본 생성자 5가지 정도가 안보일 뿐 생성되는데.
만들든 삭제하든 하라고 나옵니다.
new 쓰지 말고 shared_ptr이나 unique_ptr 쓰라고 나옵니다.
예외 처리가 필요 없는 함수는 전부 noexcept 선언하라고 나옵니다.
변수 선언 후 변경이 없다면 const 선언 하라고 나옵니다.(리턴값 저장)
unsigned char 배열 생성 후 memcpy 시 보통 변수를 그냥 넣는데.
&name[0] 쓰라고 뜹니다.
std::vector 사용 시 배열 형태로 사용하지 말라고 뜹니다. (ex : name[n])
C스타일 캐스팅하지 말고 reinterpret_cast쓰지 말라고 뜹니다.
reinterpret_cast로 포인터를 캐스팅 했을 시 해결 방법 찾아보니 메모리 할당해서 복사하라는군요. ㅎㅎ
꼭 써야 하는 경우엔 [[gsl::suppress(type.1)]] 이런 걸 써 줘야 합니다.
2개의 좋아요
뭐 닷넷만 우대해준것도 아니고 크게 틀린말도 아니고 주목할점이라면은 미국 백악관에서 뱉은말이라는건데 아무리 백악관이라 한들 자기네들이 뭔데?? 알아서 할건데??? 싶습니다. 딱히 반가울 필요없는 걍 뜬금없는 소식이었어서 넘겼네요 저는
1개의 좋아요
개발자의 갑이 될 고객사 입장에서는 백악관의 권고 덕분에 “앞으로 프로젝트는 무조건 러스트로 고고~” 할테고, 그래도 우기고 C/C++로 만들었다가 문제가 생기면 책임 소재 때문에라도 러스트로 할 가능성이 크죠.
물론 러스트 개발자가 거의 없어서 힘들겠지만…