PyArg_ParseTuple解析异常：Python C扩展Car类name属性乱码问题

一、方法1中repr()乱码的原因及修复 #

核心原因 #

你在方法1中大概率犯了以下错误之一：

1. 字符串未正确添加终止符：malloc内存时只分配了strlen(tmp)字节，未额外加1存储\0。printf会在遇到第一个\0时停止输出，恰好内存后续字节可能是\0，所以能正常显示；但PyUnicode_FromFormat等Python API会严格读取直到找到\0，越界读取垃圾数据就会出现乱码。
2. 未正确处理Unicode字符串：如果name包含非ASCII字符，用PyArg_ParseTuple的s格式符只能解析ASCII字符串，得到的指针无法正确表示Unicode内容，导致repr时乱码。

修复方案 #

• 修正内存分配：确保分配内存长度为strlen(tmp) + 1，给终止符留位置：

  self->name = malloc(strlen(tmp) + 1);
  if (self->name == NULL) {
      PyErr_NoMemory();
      return -1;
  }
  strcpy(self->name, tmp);
  

• 支持Unicode字符串：改用s#格式符获取字符串长度和指针，再完整复制：

  const char *tmp;
  Py_ssize_t len;
  if (!PyArg_ParseTuple(args, "s#id", &tmp, &len, &year, &maxGas)) {
      return -1;
  }
  self->name = malloc(len + 1);
  if (self->name == NULL) {
      PyErr_NoMemory();
      return -1;
  }
  memcpy(self->name, tmp, len);
  self->name[len] = '\0';
  

• 补充内存释放：在Car类型的tp_dealloc函数中释放self->name，避免内存泄漏：

  static void Car_dealloc(CarObject *self) {
      if (self->name != NULL) {
          free(self->name);
      }
      Py_TYPE(self)->tp_free((PyObject *)self);
  }
  

方法2的隐藏风险 #

方法2直接赋值self->name = tmp看似正常，但存在严重隐患：该指针指向Python字符串对象的内部缓冲区，当对应字符串被垃圾回收后，self->name会变成野指针，后续访问可能触发崩溃、乱码等未定义行为。仅当传入字符串是Python常量（如字面量）时不会出问题，但这种写法不可靠。

二、浮点数精度问题的处理 #

C的double和Python的float都是双精度浮点数，精度问题通常出现在格式化或转换环节：

1. 格式化输出精度丢失：%f默认只保留6位小数，改用%.15g或%.17f（双精度最多17位有效数字）可显示完整精度：

   // 在repr函数中
   return PyUnicode_FromFormat("<Car: name='%s', year=%d, maxGas=%.15g>", self->name, self->year, self->maxGas);
   

2. 类型转换避免手动拼接：返回浮点数给Python时用PyFloat_FromDouble函数，不要手动拼接字符串：

   static PyObject* Car_get_maxGas(CarObject *self, void *closure) {
       return PyFloat_FromDouble(self->maxGas);
   }
   

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