From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: FFI in Emacs Date: Tue, 12 Mar 2013 17:31:11 -0700 Message-ID: <513FC8CF.8030600@dancol.org> References: <83d2v4jnih.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2TBEIRNMCUERPNSKGMBUR" X-Trace: ger.gmane.org 1363134704 23361 80.91.229.3 (13 Mar 2013 00:31:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 13 Mar 2013 00:31:44 +0000 (UTC) Cc: Eli Zaretskii , joakim@verona.se, emacs-devel@gnu.org To: =?UTF-8?B?QXVyw6lsaWVuIEFwdGVs?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 13 01:32:08 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UFZbu-0005HH-W8 for ged-emacs-devel@m.gmane.org; Wed, 13 Mar 2013 01:32:03 +0100 Original-Received: from localhost ([::1]:43264 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UFZbY-0000cR-Ld for ged-emacs-devel@m.gmane.org; Tue, 12 Mar 2013 20:31:40 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:34366) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UFZbU-0000cM-Io for emacs-devel@gnu.org; Tue, 12 Mar 2013 20:31:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UFZbO-0007Lf-BT for emacs-devel@gnu.org; Tue, 12 Mar 2013 20:31:36 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:35499) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UFZbH-0007KF-1t; Tue, 12 Mar 2013 20:31:23 -0400 Original-Received: from c-76-22-66-162.hsd1.wa.comcast.net ([76.22.66.162] helo=[0.0.0.0]) by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UFZb9-0006is-DI; Tue, 12 Mar 2013 17:31:15 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 In-Reply-To: X-Enigmail-Version: 1.5.1 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:157805 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2TBEIRNMCUERPNSKGMBUR Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 3/12/2013 3:53 PM, Aur=C3=A9lien Aptel wrote: >>> a) a function can allocate memory that has to be freed >> >> At least on Windows, this cannot be done safely, so please don't >> design the interface based on the assumption this is doable. If a >> shared object allocates memory, it should be responsible for freeing >> it, or provide an API for telling it to free it. >=20 > I'm not sure I understand. You're saying that freeing a pointer > returned by a library function which explicitly says you have to free > it yourself is not safe on Windows? That seems strange. Free using which heap? It's common for different modules in a Windows pro= cess to use entirely different C runtime libraries. On Windows, all inter-module dependencies are (module, symbol) pairs (written "module!symbol"), not ju= st bare symbol names as on ELF systems. That is, modA!fun1 calling modB!fun2 can = exist in the same process as a modC!fun1 calling modD!fun2. One module's malloc= isn't necessarily (and often isn't) the same as another module's malloc. It's a= lso common for Windows programs to allocate memory off private heaps, althoug= h that's discouraged these days for performance reasons. There's nothing stopping a POSIXish program from using multiple heaps eit= her, but due to tradition and the way ELF dynamically binds symbols, you're li= kely to see most parts of a typical more programs tend to just use the system lib= c. It's good practice, though, on both Windows and POSIXish systems, to provide a= function resource-specific (or at least module-specific) deallocation fun= ctions. It's just that if you don't follow this advice under Windows, heap corrup= tion shoots you in the face. (Incidentally, one of the challenges of writing Python loadable modules f= or Windows is that Python is written with the assumption that all parts of t= he program share the same libc, so if foo.pyd isn't linked to precisely the = same version of the C runtime that python27.dll is linked to, things go wrong = very quickly.) Sometimes Windows library specify that memory is allocated on the "proces= s heap". The process heap is provided by ntdll.dll and functions more like = a Posixish system's libc heap in that it's shared by all parts of a process= ; see HeapAlloc and HeapFree. Likewise, you can't share file descriptors or FIL= E* pointers between different modules under Windows, but you *can* share HAN= DLEs, since HANDLEs are universal and managed by the kernel. ------enig2TBEIRNMCUERPNSKGMBUR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (Cygwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlE/yNIACgkQ17c2LVA10VsC7gCfbcsD8vWJ7zJYcHvfGWF9lhhi 1b4AoLuReSl7b5Nxm6DGJDxPyk4D3Jrb =9bIv -----END PGP SIGNATURE----- ------enig2TBEIRNMCUERPNSKGMBUR--