带日志级别的标准输出日志宏编译警告及宏展开问题排查

核心原因 #

问题大概率出在log_msg宏的定义上，尤其是##__VA_ARGS__的使用干扰了编译器对可变参数的类型识别，导致格式检查出现偏差。

旧项目里常见的错误宏定义可能是这样：

#define log_msg(level, out, fmt, ...) \
    do { \
        if (level >= LOG_LEVEL) { \
            fprintf(out, fmt, ##__VA_ARGS__); \
        } \
    } while(0)

这里的##__VA_ARGS__在部分旧版编译器（比如老GCC）中会“折叠”可变参数的类型信息，让编译器无法正确关联格式字符串和参数类型，甚至会误导你觉得是格式符的问题，陷入调整格式符的循环。另外，宏如果嵌套了其他处理逻辑、对参数做了隐形转换，也会破坏格式检查。

排查步骤 #

• 查宏定义：找出log_msg的完整定义，看是否存在##__VA_ARGS__滥用、参数额外包装/转换、宏展开后输出函数参数列表被破坏的情况。
• 手动展开宏：把你的调用log_msg(LOG_DBG, STD_OUT, "msgSize = %ld", msgSize)手动展开，看生成的代码。如果展开后是正常的fprintf调用，那问题要么是格式符和参数类型不匹配，要么是msgSize的实际类型被项目里的typedef或宏偷偷改了（旧项目常出现这种奇葩操作）。
• 验证参数类型：用printf("sizeof(msgSize)=%zu\n", sizeof(msgSize));打印参数大小，32位系统下int是4字节对应%d，64位下long是8字节对应%ld。
• 检查编译器：旧版GCC对##__VA_ARGS__的格式检查支持差，加-Wformat=2选项让编译器做更严格的检查，明确错误来源。

解决办法 #

• 修正宏定义：如果是##__VA_ARGS__的问题，尝试去掉##（如果不需要处理空参数的话），或者改成更规范的写法：

  #define log_msg(level, out, fmt, ...) \
      do { \
          if (level >= LOG_LEVEL) { \
              fprintf(out, fmt, __VA_ARGS__); \
          } \
      } while(0)
  

  要是需要兼容空参数场景，保留##但确保编译器版本支持C99及以上。
• 用标准格式符：避免平台差异，引入<inttypes.h>用标准格式符，比如PRId32对应32位整数，PRId64对应64位：

  #include <inttypes.h>
  log_msg(LOG_DBG, STD_OUT, "msgSize = %" PRId32, msgSize);
  

• 确认参数类型：如果msgSize是int就用%d，是long就用%ld，别被编译器的误导性警告绕进去。

内容的提问来源于stack exchange，提问作者ProPlayerMaxUltra