浅谈hks_ipc_serialization中的函数KeyInfoListInit

在阅读源代码的时候看到这个函数时，有些疑惑，在此表达自己一点点的看法，由于知识水平的不足，还望大家批评指正，一起交流！

1. 函数分析

首先我们贴上源代码跟我自己的注释：

分析：
先从参数分析：

• struct HksKeyInfo *keyInfoList：用于存储keyInfo的列表
• uint32_t listCount：列表的项数
• const struct HksBlob *srcData：需要添加入list的数据来源
• uint32_t *offset：调用函数时需要传入的偏移量

函数的基本流程：for循环，调用两个函数MallocBlobFromBuffer和MallocParamSetFromBuffer将存储在srcData中的blob跟paramSet存入keyInfoList的相应位置，当分配失败时，调用HKS_LOG_E进行日志打印。最后在ret不为HKS_SUCCESS时，也就是存在一项分配失败时，将分配过信息的空间全部释放

首先我们可以从hks_log.h中看到HKS_LOG有四种类型：

分别是INFO WARN ERROR DEBUG
按照一般逻辑来说，日志打印的调用不会涉及到中断啥的，所以日志的打印并不会中断for循环的执行

那么问题来了——按照我的理解这里将i单独定义在上头，并在下方处理错误的分配空间时使用的也是i，也就是说这里的意思应该是当执行for循环中的两个拷贝函数时如果发生错误，则进行日志打印并且保存此时的i值并进行break——跳转到下面的判断语句，由于上方有分配错误的发生，那么ret必然不等于HKS_SUCCESS,此时则根据上面for循环break得到的i对现已分配的keyInfo调用 HKS_FREE_BLOB和HKS_FREE_PTR进行空间的释放。

但是for循环中并没有提前结束的标志，那么中间的错误分配将得不到及时的处理——只能通过最后一个分配得到的结果ret来进行——我认为这显然不符合鸿蒙严谨高效的一贯代码风格(可能是产生bug了)

错误的分配不及时的处理可能会引发很大的隐患；而后面的只要最后一个不错，那么中间的错误分配并不会得到有效的处理(比如释放)，会导致内存的无效占用，浪费资源，所以私以为这样的代码不符合规范

2. 函数改进

改进就很简单了，在for循环中加入提前结束的标志break——当MallocBlobFromBuffer和MallocParamSetFromBuffer出现错误(返回ret非HKS_SUCCESS)时，进行break，则此时将不会往下进行分配，i也能保存当前的值在下面进行正确个数的空间释放——一个分配有误则将前面所有已分配的空间释放并返回错误

则修改后的代码为：

感谢阅读！