sublimelinter-contrib-gcc仅提供基础语法检查，不支持misra等合规检测；它依赖gcc的-wall/-wextra等编译警告，无法识别编码规范、安全规则或行业标准，真正合规需换用cppcheck或clang-tidy等专用静态分析工具。
SublimeLinter-contrib-gcc 本身不提供“合规检测”，它只是把 gcc 当作一个语法/编译器前端来调用，能报错但不能做代码规范、安全规则或行业标准（如 MISRA、AUTOSAR、CERT）的检查——那些必须靠专用静态分析工具（如 cppcheck、pc-lint、clang-tidy）或定制规则引擎。
为什么 gcc 不适合做合规检测
gcc 的 -Wall、-Wextra 等开关只覆盖基础语言约束和常见陷阱（比如未初始化变量、隐式类型转换），对编码规范（如命名风格、函数长度、圈复杂度）、安全实践（如缓冲区边界、格式化字符串）或行业标准条款完全无感知。
- 它不会告诉你 “函数不应超过 50 行” 或 “禁止使用
strcpy” - 它默认不启用
-Werror，警告（warning）不会中断 lint 流程，容易被忽略 - 它无法读取
.clang-tidy或cppcheck.cfg这类规则配置文件 - 即使加了
-std=gnu11或-fms-extensions，也只是放宽语法限制，不是增强合规能力
SublimeLinter-contrib-gcc 的真实用途和配置要点
它适合快速捕获语法错误、链接缺失符号、头文件路径错误等编译层问题，尤其在嵌入式或裸机 C 开发中作为轻量级预检手段。关键配置项如下：
-
"executable"必须指向完整路径，例如/usr/bin/gcc（Linux/macOS）或C:\MinGW\bin\gcc.exe（Windows），不能只写gcc—— Sublime 不继承 shell 的PATH -
"args"推荐至少包含：["-x", "c", "-std=c11", "-Wall", "-Wextra", "-fsyntax-only"]；-fsyntax-only是关键，避免生成临时文件或触发完整编译 -
"include_dirs"要显式列出项目依赖路径，例如["./inc", "/opt/stm32/include"]，否则#include "xxx.h"会直接报错退出 - 若用交叉编译链（如
arm-none-eabi-gcc），必须在"executable"中指定全名，并在"args"中加-mcpu、-mfloat-abi等目标参数
想做真正合规检测？换工具链，别硬套 gcc
如果目标是 MISRA-C:2012、ISO/IEC TS 17961 或 AUTOSAR C++14 规则集，gcc 无法胜任。可行路径只有两条：
- 用
SublimeLinter-clang-tidy：支持.clang-tidy配置，可开启modernize-*, cppcoreguidelines-*, misc-*等检查集，部分覆盖 CERT 和 AUTOSAR - 用
SublimeLinter-cppcheck：支持--addon=misra.py（需额外安装 MISRA 插件），并能加载cppcheck.cfg自定义规则 - 两者都要求对应 CLI 工具已安装且路径正确；
clang-tidy需要compile_commands.json，cppcheck可直接扫描单文件但精度较低
真正麻烦的从来不是插件怎么装，而是规则谁来定义、结果谁来解读、误报怎么压——gcc 的输出只是起点，不是终点。
