public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "bangerth at dealii dot org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/19351] operator new[] can return heap blocks which are too small Date: Sun, 09 Jan 2005 22:48:00 -0000 [thread overview] Message-ID: <20050109224835.3377.qmail@sourceware.org> (raw) In-Reply-To: <20050109221816.19351.fw@deneb.enyo.de> ------- Additional Comments From bangerth at dealii dot org 2005-01-09 22:48 ------- I also wonder what the semantics are that you are expecting? I mean, you try to allocate an array that is so large that you can't address the individual bytes using a size_t, in other words one that is larger than the address space the OS provides to your program. That clearly doesn't make any sense. That being said, I understand that the behavior of this is security relevant and that any attempt to allocate more memory than is available will necessarily have to fail. Thus, our present implementation isn't standards conforming, since it returns a reasonable pointer even in the case that the allocation should have failed. I would therefore agree that this is a problem, and given that memory allocation is an expensive operation, one overflow check isn't really time critical. Unfortunately, the situation is not restricted to libstdc++'s implementation of operator new[], since that operator only gets the total size of the memory to be allocation, not the size per element and the number of elements. Therefore, by the time we get into the implementation of this operator, it is already too late. In other words, the overflow check has to happen in compiler-generated code, not in the libstdc++ implementation. I would support the introduction of such code, if necessary guarded by some flag, or unconditionally, as a matter of quality of implemetation. W. -- What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed| |1 Last reconfirmed|0000-00-00 00:00:00 |2005-01-09 22:48:34 date| | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19351
next prev parent reply other threads:[~2005-01-09 22:48 UTC|newest] Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top 2005-01-09 22:18 [Bug c++/19351] New: " fw at deneb dot enyo dot de 2005-01-09 22:25 ` [Bug c++/19351] " pinskia at gcc dot gnu dot org 2005-01-09 22:35 ` fw at deneb dot enyo dot de 2005-01-09 22:45 ` pinskia at gcc dot gnu dot org 2005-01-09 22:47 ` pinskia at gcc dot gnu dot org 2005-01-09 22:48 ` bangerth at dealii dot org [this message] 2005-01-09 23:07 ` fw at deneb dot enyo dot de 2005-01-09 23:12 ` pinskia at gcc dot gnu dot org [not found] <bug-19351-192@http.gcc.gnu.org/bugzilla/> 2006-09-27 23:51 ` geoffk at gcc dot gnu dot org 2006-09-27 23:56 ` Andrew Pinski 2006-09-27 23:56 ` pinskia at physics dot uc dot edu 2007-03-23 15:00 ` mmitchel at gcc dot gnu dot org 2007-03-23 15:09 ` schwab at suse dot de 2007-03-23 15:23 ` fw at deneb dot enyo dot de 2008-04-01 20:46 ` pinskia at gcc dot gnu dot org 2008-04-01 20:48 ` pinskia at gcc dot gnu dot org 2008-04-01 21:25 ` felix-gcc at fefe dot de 2008-04-01 21:52 ` rguenth at gcc dot gnu dot org 2008-12-09 23:25 ` mrs at apple dot com 2010-02-06 8:20 ` fw at gcc dot gnu dot org 2010-03-22 18:40 ` tglek at mozilla dot com 2010-03-25 16:45 ` fw at gcc dot gnu dot org 2010-03-25 16:58 ` manu at gcc dot gnu dot org 2010-03-25 17:14 ` fw at gcc dot gnu dot org 2010-05-23 11:04 ` fw at gcc dot gnu dot org [not found] <bug-19351-4@http.gcc.gnu.org/bugzilla/> 2011-01-22 21:27 ` fw at gcc dot gnu.org 2011-05-24 13:00 ` redi at gcc dot gnu.org 2011-05-24 20:12 ` fw 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=20050109224835.3377.qmail@sourceware.org \ --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).