http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56955
davidxl at google dot com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |davidxl at google dot com --- Comment #5 from davidxl at google dot com 2013-04-26 19:16:31 UTC --- The documentation gives the most strict semantic for the attribute where calloc is not qualified if NULL is a valid pointer. However GCC's implementation for the attribute is more relaxed but pessimizes simple cases: http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00381.html David (In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > I think it is talking about the memory returned by malloc/calloc will not > > > point > > > to another memory location while realloc can. > > > > I agree that's essentially what it ought to talk about, and the bug is that > > it's talking about something else -- the contents of the pointed-to memory. > > Well, it _is_ actually about the content. There must be no way to compute > a valid pointer to another object from the contents of the pointed-to > memory. So if you initialize the memory to {0, 1, 2, 3, 4 ...} thus > every possible byte value is somewhere and then do > > void *p = (void *)(mem[3] << 24 | mem[58] << 16 | ...); > > then points-to analysis assumes that from the contents of 'mem' you > can only compute pointers to nothing (NULL). Technically for targets > where NULL is a valid poiner to an object calloc () may not be marked > with malloc. > > That is, read it in the way that the code assumes the memory _may_ be > zero-initialized (but only zero-initialized) or uninitialized.