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


  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: link
Be 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).