From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19570 invoked by alias); 15 Apr 2013 14:53:11 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 19544 invoked by uid 48); 15 Apr 2013 14:53:07 -0000 From: "sunfish at google dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug other/56955] documentation for attribute malloc contradicts itself Date: Mon, 15 Apr 2013 14:53:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: other X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: sunfish at google dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 X-SW-Source: 2013-04/txt/msg01475.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56955 --- Comment #4 from Dan Gohman 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.