C语言如何正确接收结构体作为函数输出参数

关于无效值处理与悬垂指针问题的优先级 #

你提出的“函数应当具备处理无效传入值的能力”的思路方向是合理的，但这个需求的优先级绝对低于悬垂指针对应的所有权规则设计。

• 悬垂指针是C语言接口设计层面的根本性问题：C没有自动内存回收机制，所有涉及堆分配结构体的接口，必须首先明确所有权契约——比如调用transform_pointer_contents时，传入的二级指针指向的一级指针，必须是持有对应GArray唯一所有权的合法指针，不允许存在其他未同步的别名拷贝。这是调用方必须遵守的前置条件，违反约定导致的野指针、use-after-free问题，本质是调用方的bug，不可能靠函数内部的逻辑兜底解决——总不能在函数里扫描整个进程的内存空间，把所有指向旧GArray实例的指针都更新成新地址。你提到的“拷贝了原指针后函数内部释放旧内存导致拷贝失效”的风险，根源就是没有提前定好所有权规则，和函数容错能力没有关系。
• 无效值处理是所有权规则明确后的健壮性补充，而非核心规则。比如你现在代码里判断*arr != NULL再执行g_array_unref，就是很合理的容错：允许调用方传入指向NULL指针的二级指针（比如还没初始化的GArray*变量），函数不会直接崩溃。但容错是有明确边界的：你永远没法处理调用方传进来的野指针、已经释放过的悬空指针、指向只读内存区的指针这类非法值，硬要“兼容”这类值只会掩盖真实bug，反而会让后续问题排查难度陡增。
• 不要把容错做成对错误的纵容：如果调用方传入的二级指针本身就是NULL（也就是参数arr为NULL，不是*arr为NULL），你当前的代码直接解引用会触发段错误，这种场景要么加判断直接安全返回，要么在调试版本加断言直接报错，明确告知调用方传参错误，不要静默失败。

结构体输出参数的适用模式 #

你当前写的“二级指针传参、函数内部释放旧值、返回新实例指针”的模式，仅适用于持有堆分配对象所有权的指针类型输出场景，并不适配所有结构体类型，不同场景的正确实现方式如下：

• 场景1：栈分配的值语义普通结构体
  这类结构体没有额外的堆内存依赖，内存随栈帧自动回收，根本不需要二级指针，直接传一级指针作为输出参数即可。示例：

  typedef struct {
      int x;
      int y;
  } Point;
  
  // 输出参数为调用方栈上结构体的指针，函数直接向预留内存写入内容
  void get_default_point(Point* out) {
      if (out == NULL) return; // 基础空指针容错
      out->x = 0;
      out->y = 0;
  }
  
  // 调用方写法
  Point p;
  get_default_point(&p);
  

  这种模式不存在所有权转移，也不会产生悬垂指针，是C语言里最常见的结构体输出参数写法。
• 场景2：GArray这类由库实现、带引用计数/专属内存管理逻辑的堆分配结构体
  你当前的实现思路是正确的，只需要补全细节即可：
  1. 首先在接口约定里写死所有权规则：传入的*arr必须是调用方合法持有的GArray指针（允许为NULL），函数调用后*arr指向的新实例所有权仍归调用方，由调用方负责最终释放；调用过程中旧的GArray实例会被销毁，所有指向旧实例的别名会立即失效，调用方不得留存旧指针拷贝。
  2. 补全二级指针本身的空判断，避免直接解引用空指针：

     void transform_pointer_contents(GArray** const arr) {
         if (arr == NULL) return; // 先校验二级指针本身的有效性
     
         GArray* const tmp = g_array_new(true, true, sizeof(uint8_t));
         const uint8_t example_num = 5;
         g_array_append_val(tmp, example_num);
     
         if (*arr != NULL) {
             g_array_unref(*arr);
         }
         *arr = tmp;
     }
     

  3. 你提到的“使用类型官方提供的创建/销毁/重置API，优于手动清空元素、memset置零”的判断完全正确。类似GArray这类封装好的结构体，内部往往存在开发者不可见的隐藏字段、额外分配的内存，手动清空或者置零内存，要么会漏释放内部内存造成泄漏，要么会破坏结构体内部状态触发后续操作崩溃，必须使用配套的官方API操作。
• 场景3：无明确内存管理函数的自定义堆分配结构体
  这类场景也可以用二级指针输出的模式，但必须把所有权转移、旧指针失效的规则写得非常明确，不要让调用方猜测内存管理责任。绝对不要对值语义的栈结构体滥用二级指针，只会徒增代码复杂度，提高内存错误概率。

顺便提下你示例代码里的两个小问题：一是main函数里把arr声明为const GArray*，和函数参数类型不匹配——const修饰表示指向的GArray内容不可修改，但你的函数既要修改指针的指向，还要往数组里写入元素，这个const是多余的，会触发编译器类型警告；二是evil_copy本身就是违反所有权约定的写法，只要接口明确标注了旧指针失效规则，这类问题属于调用方使用不当，不需要在函数内部做无意义的兼容。

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