This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [C++] init.c/build_new wrongly implements new-expression


Alexandre Oliva <oliva@dcc.unicamp.br> writes:

| On May 25, 1999, Gabriel Dos_Reis <Gabriel.Dos_Reis@sophia.inria.fr> wrote:
| 
| > Alexandre Oliva <oliva@dcc.unicamp.br> writes:
| > | On May 24, 1999, Gabriel Dos_Reis <Gabriel.Dos_Reis@sophia.inria.fr> wrote:
| > | 
| > | > So that the following ends up with a segmentation fault instead of
| > | > throwing a bad_alloc:
| > | 
| > | > 	double* p = new double[numeric_limits<size_t>::max()];
| > | 
| > | It is correct.  It is not the allocation that fails, it's the size
| > | calculation that overflows, thus producing undefined results.
| 
| > A possible fix would consist in having build_new insert a test to
| > detect overflow and throw a bad_alloc. Thoughts?
| 
| A general principle of C++ is that you don't pay for what you don't
| use.

That is why virtually any C++ program that uses the Standard library
has exception handling concern even though it doesn't use exceptions ;-)

No, I don't think that the zero-overhead is relevant in this
particular case. 

Checking whether the new-expression ends up by allocating sufficient
memory is part of the semantics of new-expression.

ISO 14882 says in 5.3.4/10:
---
  A new-expression passes the amount of space requested to the
  allocation fonction as the first argument of type std::size_t.  That 
  argument shall be no less that the size of the object being created;
  [...]
---

It appears that if you use a new-array then you use size-overflow-checking. 

| ... Testing for overflow in every single new-expression might
| introduce unacceptable overhead, while concerned users might (and
| should) perform the test themselves, for the sake of portability.
| Therefore, IMHO, gcc is not the proper place to introduce this fix.

Sorry to disagree with you but gcc is the right place, as it is where
we implement the new-expression semantics.  Telling users to do what
g++ is supposed to be doing is just plain silly.

| Unless it is disabled by default, and is enabled with
| -fcheck-overflow-on-new-array.  But I don't think it's worth it.

I do see things in the revere way: provide
-fno-check-overflow-on-new-array as we do for exception handling.

-- Gaby


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]