public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
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:52:00 -0000	[thread overview]
Message-ID: <bug-53225-4-gzzLQHkPN0@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-53225-4@http.gcc.gnu.org/bugzilla/>

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225

--- Comment #22 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-05-04 21:51:39 UTC ---
(In reply to comment #19)
> Johnathan, const static members are compile time beasts.  There are almost
> macros like #define, but not quite as the compiler will give them storage if
> you take their address.

Please don't try to C++ to me.

How do you explain that "int_type" is int in A::f() and not short?

>  I don't think it is a good idea to add another
> paradigm into this.

Ignore the static const, explain the typedef.

> Nor does your example explain how the field moved and was
> correctly assigned in the code I gave above with method() - if I were to accept
> your example as valid, then that code would not work - but it does, there is
> is.  You can compile it, and get the memory dumps yourself in gdb.  Can you
> speak to that example with method()?  That would be very useful.

It didn't "move"

> (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

At 0x804a008 there is a B object.

Inside that B object is a C object, also at address 0x804a008, and an A object
at address 0x804a00c.  Think of the B as a little box with two object in it.

Inside the A at 0x804a00c is an integer called "count" and that is also at
address 0x804a00c.

The memory looks like this:

0x804a008      0x804a00c      
B-----------------------------
C--------------A--------------
y--------------count----------

Inside operator new you get a piece of memory, big enough for a B, then you
cast that memory to A* and dereference it to access A::count.  Because you cast
the memory to A* the compiler access "count" at that address (see the diagram,
the "count" member is at offset zero into an A.


here's your invalid example adjusted to use a normal member instead of operator
new, it fails in the same way:

#include <cstddef>
#include <stdlib.h>
#include <assert.h>
typedef unsigned int uint;

class C{ // just here to be faithful to the original code
  int y;
};

class A{
public:
  typedef A this_type;

  static void* create(size_t enfacia_size, uint count){
      size_t total_size 
    = enfacia_size
    + sizeof(int) * count; // the 'tail'
    ;
      this_type *new_pt = (this_type *)calloc(total_size, 1);
      new_pt->count = count;
      return new_pt;
  }
  uint count;
};

class B : public C, public A{
public:
    int i;
};

int main(){
  B *b_pt = (B*) B::create(sizeof(B), 5);
  assert(b_pt->count == 5);
}

There's nothing special about operator new, you just don't understand C++


  parent reply	other threads:[~2012-05-04 21:52 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-04  3:30 [Bug c++/53225] New: " dimitrisdad at gmail dot com
2012-05-04  3:35 ` [Bug c++/53225] " dimitrisdad at gmail dot com
2012-05-04  3:41 ` pinskia at gcc dot gnu.org
2012-05-04  5:21 ` dimitrisdad at gmail dot com
2012-05-04  8:55 ` redi at gcc dot gnu.org
2012-05-04  9:44 ` redi at gcc dot gnu.org
2012-05-04 18:12 ` dimitrisdad at gmail dot com
2012-05-04 18:32 ` redi at gcc dot gnu.org
2012-05-04 18:57 ` dimitrisdad at gmail dot com
2012-05-04 19:25 ` dimitrisdad at gmail dot com
2012-05-04 19:45 ` redi at gcc dot gnu.org
2012-05-04 19:59 ` dimitrisdad at gmail dot com
2012-05-04 20:02 ` dimitrisdad at gmail dot com
2012-05-04 20:10 ` daniel.kruegler at googlemail dot com
2012-05-04 20:18 ` dimitrisdad at gmail dot com
2012-05-04 20:35 ` redi at gcc dot gnu.org
2012-05-04 20:56 ` dimitrisdad at gmail dot com
2012-05-04 20:59 ` redi at gcc dot gnu.org
2012-05-04 21:07 ` redi at gcc dot gnu.org
2012-05-04 21:16 ` dimitrisdad at gmail dot com
2012-05-04 21:27 ` dimitrisdad at gmail dot com
2012-05-04 21:30 ` redi at gcc dot gnu.org
2012-05-04 21:41 ` dimitrisdad at gmail dot com
2012-05-04 21:52 ` redi at gcc dot gnu.org [this message]
2012-05-04 21:56 ` redi at gcc dot gnu.org
2012-05-04 22:01 ` dimitrisdad at gmail dot com
2012-05-04 22:05 ` daniel.kruegler at googlemail dot com
2012-05-04 22:07 ` pinskia at gcc dot gnu.org
2012-05-04 22:09 ` redi at gcc dot gnu.org
2012-05-04 22:31 ` dimitrisdad at gmail dot com
2012-05-04 22:55 ` dimitrisdad at gmail dot com
2012-05-04 23:21 ` redi at gcc dot gnu.org
2012-05-04 23:37 ` dimitrisdad at gmail dot com
2012-05-04 23:37 ` dimitrisdad at gmail dot com
2012-05-05  0:04 ` pinskia at gcc dot gnu.org
2012-05-05  0:15 ` redi at gcc dot gnu.org
2012-05-05  0:49 ` dimitrisdad at gmail dot com

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=bug-53225-4-gzzLQHkPN0@http.gcc.gnu.org/bugzilla/ \
    --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).