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: Modules: definition of emacs_value Date: Wed, 2 Mar 2016 12:14:01 -0800 Message-ID: <56D74989.1070404@dancol.org> References: <56D4D127.5020505@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lipXMNKrMLqChkjTkXbuDWd0kTnK23LUA" X-Trace: ger.gmane.org 1456949672 9432 80.91.229.3 (2 Mar 2016 20:14:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 2 Mar 2016 20:14:32 +0000 (UTC) To: Philipp Stephani , Emacs developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 02 21:14:25 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 1abDA7-00035t-Qn for ged-emacs-devel@m.gmane.org; Wed, 02 Mar 2016 21:14:23 +0100 Original-Received: from localhost ([::1]:58757 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1abDA7-0007oM-7E for ged-emacs-devel@m.gmane.org; Wed, 02 Mar 2016 15:14:23 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56375) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1abDA1-0007jS-RA for emacs-devel@gnu.org; Wed, 02 Mar 2016 15:14:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1abD9y-0003wE-Kx for emacs-devel@gnu.org; Wed, 02 Mar 2016 15:14:17 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:33808) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1abD9y-0003uX-90 for emacs-devel@gnu.org; Wed, 02 Mar 2016 15:14:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=Bm6hecQII3eVvX6oEFpHJT0jNuzwM2gYvfEr+jz09JQ=; b=Dux9grFMxX9rxLxFDzjRlQJQ3ssnnaviWIFLQpJUxgwM4+87jyuq7b1n9WYL1jPX+mCuWe71BoVTUtCmjsPHV3iM2SgIn+BQ3gXCKHH4i+Z4SfTBWG8MAcVEUeXD3ml80LF6leW5ixoeV2hhz1tBEfaJLqFBqufI1DNhY3LkxlO8UpEX4pkI6HCNO3jyn3Gj6H6NtD5ggR7zWmW8QtuskGBE/TyZ3Of52tj33Yx+3y5jNd92iMP309/qPNvMsfS0QoletCLx89ad8z+JoBAjnYp525UnZwsInrmSWcPoBUclf7TeCclpLwaH/+QtqqMunICTMbjmao9h/MTCus2zPg==; Original-Received: from c-67-161-115-4.hsd1.wa.comcast.net ([67.161.115.4] helo=[192.168.1.210]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1abD9q-0003We-1g; Wed, 02 Mar 2016 12:14:06 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. 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:200872 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lipXMNKrMLqChkjTkXbuDWd0kTnK23LUA Content-Type: multipart/mixed; boundary="a4DmAtWvH62Q1fQSr1WrUcahcIkkBHvWJ" From: Daniel Colascione To: Philipp Stephani , Emacs developers Message-ID: <56D74989.1070404@dancol.org> Subject: Re: Modules: definition of emacs_value References: <56D4D127.5020505@dancol.org> In-Reply-To: --a4DmAtWvH62Q1fQSr1WrUcahcIkkBHvWJ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/02/2016 10:30 AM, Philipp Stephani wrote: >=20 >=20 > Daniel Colascione > schrie= b > am Di., 1. M=C3=A4rz 2016 um 00:15 Uhr: >=20 > 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? >=20 > I don't like giving users raw Lisp_Objects.=20 >=20 >=20 > 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. --a4DmAtWvH62Q1fQSr1WrUcahcIkkBHvWJ-- --lipXMNKrMLqChkjTkXbuDWd0kTnK23LUA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJW10mJAAoJEN4WImmbpWBleXYP/j6wPqRutJvbwjCGy2R8zBZS oda0Lb64BUmH7zodvBRs7RXh9/0E+C3U34OZBgsbzHohXjW93IIrSgmNGO4vmF1g dO6UntsAHZnoMb0EK8qmMUHO9RiUgazKH6pUYCdz87QIo97HaqDj0h6WFHSt1HDc /VYLCJgwwsgTxB9F3yWaaXIyh39f4as4fNQGYfw4Vljg4ZwKVZqStq0sNL7uZFJg YY1lLtfb1eqPl2+qUreABFl6RO5Hl0GQGE7ekFxlun60tJqyHKbmajsRbeeMen8L mTqMgRAuauc3SFkginaFECqcPctuPmSkXjTg0vjb5Ar9UgV3H2fWR3xliPjEIAPF rxC9WFFSAjIi4D9+RfW52MjIatyzyk08iG6j7njxRcHae2EFaHhhRQpCiJuj6KWa ICevbAzdlbtrrvanPQWUXO699Wvqn/NIglRri1J+n7CnCdgwfnN3rmeYAD8LsqI0 ib5jJK3YAD9/sM4e05NKbv5CaOXvoNJ9oq5f07Tu0hozHiGdSGleuHMQzqVy6J7l DZ7akhJmENbBg8r9QDqWOMU2Xamv2ldxaj5nStg1tNv4k4w/YqiqoAucX4MeYkPO U29ITxnJxZaLh7qVhTGr5dvMqyj/v749nvI2OsVLvThmMCmy7gMyYv2srMhl0s0v E9Bq/V3kmMpFF1AX/wE8 =uh4J -----END PGP SIGNATURE----- --lipXMNKrMLqChkjTkXbuDWd0kTnK23LUA--