Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Return-Path: <python-python-list@m.gmane.org>
X-Original-To: python-list@python.org
Delivered-To: python-list@mail.python.org
X-Spam-Status: OK 0.000
X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'operator': 0.03; 'subject:: [': 0.04; 'explicitly': 0.05; 'that?': 0.05; 'subject:Python': 0.06; 'compiler': 0.07; 'padding': 0.07; 'result,': 0.07; 'assumed': 0.09; 'override': 0.09; 'received:80.91': 0.09; 'received:80.91.229': 0.09; 'received:gmane.org': 0.09; 'received:list': 0.09; 'runtime': 0.09; 'subject:into': 0.09; 'python': 0.11; 'wrote': 0.14; 'converted,': 0.16; 'element.': 0.16; 'logical,': 0.16; 'malloc': 0.16; 'received:80.91.229.3': 0.16; 'received:plane.gmane.org': 0.16; 'subject:variable': 0.16; 'unnamed': 0.16; 'size,': 0.16; 'wrote:': 0.18; '(not': 0.18; 'things.': 0.19; 'subject:] ': 0.20; 'pointer': 0.24; 'initial': 0.24; 'mention': 0.26; 'least': 0.26; 'header:X-Complaints-To:1': 0.27; 'michael': 0.29; 'array': 0.29; 'points': 0.29; "doesn't": 0.30; 'overhead': 0.31; 'struct': 0.31; 'actual': 0.34; 'convert': 0.35; 'but': 0.35; 'there': 0.35; 'c++': 0.36; 'object,': 0.36; 'surely': 0.36; 'vice': 0.36; 'subject:?': 0.36; 'two': 0.37; 'to:addr:python-list': 0.38; 'does': 0.39; 'quote': 0.39; 'structure': 0.39; 'to:addr:python.org': 0.39; 'received:org': 0.40; 'even': 0.60; 'subject:Can': 0.60; 'new': 0.61; "you're": 0.61; 'first': 0.61; 'address': 0.63; 'different': 0.65; 'within': 0.65; '8bit%:21': 0.69; 'glad': 0.83; 'citation': 0.84; 'skip:\xef 10': 0.84; 'edwards': 0.91
X-Injected-Via-Gmane: http://gmane.org/
To: python-list@python.org
From: Dave Angel <davea@davea.name>
Subject: Re: [OT] Can global variable be passed into Python function?
Date: Sat, 1 Mar 2014 23:02:19 -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>
X-Gmane-NNTP-Posting-Host: dpc6744192186.direcpc.com
X-Newsreader: PiaoHong Usenet NewsReaders 1.36
X-BeenThere: python-list@python.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion list for the Python programming language <python-list.python.org>
List-Unsubscribe: <https://mail.python.org/mailman/options/python-list>, <mailto:python-list-request@python.org?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/python-list/>
List-Post: <mailto:python-list@python.org>
List-Help: <mailto:python-list-request@python.org?subject=help>
List-Subscribe: <https://mail.python.org/mailman/listinfo/python-list>, <mailto:python-list-request@python.org?subject=subscribe>
Newsgroups: comp.lang.python
Message-ID: <mailman.7560.1393732703.18130.python-list@python.org>
Lines: 35
NNTP-Posting-Host: 2001:888:2000:d::a6
X-Trace: 1393732703 news.xs4all.nl 2901 [2001:888:2000:d::a6]:44894
X-Complaints-To: abuse@xs4all.nl
Xref: csiph.com comp.lang.python:67407

 Grant Edwards <invalid@invalid.invalid> Wrote in message:
> On 2014-02-24, Michael Torrie <torriem@gmail.com> wrote:
>
>>
>> Why would you think that? The address of the start of your malloc'ed
>> structure is the same as the address of the first element.  Surely
>> this is logical?
> 
> Not only is it logical, the C standard explicitly requires it.  Here's
> a second-hand citation since I don't happend to have an actual copy of
> the standard on hand:
> 
>     C1x �6.7.2.1.13:
> 
>        A pointer to a structure object, suitably converted, points to
>        its initial member ... and vice versa. There may be unnamed
>        padding within a structure object, but not at its beginning.

The quote you make from the C standard doesn't mention malloc,  so
 you're arguing different things. It's not the compiler that casts
 the malloc return value to the struct type.

C++ does implicitly convert the result,  and the return value of
 new already has the struct type. But the runtime stores at least
 two kinds of overhead on occasion,  the array size, and the
 vtable. So the malloc address can not be assumed to match the
 struct beginning.  (Not even considering that one can override
 operator new at two levels)

Glad python doesn't have any of this mess.


-- 
DaveA