Path: csiph.com!usenet.pasdenom.info!aioe.org!news.stack.nl!newsfeed.xs4all.nl!newsfeed4a.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Return-Path: 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; 'subject:: [': 0.04; 'subject:Python': 0.06; 'compiler': 0.07; 'result,': 0.07; '[],': 0.09; '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; 'sure,': 0.09; 'wrote': 0.14; 'block.': 0.16; 'malloc': 0.16; 'received:80.91.229.3': 0.16; 'received:plane.gmane.org': 0.16; 'subject:variable': 0.16; 'size,': 0.16; 'wrote:': 0.18; '(not': 0.18; 'obviously': 0.18; 'things.': 0.19; 'subject:] ': 0.20; 'pointer': 0.24; 'space.': 0.24; 'mention': 0.26; 'least': 0.26; 'header:X-Complaints-To:1': 0.27; 'function': 0.29; 'chris': 0.29; 'array': 0.29; "doesn't": 0.30; 'returned': 0.30; 'specified': 0.30; 'block,': 0.31; 'overhead': 0.31; 'struct': 0.31; 'beginning': 0.33; 'table': 0.34; 'convert': 0.35; 'definition': 0.35; 'etc': 0.35; 'but': 0.35; 'c++': 0.36; 'subject:?': 0.36; 'virtual': 0.37; 'two': 0.37; 'whatever': 0.38; 'to:addr:python- list': 0.38; 'pm,': 0.38; 'does': 0.39; 'quote': 0.39; 'to:addr:python.org': 0.39; 'received:org': 0.40; 'even': 0.60; 'dave': 0.60; 'subject:Can': 0.60; 'new': 0.61; "you're": 0.61; 'address': 0.63; 'such': 0.63; 'different': 0.65; 'mar': 0.68; 'angel': 0.91 X-Injected-Via-Gmane: http://gmane.org/ To: python-list@python.org From: Dave Angel Subject: Re: [OT] Can global variable be passed into Python function? Date: Sun, 2 Mar 2014 08:22:57 -0500 (EST) Organization: news.gmane.org References: <27ac2248-0ca3-4ba6-9d25-eaad324bc5e9@googlegroups.com> <87sird7wuw.fsf@handshake.de> <8454E8CB-E6E3-452F-8E54-9A77BFF34EC2@gmail.com> <1m3gg9lbf2ln5m2kbki954t17mqni3b20k@4ax.com> <53095145$0$29985$c3e8da3$5496439d@news.astraweb.com> <877g8mcg1m.fsf@elektro.pacujo.net> <87ob1yay9m.fsf@elektro.pacujo.net> <08aa32de-cd51-4888-bd60-2c2b53d86ecc@googlegroups.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 27 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1393766338 news.xs4all.nl 2846 [2001:888:2000:d::a6]:56196 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:67436 Chris Angelico Wrote in message: > On Sun, Mar 2, 2014 at 3:02 PM, Dave Angel wrote: >> 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 > > Whatever pointer malloc returns is the beginning of the *usable* > space. Any overhead for array size etc has to be before that; a > virtual function table pointer would be inside that space, but that's > very much compiler-dependent. > 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. -- DaveA