post
C 확장, 이식성, 대체 컴파일러에 관하여
ISO C 표준만 따르는 코드는 드물고, 실제 C 코드베이스는 기능 추가와 컴파일러·라이브러리별 공백 우회를 위해 비표준 확장에 의존함 유용한 C 컴파일러는 stdio.h 같은 시스템 헤더부터 처리해야 하지만, glibc는 __attribute__((packed)), #include_next 같은 GNU 확장과 가정으로 장벽을 만듦
한 줄 요약
ISO C 표준만 따르는 코드는 드물고, 실제 C 코드베이스는 기능 추가와 컴파일러·라이브러리별 공백 우회를 위해 비표준 확장에 의존함
핵심 내용
ISO C 표준만 따르는 코드는 드물고, 실제 C 코드베이스는 기능 추가와 컴파일러·라이브러리별 공백 우회를 위해 비표준 확장에 의존함
유용한 C 컴파일러는 stdio.h 같은 시스템 헤더부터 처리해야 하지만, glibc는 _attribute((packed)), #includenext 같은 GNU 확장과 가정으로 장벽을 만듦
SDL의 byteswapping 로직은 ISA 매크로가 있으면 inline assembly를 택할 수 있어, GCC·clang이 아닌 컴파일러도 GCC식 확장을 요구받을 수 있음
OpenBSD와 Gnulib의 extern inline 처리는 C99와 GCC 의미 차이, 플랫폼별 분기, FORTIFYSOURCE 조건 때문에 inline 의미론 호환을 복잡하게 만듦
작은 C 컴파일러는 upstream 패치, downstream 패치, 전용 가드 확보, GCC 호환성 흉내 중 선택해야 하며 기능 테스트 매크로 확대가 더 나은 방향으로 보임
왜 중요한가
유용한 C 컴파일러는 stdio.h 같은 시스템 헤더부터 처리해야 하지만, glibc는 _attribute((packed)), #includenext 같은 GNU 확장과 가정으로 장벽을 만듦 SDL의 byteswapping 로직은 ISA 매크로가 있으면 inline assembly를 택할 수 있어, GCC·clang이 아닌 컴파일러도 GCC식 확장을 요구받을 수 있음 OpenBSD와 Gnulib의 extern inline 처리는 C99와 GCC 의미 차이, 플랫폼별 분기, FORTIFYSOURCE 조건 때문에 inline 의미론 호환을 복잡하게 만듦
참조한 것 · 가져온 것
원문: https://lemon.rip/w/6-c-extensions-compilers/
GeekNews: https://news.hada.io/topic?id=29887
