Hacker News 의견

• F-35의 C++ 코딩 표준 문서가 여기에 있음
  142페이지짜리로, 실제 항공기 소프트웨어 개발에서 어떤 제약이 있는지 볼 수 있음
  • 몇 장 훑어봤는데 꽤 합리적인 규칙들로 보임
    다만 “shall” 규칙의 예외가 궁금함. 이런 대규모 프로젝트에서는 예외 케이스가 표준의 실효성을 보여줌
  • 실시간 시스템에서는 운영 중 동적 메모리 할당 금지 규칙이 있음
    2005년 당시에는 괜찮았겠지만, 요즘 AI 기반 드론 같은 환경에서는 어떻게 적용될지 궁금함
  • 이런 규칙을 정적 분석 도구로 강제하는지, 아니면 개발자들이 직접 숙지해야 하는지 궁금함
  • 임베디드나 저사양 기기용 소프트웨어에도 이런 규칙이 유효한지 고민됨
    특히 stdio.h 금지 같은 부분은 낯설지만, 읽다 보면 “그래, 맞는 말이네” 싶음
  • 이 문서를 처음 봤을 때, 누군가가 “Arduino Uno용 C++도 여전히 C++이다”는 예시로 들었음
• 실제 MISRA 코드에서 본 적 있는 a = a; 같은 구문이 떠오름
  사용되지 않는 파라미터를 제거하지 않기 위한 꼼수인데, 이런 규칙이 좋은 코드 품질을 보장하는지는 의문임
  • MISRA 관련 연구를 보면 일부 규칙은 결함을 줄이지만, 일부는 오히려 결함을 늘림
    JSF 가이드라인은 2005년 문서라 시대적 한계가 있음
    Bjarne Stroustrup이 최근 “C++ 프로파일” 개념을 제시한 것도 흥미로움
    결국 이런 스타일 가이드는 미적 취향의 문제일 수도 있음
  • C에서는 변수를 참조만 할 때 (void)a;로 처리하는 게 표준적인 방식임
  • 실제로 안전 필수 코드를 많이 작성해봤는데, 코딩 규칙이 전체 품질을 떨어뜨리는 경우도 많았음
    진짜 안전을 보장하는 건 설계 품질과 페일세이프 구조임
  • Zig에서는 _ = a;로 명시적으로 처리함
    관련 이슈도 있음
  • 이런 표준은 코드 리뷰를 대체하지 않음
    오히려 리뷰 시 참고할 공통 기준을 제공하는 역할임
• 위성 소프트웨어도 비슷하게 STL 사용이 금지되어 있음
  핵심은 미션 보증(mission assurance) 임
  스택이나 힙을 쓰면 변수의 메모리 주소가 바뀌는데, 특정 셀이 고장 나면 문제가 생김
  모든 변수가 고정 주소를 가지면, 고장난 셀만 패치로 옮겨서 임무를 계속할 수 있음
  • 하지만 C++에서 스택을 완전히 안 쓰는 건 불가능함
    지역 변수, 매개변수, 반환 주소 등은 결국 스택에 필요함
    재귀도 불가능해지고, 임시 변수도 제한됨
    그래서 이 주장은 현실적이지 않음
  • 이런 수동적 접근보다는 ECC 메모리나 Reed-Solomon 코딩 같은 자동화된 방법이 더 효율적임
  • 그렇다면 변수는 전역으로 두는 건가? 그리고 메모리 셀 오류 감지는 어떻게 하는지 궁금함
  • 실제로는 스택을 사용함. 힙은 제한되지만 메모리 풀을 사용함
    스택과 힙의 주소 범위를 고정할 수는 있지만, 이게 설득력 있는 이유인지는 의문임
  • 그렇다면 함수의 in/out 파라미터는 어떻게 처리하는지도 궁금함
• “모든 if, else if에는 반드시 else나 주석이 있어야 한다”는 규칙이 있음
  나도 비슷하게 “이 경우는 절대 발생하지 않아야 함” 같은 로그를 남김
  대규모 시스템에서는 이런 예외 상황 로깅이 디버깅에 매우 유용함
  • Rust의 match 문이 이런 점에서 좋음
    모든 경우를 명시적으로 처리해야 해서, enum 값이 추가되면 컴파일러가 경고해줌
  • 나는 여기에 _STOP이나 _CRASH 매크로를 추가해서 즉시 디버그 중단시키기도 함
    문제를 바로 수정하도록 강제하는 효과가 있음
• Ada 대신 C++을 선택한 이유를 설명한 엔지니어링 리드의 글이 있음
  요약하면 “Ada 개발자와 툴체인이 부족했다”는 이유였음
  하지만 지금은 언어 다양성에 대한 개방성이 커져서 Ada가 더 받아들여질 수 있을 것 같음
  NVidia가 SPARK를 채택한 것도 Ada의 부활 조짐으로 보임
  • “Ada 개발자가 부족하다”는 논리는 싫어함
    DoD가 Ada를 강제했다면, 대학과 기업이 따라왔을 것임
    결국 언어 학습은 가능하고, Ada를 썼다면 F-35의 신뢰성도 더 높았을 것임
  • 지금도 Ada 컴파일러를 파는 업체가 7곳이나 있음
    AdaCore, GHS, PTC ApexAda, DDC-I, Irvine, OC Systems, RR Software 등임
    과거에는 Ada 컴파일러가 유료 옵션이었고, C/C++은 기본 제공이라 학교나 기업이 C++을 택했음
    AdaCore가 ISO 표준화와 오픈소스 확산에 큰 기여를 했음
  • 나도 Ada가 다시 부흥하길 바람
    예전엔 과도하게 비판받았지만, 지금은 오히려 매력적으로 느껴짐
  • 하지만 실제로 Ada를 써보니 문법이 마음에 들지 않았음
    파일 구조나 빌드 플래그가 복잡했고, RedMonk 언어 순위에도 Ada가 없었음
    일부 기능은 흥미로웠지만, Rust처럼 현대적인 언어 경험은 아니었음
• 항공전자 분야가 MISRA C/C++을 따르는지 궁금했음
  • 코딩 표준은 일부일 뿐이고, 핵심은 감사 가능한 프로세스 문서화임
    DO-178C 같은 인증 체계가 중요함
  • 회사마다 다름. 어떤 곳은 Matlab/Simulink 오토코드로 생성된 C를 그대로 씀
    오히려 이게 고신뢰성 코드 작성의 올바른 방식일 수도 있음
  • 지역별로도 다름. 미국은 MIL 표준, 유럽은 ECSS, 항공은 DO-178C, 그리고 MISRA가 널리 쓰임
• LaurieWired의 유튜브 채널이 정말 훌륭함
  • 특히 ARM 어셈블리 튜토리얼 시리즈가 뛰어남
• Laurie의 다른 영상들도 추천함
  리버스 엔지니어링, 난독화, 컴파일러 등 다양한 주제를 다룸
• “널 포인터를 역참조하지 말라”는 규칙(AV Rule 174, MISRA Rule 107)을 보고
  이런 것도 굳이 명시해야 하나 싶었음
• 실제 F-35 코드 빌드에 어떤 컴파일러를 쓰는지도 궁금함
  LM이 직접 만든 건지, 상용 제품인지 알고 싶음