malloc上栽的跟头

来源：互联网发布：it类专业有哪些编辑：程序博客网时间：2024/04/30 14:50

char *src_uid = NULL, *desc_uid = NULL;
parse_sduid_str(uid_s, &src_uid, &des_uid);
int parse_sduid_str(const char *uid_s, char **src_uid, char **des_uid)
{
int i = 1;
int j = 0;

        *src_uid = (char *)calloc(sizeof(char), 5);
        *des_uid = (char *)calloc(sizeof(char), 5);
        if(*src_uid == NULL || *des_uid == NULL){
                return FALSE;
        }

        for(; uid_s[i] != ']'; i++, j++){
                *src_uid[j] = uid_s[i];
        }
      *src_uid[j] = '\0';

        for(i++, j = 0; uid_s[i] != '\0'; i++, j++){
                *des_uid[j] = uid_s[i];
        }

*des_uid[j] = '\0';

return TRUE;
}

这段代码有一个很严重的隐患问题：
calloc时候：
char **时候，形参已经获得实参地址(uid_s, &src_uid, &des_uid)；
也就是说char *的地址是确定的，这时候把calloc返回的地址给了char * ,明明之中就会改变实参传过来的地址。例如实参是 1 2,calloc完毕之后地址不见得是1 2而是calloc返回的地址可能是3,4也可能是其他。

应该是在函数内部定义变量之后calloc；一切操作完成之后再把首地址赋值给形参变量带回，这样就不会出问题。
设计问题：
1：
最好的函数设计只是实现要实现的功能不做其他任何处理！
也就是说malloc等等的内存管理函数都在主进程统一管理，维护。
函数内部只实现函数的事。否则很容易造成泄露也很不容易维护。
如果这个函数式循环调用的环境就是不好维护free的例子
2：
函数中能不malloc就不用，这写个内存函数会带来很多很多内存碎片。
这个是需要专门维护的，否则如果服务器一直运行不重启，内存总有吃空那时候。
3：设计：
int main()
{
char str[100] = {0};
func(str);
printf("%s\n", str);
}
int func(char *buf){
strcpy(buf, "1234");
}

0 0