From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11859 invoked by alias); 4 May 2012 21:16:43 -0000 Received: (qmail 11850 invoked by uid 22791); 4 May 2012 21:16:42 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 04 May 2012 21:16:20 +0000 From: "dimitrisdad at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/53225] static operator new in multiple inheritance carries incorrect type information for the class Date: Fri, 04 May 2012 21:16:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Keywords: X-Bugzilla-Severity: minor X-Bugzilla-Who: dimitrisdad at gmail dot com X-Bugzilla-Status: WAITING X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-05/txt/msg00503.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225 --- Comment #18 from Thomas W. Lynch 2012-05-04 21:16:18 UTC --- This code compiles: #include #include typedef unsigned int uint; class C{ // just here to be faithful to the original code int y; }; class A{ public: typedef A this_type; void* operator new(size_t enfacia_size, uint count){ size_t total_size = enfacia_size + sizeof(int) * count; // the 'tail' ; this_type *new_pt = (this_type *)malloc(total_size); new_pt->count = count; return new_pt; }; uint count; }; class B : public C, public A{ public: int i; }; int main(){ B *b_pt = new(5) B; uint j=0; j++; }; And this is the debugger output: (gdb) r Starting program try_offsets Breakpoint 1, main () at try_offsets.cc:32 (gdb) n (gdb) p &(b_pt->count) $1 = (uint *) 0x804a00c (gdb) x/10 b_pt 0x804a008: 5 0 0 0 0x804a018: 0 0 0 0 0x804a028: 0 135129 (gdb) p b_pt $2 = (B *) 0x804a008 (gdb) Compare this to the prior code and debugger output of the same form, and you will notice that operator new, from a point of view of type, behaves differently than other method. Though it was inherited, its understanding of this_type has not changed, as it does in the case for other methods. In the least, in a strongly typed system I would expect there to be a warning about inheriting operator new when the type was not going to be updated as it is for other opertors and methods, though I suspect it is a small matter for the compiler to give it the right type info. >>From a language design point of view, I could see not having operator new accept references to the object as it blurs the line between allocation and intialization (operator new and construction). It such a constraint were made it should not be by implied contract with the programming because it is such a subtle issue, there should be an error IMHO. Though, I don't like seeing non-orthogonal artificial constraints, there is no reason operator new shouldn't see the correct static type. Let the programmer determine the appropriate conceptual partitioning. In any case, what we have now is neither of these. The compiler lets you do, though it is easy check for, and then it generates code that doesn't work - then when coming back to the compiler guys one engages in a very technical discussion. Seems a small change would increase productivity and quality code .. I see our comments crossed, let me look at what you just posted here now