public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug other/56955] documentation for attribute malloc contradicts itself Date: Wed, 21 May 2014 12:09:00 -0000 [thread overview] Message-ID: <bug-56955-4-NWSBMnG2Gb@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-56955-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56955 Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Last reconfirmed| |2014-05-21 CC| |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Dan Gohman from comment #4) > (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. It's exactly the same. > 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? There must be no way to "compute" a pointer to an object by _just_ combining bits and bytes of that memory cleverly. So for example initializing the memory to -1 (all bits set) would not work as you can compute a zero from 1 ^ 1 and thus any possible pointer value. That's not possible for zero. Oh wait, you can do ~0. Hmm ... subtle ;) Ok, we ignore pointer values computed from FP values as well, thus I guess technically only undefined content is really really valid. Practically memory with non-pointer values is ok unless you play evil (or very evil) games outlined above. > > 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. True. See above though. Note that the actual implementation (as opposed to what would be allowed by the documentation) does: /* If this is not a real malloc call assume the memory was initialized and thus may point to global memory. All builtin functions with the malloc attribute behave in a sane way. */ if (!fndecl || DECL_BUILT_IN_CLASS (fndecl) != BUILT_IN_NORMAL) make_constraint_from (vi, nonlocal_id); and thus restricts this to "known" functions (not only malloc, but also strdup which we just expect you don't use to transfer pointers ...). As of 'realloc' - yes we can special-case that in the compiler (we don't do that), but we can't really re-use the existing 'malloc' attribute for that. The proposed revised documentation looks like a good improvement to me, Paul, can you post it to gcc-patches@?
next prev parent reply other threads:[~2014-05-21 12:09 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <bug-56955-4@http.gcc.gnu.org/bugzilla/> 2013-04-14 19:05 ` pinskia at gcc dot gnu.org 2013-04-14 19:47 ` sunfish at google dot com 2013-04-15 10:19 ` rguenth at gcc dot gnu.org 2013-04-15 14:53 ` sunfish at google dot com 2014-05-20 20:41 ` eggert at gnu dot org 2014-05-20 20:49 ` carlos at redhat dot com 2014-05-20 20:51 ` eggert at gnu dot org 2014-05-20 21:00 ` bugdal at aerifal dot cx 2014-05-21 0:31 ` eggert at gnu dot org 2014-05-21 1:26 ` sunfish at mozilla dot com 2014-05-21 4:22 ` eggert at gnu dot org 2014-05-21 12:09 ` rguenth at gcc dot gnu.org [this message] 2014-05-21 13:09 ` rguenth at gcc dot gnu.org 2014-05-21 14:33 ` sunfish at mozilla dot com 2014-05-21 15:14 ` eggert at gnu dot org 2014-05-22 14:14 ` eggert at gnu dot org 2014-05-23 10:11 ` rguenth at gcc dot gnu.org 2014-05-23 10:13 ` rguenth at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-56955-4-NWSBMnG2Gb@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).