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.