From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: Modules: definition of emacs_value Date: Thu, 31 Mar 2016 17:32:59 +0000 Message-ID: References: <56D4D127.5020505@dancol.org> <56D74989.1070404@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11407f1ee8481a052f5ba75f X-Trace: ger.gmane.org 1459445609 11046 80.91.229.3 (31 Mar 2016 17:33:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 31 Mar 2016 17:33:29 +0000 (UTC) To: Daniel Colascione , Emacs developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 31 19:33:28 2016 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 1algTH-0004ds-89 for ged-emacs-devel@m.gmane.org; Thu, 31 Mar 2016 19:33:27 +0200 Original-Received: from localhost ([::1]:33582 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1algTG-0007qr-Lm for ged-emacs-devel@m.gmane.org; Thu, 31 Mar 2016 13:33:26 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44632) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1algT1-0007qj-EK for emacs-devel@gnu.org; Thu, 31 Mar 2016 13:33:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1algT0-00088z-Dy for emacs-devel@gnu.org; Thu, 31 Mar 2016 13:33:11 -0400 Original-Received: from mail-lf0-x22b.google.com ([2a00:1450:4010:c07::22b]:34042) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1algSz-00088r-Uc for emacs-devel@gnu.org; Thu, 31 Mar 2016 13:33:10 -0400 Original-Received: by mail-lf0-x22b.google.com with SMTP id c62so64516428lfc.1 for ; Thu, 31 Mar 2016 10:33:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=H4o9XFZyIDy+VoUisnlz7B2EXkl5tQlhRkGuF4hL9zI=; b=wyDEIfdVCcmKvgtOQRJjvY4ZIPCmvRdUT+l1rfY/iypyoo/VJZXf2K3FfKa5eeu6hc YhYZ25pYGGT2Oz22fVzFdjZZIfuYPFzFJcDzU3EDKll2L/p6Ht34xDfbW2ECF2ni/5FO l7nhqzyubqxSdYqpeSQOCeB4I+W5d2bDZEvpBZrW7OghEzcll2sg/BCZWn0axk1i6hsi 6FRSMBwlA1n+IVpiwm24M0iBglCtj1GC1kv+Bn3Yzk0HIo+W/fyj+qojz6mzVsaEkN+W NVf34M87KWczoH57k5eNK4XpfF8r7BZo8576TRXw49rJjy3fQNReV+wh6b0b3W5II0ny ZVGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=H4o9XFZyIDy+VoUisnlz7B2EXkl5tQlhRkGuF4hL9zI=; b=ikdmOrDByPAh/4TyYy8PZfm43Wri77HxRTXNUgNKpnvTbwdDAW4lRI4MxiMyrGg2/m IqBFPal6ExqwGAbsb4gGovKR8k4yGz3WjtXWuYnZIzXiEY4V7QgyTF64/uMEO3V2R+Um n5F8TyLN+1Jqr7sYXmwwYhbx4rEVQCogTfP6IhhhbY9Ay33OMDDXbcWzcgd2NPzVmqt+ rqnWABj0JwZc2Ay3qKSn+0XK8TAY/SEIfx2jhngfVtCw+9dKaOVfz6Ozclliaw7r781U tcxNjxsa50U7D66nyueKd9V2CzqZn1FfoO1JKzYfWOBvQe4cosAgd91CeacSpXKHioSn uPpg== X-Gm-Message-State: AD7BkJIrqpEGkZ2FkX2T87WNHiJPnFkmdve3aaqTn7WrrBAIwq13YTSFYyu1CPgeEcB05zbwQaJ7cJ9bUX1kSQ== X-Received: by 10.25.18.211 with SMTP id 80mr757115lfs.127.1459445589098; Thu, 31 Mar 2016 10:33:09 -0700 (PDT) In-Reply-To: <56D74989.1070404@dancol.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:4010:c07::22b 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:202517 Archived-At: --001a11407f1ee8481a052f5ba75f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Daniel Colascione schrieb am Mi., 2. M=C3=A4rz 2016 um 21:14 Uhr: > On 03/02/2016 10:30 AM, Philipp Stephani wrote: > > > > > > Daniel Colascione > schrie= b > > am Di., 1. M=C3=A4rz 2016 um 00:15 Uhr: > > > > On 02/29/2016 03:03 PM, Philipp Stephani wrote: > > > Is it a strict requirement that emacs_value be a pointer? If not, > > > couldn't we simply define it as int64 and assume that that will b= e > > large > > > enough to hold a Lisp_Object for the foreseeable future? Or do we > > expect > > > Lisp_Object to ever grow beyond 64 bits? > > > > I don't like giving users raw Lisp_Objects. > > > > > > But we are already doing that in most cases (64-bit pointers and > > Lisp_Objects): the pointer is not a real pointer, just a Lisp_Object > > cast to a pointer type. > > I know, and I don't like it. I wish it were a real pointer. > > Me too, but the chance to get that changed seems rather minimal. Given that, we currently have the worst of both worlds: emacs_value is not a real pointer, but still bound by the size of a pointer. Since we won't be able to change emacs_value any more once 25.1 is released, now is the last chance to get its definition changed. --001a11407f1ee8481a052f5ba75f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Daniel= Colascione <dancol@dancol.org&= gt; schrieb am Mi., 2. M=C3=A4rz 2016 um 21:14=C2=A0Uhr:
On 03/02/2016 10:30 AM, Philipp Stephani wrote:
>
>
> Daniel Colascione <dancol@dancol.org <mailto:dancol@dancol.org>> schrieb
> am Di., 1. M=C3=A4rz 2016 um 00:15 Uhr:
>
>=C2=A0 =C2=A0 =C2=A0On 02/29/2016 03:03 PM, Philipp Stephani wrote:
>=C2=A0 =C2=A0 =C2=A0> Is it a strict requirement that emacs_value be= a pointer? If not,
>=C2=A0 =C2=A0 =C2=A0> couldn't we simply define it as int64 and = assume that that will be
>=C2=A0 =C2=A0 =C2=A0large
>=C2=A0 =C2=A0 =C2=A0> enough to hold a Lisp_Object for the foreseeab= le future? Or do we
>=C2=A0 =C2=A0 =C2=A0expect
>=C2=A0 =C2=A0 =C2=A0> Lisp_Object to ever grow beyond 64 bits?
>
>=C2=A0 =C2=A0 =C2=A0I don't like giving users raw Lisp_Objects.
>
>
> But we are already doing that in most cases (64-bit pointers and
> Lisp_Objects): the pointer is not a real pointer, just a Lisp_Object > cast to a pointer type.

I know, and I don't like it. I wish it were a real pointer.


Me too, but the chance to get that cha= nged seems rather minimal.
Given that, we currently have the wors= t of both worlds: emacs_value is not a real pointer, but still bound by the= size of a pointer. Since we won't be able to change emacs_value any mo= re once 25.1 is released, now is the last chance to get its definition chan= ged.=C2=A0
--001a11407f1ee8481a052f5ba75f--