Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com From: "Tom Scott" To: Subject: Code generation bug for operator new[] when -fcheck-new in GCC 3.3.1 Date: Wed, 26 Nov 2003 16:16:37 -0500 Organization: Storage Matrix, Inc. Message-ID: <000c01c3b462$94729dc0$6400a8c0@DELL2K> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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 { public: 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) { } }; main() { 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. Tom -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/