From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Lisp object that refers to a C struct Date: Fri, 19 Oct 2012 10:44:32 -0400 Message-ID: References: <83ehkz4edw.fsf@gnu.org> <83bog33wdr.fsf@gnu.org> <837gqq49j7.fsf@gnu.org> <83r4ox3frd.fsf@gnu.org> <83ipa92i95.fsf@gnu.org> <83bog03jyf.fsf@gnu.org> <507F2C74.4070107@cs.ucla.edu> <83391c2xjq.fsf@gnu.org> <83wqyo1129.fsf@gnu.org> <83sj9b1z1i.fsf@gnu.org> <83bofz0w7q.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1350657896 2802 80.91.229.3 (19 Oct 2012 14:44:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 19 Oct 2012 14:44:56 +0000 (UTC) Cc: lekktu@gmail.com, eggert@cs.ucla.edu, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 19 16:45:03 2012 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 1TPDor-0002lY-EO for ged-emacs-devel@m.gmane.org; Fri, 19 Oct 2012 16:45:01 +0200 Original-Received: from localhost ([::1]:49726 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TPDok-0002AU-BP for ged-emacs-devel@m.gmane.org; Fri, 19 Oct 2012 10:44:54 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:55678) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TPDob-0002A6-Hb for emacs-devel@gnu.org; Fri, 19 Oct 2012 10:44:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TPDoZ-0003cN-43 for emacs-devel@gnu.org; Fri, 19 Oct 2012 10:44:45 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:49446) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TPDoY-0003bM-Ul; Fri, 19 Oct 2012 10:44:43 -0400 Original-Received: from faina.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id q9JEiWw2031382; Fri, 19 Oct 2012 10:44:32 -0400 Original-Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id BA77CB40A1; Fri, 19 Oct 2012 10:44:32 -0400 (EDT) In-Reply-To: <83bofz0w7q.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 19 Oct 2012 09:14:49 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4376=0 X-NAI-Spam-Version: 2.2.0.9309 : core <4376> : streams <841324> : uri <1247200> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 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:154443 Archived-At: >> > It doesn't. I meant the need to manage the table itself, grow it when >> > needed, etc. >> To me "table" doesn't imply "array". It's just some kind of >> data-structure that keeps the elements at hand. It can be a list, an >> array, a tree, a has-table, you name it. > If we use a Lisp data structure, then the same issue of putting a bare > pointer into that started this thread it pops up again, doesn't it? > Anyway, a Lisp data structure is what I have now. In any case, the code now does keep a table of those C structs, and they are not reclaimed when the Lisp code loses the last "handle". Instead they are only reclaimed when the Lisp code calls remove-watch explicitly. This design means we don't need a "finalizer" (i.e. code in gc_sweep that calls us back to free the C struct), but it also means that we may "leak" those C structs if the Lisp code just forgets to `remove-watch'. I think that's OK for now. >> > Call w32_valid_pointer_p, and in addition verify that the struct >> > pointed to by it has the correct magic signature. >> Why is that needed? > To make sure we never dereference a pointer that doesn't point to the > watch object. Since the remove-watch API accepts a Lisp integer, it > could be called with any arbitrary integer value. But as long as the table is not corrupted, there's no risk of such a thing happening anyway. > IOW, I don't want to crash, even if somehow a bad pointer is found in > the alist described below. OK, so it's just done out of paranoia. That's fine, but please make it clear in the code, e.g. by placing it in an eassert. > As I wrote, the reason for this design of the alist was to be 100% > compatible with what R=FCdiger did. Otherwise, I could keep CALLBACK in > the C struct as well, for example. I think it's OK. Encoding C pointers in Lisp integers is pretty ugly, so we should make sure that no part of the design depends on it (so it can be changed in the future) and we should also make it very clear in the doc that Elisp code should not rely on those handles being integers (treat them as black boxes instead). Stefan