PyArg_ParseTuple解析结果依赖指针声明顺序的原因排查

直接原因：栈内存布局的未定义行为 #

你遇到的现象完全可以解释——这是C语言栈内存布局与对齐规则导致的未定义行为。

PyArg_ParseTuple会严格按照格式字符串的顺序，将Python元组中的参数依次写入你传入的指针指向的内存地址。而C编译器对栈上变量的存储顺序、对齐方式和填充字节有自由决定权：

• 原变量声明顺序下，msg_len（如果类型是int而非Py_ssize_t）和type的大小/对齐要求不同，编译器可能在栈上插入了填充字节，或者变量的实际内存位置与PyArg_ParseTuple的写入顺序不匹配，导致解析时的内存写入错误覆盖了gobj的指针值，最终让它变成空指针。
• 调整type和msg_len的声明顺序后，栈上变量的布局恰好避开了对gobj指针的破坏，所以解析恢复正常。

深层问题：参数类型不匹配才是根源 #

调整变量顺序只是临时的“歪打正着”，真正的隐患是**PyArg_ParseTuple格式字符串与变量类型不匹配**：

• 格式符s#要求对应的两个参数必须是char**和Py_ssize_t*，但如果你的msg_len被声明成了int而非Py_ssize_t，就会出现类型不匹配。
• 这种不匹配会导致PyArg_ParseTuple写入时越界访问栈内存，破坏相邻变量（比如gobj的指针）。不同的变量声明顺序只是改变了栈上变量的位置，让越界的影响是否显现变得随机。

修复建议 #

1. 严格匹配类型：把msg_len的类型改成Py_ssize_t，完全对应s#格式符的要求，这才是解决问题的根本。
2. 不要依赖变量顺序：依赖声明顺序规避问题是不可移植的，换编译器、编译选项（比如开启优化）都可能让问题复现。
3. 全面检查参数匹配：排查所有C扩展中PyArg_ParseTuple的调用，确保格式符和变量类型一一对应，这是Python C扩展开发中最常见的坑之一。

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