Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!newsfeed.xs4all.nl!newsfeed2a.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
To: python-list@python.org
From: Dave Angel <davea@davea.name>
Subject: Re: [OT] Can global variable be passed into Python function?
Date: Sun, 2 Mar 2014 14:17:41 -0500 (EST)
Organization: news.gmane.org
References: <27ac2248-0ca3-4ba6-9d25-eaad324bc5e9@googlegroups.com> <87sird7wuw.fsf@handshake.de> <le7fso$a83$1@ger.gmane.org> <8454E8CB-E6E3-452F-8E54-9A77BFF34EC2@gmail.com> <1m3gg9lbf2ln5m2kbki954t17mqni3b20k@4ax.com> <mailman.7262.1393078476.18130.python-list@python.org> <53095145$0$29985$c3e8da3$5496439d@news.astraweb.com> <877g8mcg1m.fsf@elektro.pacujo.net> <mailman.7286.1393151578.18130.python-list@python.org> <87ob1yay9m.fsf@elektro.pacujo.net> <08aa32de-cd51-4888-bd60-2c2b53d86ecc@googlegroups.com> <mailman.7319.1393265975.18130.python-list@python.org> <leg7au$ckp$2@reader1.panix.com> <leua81$fjj$1@ger.gmane.org> <CAPTjJmpeLq_7R=Z5J14dpny6XJ0xx-8CnueMJ02pcnDsULZTdg@mail.gmail.com> <levb36$jmk$1@ger.gmane.org> <CAPTjJmrCXrqZzCrvWm7Bb0yG3wDge=kheLL4w83W79MQ4XKGdg@mail.gmail.com>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.7590.1393787621.18130.python-list@python.org>
Lines: 89
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:67460

 Chris Angelico <rosuav@gmail.com> Wrote in message:
> On Mon, Mar 3, 2014 at 12:22 AM, Dave Angel <davea@davea.name> wrote:
>> Sure,  for some definition of "usable".  Overhead such as block
>>  size, freelist pointer etc., are obviously outside of the
>>  returned block.  But the array size that's specified in a call to
>>  new [], and the vptr, are definitely inside the malloc'ed block,
>>  and may be before the struct data.
> 
> Hmm. Last I was working with it, the array size to new[] was outside
> the block, just as the block size to malloc(). The vptr is part of any
> struct/class with virtual functions, and effectively acts as a hidden
> class member, so you get one of those inside the block, and it's
> included in sizeof.
> 
> //Allocated Space: The Final Frontier!
> #include <stdio.h> //cout sucks :)
> 
> class Foo
> {
>     int x;
>     int y;
>     int z;
> };
> 
> class Bar
> {
>     int x;
>     int y;
>     int z;
>     virtual int get_x() {return x;}
> };
> 
> int main()
> {
>     printf("sizeof(int) = %u\n",sizeof(int));
>     printf("sizeof(int*) = %u\n",sizeof(int*));
>     printf("sizeof(Foo) = %u\n",sizeof(Foo));
>     printf("sizeof(Bar) = %u\n",sizeof(Bar));
>     Foo *foo = new Foo[10];
>     printf("foo = %p/%p = %u\n",foo,foo+10,(char *)(foo+10)-(char *)foo);
>     Bar *bar = new Bar[10];
>     printf("bar = %p/%p = %u\n",bar,bar+10,(char *)(bar+10)-(char *)bar);
>     return 0;
> }
> 
> 
> rosuav@sikorsky:~$ g++ frontier.cpp && ./a.out
> sizeof(int) = 4
> sizeof(int*) = 8
> sizeof(Foo) = 12
> sizeof(Bar) = 24
> foo = 0xf38010/0xf38088 = 120
> bar = 0xf38090/0xf38180 = 240
> 
> 
> 
> The rules of structs are that they be contiguous, that they be laid
> out sequentially, and that any padding needed between structures is at
> the end of the previous one (which is why three of 4 bytes makes 12
> bytes, but three of 4 bytes plus 8 bytes makes 24 - the eight-byte
> pointer has to be aligned on a multiple of eight bytes, so having a
> 20-byte structure that starts with an 8-byte pointer is a no-no). The
> allocated block of memory is, by definition, the same as the pointer
> to its first element. As it happens, the pointer bar is not synonymous
> with &bar->x, &bar->y, or &bar->z, which means the vptr is at the
> beginning of bar, which makes sense; but the compiler's not obliged to
> do that, and in some cases may choose not to - for instance, if bar
> (with a virtual function) inherited from foo (with none), it might be
> convenient to allow a pointer-cast to not change the value of the
> pointer. (g++ 4.7.2 still puts the vptr at the beginning of bar in
> that case, but other compilers or other versions may differ.)
> 
> Array size is outside the block, presumably before it, as &foo[0] is
> by definition identical to foo, and there's no room inside the
> structure for any spare data. Virtual function table is inside the
> block because it's a hidden member of the object (like __class__ in
> Python, only better hidden).
> 

Array size is inside the malloc block, but outside the struct
 block.  As you can see if you try to delete without the brackets
 when you used new [], some runtimes will crash. 

This is not to say that there will always be these extra offsets, 
 just that they can be there.

-- 
DaveA