From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: FFI in Emacs Date: Wed, 13 Mar 2013 05:55:49 +0200 Message-ID: <837glcj6m2.fsf@gnu.org> References: <83d2v4jnih.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1363147069 24994 80.91.229.3 (13 Mar 2013 03:57:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 13 Mar 2013 03:57:49 +0000 (UTC) Cc: joakim@verona.se, emacs-devel@gnu.org To: =?utf-8?Q?Aur=C3=A9lien?= Aptel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 13 04:58:09 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 1UFcpM-0004fH-4r for ged-emacs-devel@m.gmane.org; Wed, 13 Mar 2013 04:58:08 +0100 Original-Received: from localhost ([::1]:48638 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UFcoz-0007vw-Sz for ged-emacs-devel@m.gmane.org; Tue, 12 Mar 2013 23:57:45 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:44422) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UFcov-0007vg-3h for emacs-devel@gnu.org; Tue, 12 Mar 2013 23:57:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UFcoq-0007sH-Ez for emacs-devel@gnu.org; Tue, 12 Mar 2013 23:57:41 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:37517) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UFcoq-0007rq-5s for emacs-devel@gnu.org; Tue, 12 Mar 2013 23:57:36 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MJK00400YK0ZP00@a-mtaout23.012.net.il> for emacs-devel@gnu.org; Wed, 13 Mar 2013 05:55:52 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MJK004X4YX4ZN20@a-mtaout23.012.net.il>; Wed, 13 Mar 2013 05:55:52 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.175 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:157813 Archived-At: > Date: Tue, 12 Mar 2013 23:53:28 +0100 > From: Aur=C3=A9lien Aptel > Cc: joakim@verona.se, emacs-devel@gnu.org >=20 > On Tue, Mar 12, 2013 at 10:50 PM, Eli Zaretskii wrot= e: > > Do we really need these libraries? If the Posix hosts can do wit= h > > dlopen, dlsym, dlclose, and dlerror, then it's very easy to emula= te > > that on platforms that don't have these in the system libraries. = What > > else is needed, and why? >=20 > I agree that libltdl is small enough to be re-implemented but you > didn't say why you don't want to use it. Because each additional external library required to build Emacs is more nuisance and complexity for end users, who need to find a compatible version, install it, and know how to tell the compiler to find it. > >> 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 free= ing > > 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 fr= ee > it yourself is not safe on Windows? That seems strange. Daniel explained why it isn't strange. Emacs on Windows does define = a separate heap, to emulate the Posix sbrk and its behavior, see w32heap.c. > > Likewise with file descriptors -- they cannot be safely shared ac= ross > > the interface, because the shared library could have used a diffe= rent > > runtime for opening files. >=20 > If you're talking about read(), it was just an example of a > problematic API (side effects). If you're writing some code to > interface with C I expect you to know what you're doing. Again, Daniel explained that any function that opens a file and any FILE object cannot be passed safely.