http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56955
--- Comment #4 from Dan Gohman <sunfish at google dot com> 2013-04-15 14:53:06
UTC ---
(In reply to comment #3)
> 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.
Oh wow. That's a subtlety that completely escaped me.
> 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).
Is that example fundamentally different than something like this:
void *q = (void *)(mem[0] + 0xb1ab1ab1a);
In both cases, the information of the pointer value is in the expression, not
in the memory.
Is it the case that the memory must be either actually zeros or uninitialized?
Or could it contain other data which merely transmits no information about
pointer values?
> 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.
If this is what it means, then I request that the text be updated to say this.
I'd be willing to propose a wording, once I understand the intent, if that'd be
helpful.
What should we say about the fact that GLIBC uses the malloc attribute on
strdup (and similar things)? strdup actually could be used to transmit
information about pointer values.
