public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: Hallvard B Furuseth <h.b.furuseth@usit.uio.no> To: gcc-gnats@gcc.gnu.org Cc: h.b.furuseth@usit.uio.no Subject: c/3414: Inaccurate documentation of __attribute__((malloc)) Date: Mon, 25 Jun 2001 13:36:00 -0000 [thread overview] Message-ID: <E15Ed3R-00015d-00@bombur.uio.no> (raw) >Number: 3414 >Category: c >Synopsis: Inaccurate documentation of __attribute__((malloc)) >Confidential: no >Severity: non-critical >Priority: low >Responsible: unassigned >State: open >Class: doc-bug >Submitter-Id: net >Arrival-Date: Mon Jun 25 13:36:00 PDT 2001 >Closed-Date: >Last-Modified: >Originator: Hallvard B Furuseth >Release: 3.0 >Organization: >Environment: System: SunOS bombur.uio.no 5.8 Generic_108528-03 sun4u sparc SUNW,Ultra-5_10 Architecture: sun4 host: sparc-sun-solaris2.8 build: sparc-sun-solaris2.8 target: sparc-sun-solaris2.8 configured with: ./configure --quiet --enable-version-specific-runtime-libs --prefix=/usit/bombur/hbf --program-suffix=-3.0 >Description: From @item malloc, @node Function Attributes: "The `malloc' attribute is used to tell the compiler that a function may be treated as if it were the malloc function." The compiler could assume several things about that; e.g. that the return value will be aligned for any data type. However, the rest of the paragraph is: "The compiler assumes that calls to malloc result in a pointers that cannot alias anything. This will often improve optimization." Is this the *only* assumption __attribute__((malloc)) causes? Incidentally, it also assumes that the program uses malloc correctly - here is a malloc which _can_ alias something: free(x = malloc(10)); if (x == (y = malloc(10))) { ... } (BTW, typo: "a pointers" should be "a pointer". >How-To-Repeat: >Fix: I'm guessing that you mean something like this, but I have not checked. Sorry if my English is a bit clumsy: The @code{malloc} attribute is used to tell the compiler that a function returns a pointer which cannot alias anything (or a null pointer), i.e. i behaves like the @code{malloc} function. This will often improve optimization. Note that this may break programs that incorrectly uses the value of such a pointer after it has been invalidated (in the case of malloced pointers by calling @code{free()}, even if the pointer is not dereferenced. >Release-Note: >Audit-Trail: >Unformatted:
next reply other threads:[~2001-06-25 13:36 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2001-06-25 13:36 Hallvard B Furuseth [this message] 2003-02-18 2:54 bje 2003-03-27 21:04 neroden
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=E15Ed3R-00015d-00@bombur.uio.no \ --to=h.b.furuseth@usit.uio.no \ --cc=gcc-gnats@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).