This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Code generation bug for operator new[] when -fcheck-new in GCC 3.3.1

This bug is more properly a bug with GCC and not with cygwin - it shows up
in GCC 3.2.2 (i386-redhat-linux) as well. So I've submitted the problem to
GCC Bugzilla.  It's Bug 13215. - Tom

-----Original Message-----
From: Tom Scott [] 
Sent: Wednesday, November 26, 2003 4:17 PM
Subject: Code generation bug for operator new[] when -fcheck-new in GCC

I've found that the following sample, which uses nothrow memory allocation
semantics, generates a segmentation violation:

// g++ -g -fcheck-new -fno-exceptions -fno-rtti sample.cpp #include
class foo {
    int v;
    foo(){ v = 0; }
    ~foo() {}
    void* operator new[](size_t size) {
        return 0;   // simulated memory failure
    void operator delete[](void* p, size_t size) { }
    foo *p = new foo[2];
    // p==4 here
    if (p) delete [] p;
    return 0;

The segmentation violation results from a bug in the code that is generated
to call operator new[].  The return of operator new[] is correctly checked
for non-zero before calling the ctor ("-fcheck-new" semantics), but this
return value is subsequently incremented by 4.  As a result, p is set to 4
(not 0) when memory runs out.
A work around is to modify applications so that the return value of "new
class[]" is checked and to treat a return of 4 the same as 0.

Unsubscribe info:
Problem reports:

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