Osheep

时光不回头,当下最重要。

linux c开发: 关于malloc(0)

因为有一个bug栽在malloc(0)上,所以有必要记录一下。先说结论:

  • malloc(0)是允许的,并且返回一个非NULL的指针,至少在我工作的linux系统上是这样的。man文档里面说:
    malloc() allocates size bytes and returns a pointer to the allocated memory. The memory is not cleared. If size is 0, then malloc() returns either NULL, or a unique pointer value that can later be successfully passed to free()
    关键在于这个or,也许是有返回NULL的情况,但是我们不能忽视返回非NULL的情况。我的bug就是犯了这个错误。
  • 实际malloc(0)没有什么意义,应该判断参数值,如果是0就不要malloc并返回一个NULL指针,这样size_t参数和malloc的返回结果就统一了,避免不明白这个细节的人,比如之前的我,写出bug。

再看看我的bug,我大概是写了一个这样的函数:

uint8_t generate_random_buffer(char **out_buf)
{
    uint8_t size = get_random_byte();
    *out_buf = malloc(size);
    set_randombytes_buf(*out_buf, size);
    return size;
}

这个函数随机出一个unsigned byte,即0~255, 以此为size,malloc一个buf,并且向其中填入随机字节。然后通过参数将buf返回到调用者,函数返回值为buf的size。当时我是知道随机出来的size可能为0,并且也查了一下malloc(0)没问题,且可能返回一个NULL。然后我就大意了。再调用这个函数的地方,使用完这个随机buf后,我需要释放他。我直接使用 != NULL来判断,并且释放了一个关联的buf。而那个关联的buf是在size大于0才会malloc出来,而size等于0时,这个关联buf的指针是指向一个栈上的结构体。好吧,这个情况是有点复杂,毕竟是实际的项目。bug的来源在于返回的size为0时,我没有malloc这个关联buf,而释放这个关联buf的条件是随机buf不为NULL,我这么写只是为了偷懒,少做一个判断,当时心里想size大于0时随机buf才不会NULL吧,所以关联buf也是malloc过的。实际上,现在知道了,size为0时,随机buf的指针不是NULL,而我判断随机buf不是NULL的时候顺带free了关联buf造成了double free的crash(其实是free了栈上的对象)。
解决bug的方法可以是区别对待返回的size值和随机buf指针,但是我觉得更稳妥的,特别是如果其他人用了我写的函数最好不要出类似的问题,所以我改成了当size为0时不malloc,这保留随机buf的指针为NULL。

uint8_t generate_random_buffer(char **out_buf)
{
    uint8_t size = get_random_byte();
    if(size > 0) {
        *out_buf = malloc(size);
        set_randombytes_buf(*out_buf, size);
    }
    return size;
}
点赞