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: Mon, 29 Feb 2016 15:15:51 -0800 Message-ID: <56D4D127.5020505@dancol.org> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xbpgLIbaj6sF8JHHblRN3SbU0XHOsqD98" X-Trace: ger.gmane.org 1456787771 26369 80.91.229.3 (29 Feb 2016 23:16:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 29 Feb 2016 23:16:11 +0000 (UTC) To: Philipp Stephani , Emacs developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 01 00:16:10 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 1aaX2w-0006M4-JX for ged-emacs-devel@m.gmane.org; Tue, 01 Mar 2016 00:16:10 +0100 Original-Received: from localhost ([::1]:39605 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaX2w-0008Mj-0O for ged-emacs-devel@m.gmane.org; Mon, 29 Feb 2016 18:16:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43697) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaX2s-0008LW-B3 for emacs-devel@gnu.org; Mon, 29 Feb 2016 18:16:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aaX2r-0005Cx-IJ for emacs-devel@gnu.org; Mon, 29 Feb 2016 18:16:06 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:59902) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaX2r-0005AR-8C for emacs-devel@gnu.org; Mon, 29 Feb 2016 18:16:05 -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=6rN5aV1RPuj9Cv1TvYd5lf3VM8Lp4CxXXSL3ddKctj4=; b=Fcf2Xvpkp/KP1jap2jFpARasEjYpeN08K3lTcYuUJtg+rymRTR+Dd83xiS7EA6Xfx6SHmxro27dqCcMtN9A5Zre489LDu8faNM3awSmp/1KePt4nraD96vlFehK6Pu1n9tgvnh1wdcvgRQmFRJTdixVmluKT9vBp1N+aEftMnw1e14WL6G1nvrIGYmrd5JunzLqlMgPp7BiLonl0sXOygI3A7LmHkNcyyq8AQz9Kp9ltHgG/UBDf6RSXZUCu6r4nsDbXM1EFtqVTKtSJqCfBpRTg6u69zUtW9BW+K3Cn8TnjhHVkH6DvlcVEFsVNFhQY4qDdxFtB+aiRTUQayvBi2w==; Original-Received: from [2620:10d:c090:200::c:4c90] (helo=[IPv6:2620:10d:c083:10fb:2ab2:bdff:fe1c:db58]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1aaX2k-0006sQ-7W; Mon, 29 Feb 2016 15:15:58 -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:200832 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xbpgLIbaj6sF8JHHblRN3SbU0XHOsqD98 Content-Type: multipart/mixed; boundary="0Wx1oEML1JVhp820BoQXoDJe101drMVlC" From: Daniel Colascione To: Philipp Stephani , Emacs developers Message-ID: <56D4D127.5020505@dancol.org> Subject: Re: Modules: definition of emacs_value References: In-Reply-To: --0Wx1oEML1JVhp820BoQXoDJe101drMVlC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 be larg= e > enough to hold a Lisp_Object for the foreseeable future? Or do we expec= t > Lisp_Object to ever grow beyond 64 bits? I don't like giving users raw Lisp_Objects. I really don't like making 32-bit callers cope with 64-bit values. If emacs_value is a pointer, we have complete freedom with respect to runtime behavior. Putting a Lisp_Object directly in an emacs_value is a false economy. --0Wx1oEML1JVhp820BoQXoDJe101drMVlC-- --xbpgLIbaj6sF8JHHblRN3SbU0XHOsqD98 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 iQIcBAEBCAAGBQJW1NEoAAoJEN4WImmbpWBlF6wQAKYFPXdX8oWP4kHo/mlpn4/Y SBdmepxZXKHNd/KlJ4VhkhvwtDKojHEdxkipNd0yGcxKkBp+bH7CrFSOkVQdwZ95 zsRhlZctRzLf9t0+hbjhBcSE3/zRNZdvMtbazwFIXT+p1zyGbinu6/rPt49HEFjw QZSlTdQOnwPoVyYzqE93whlvsnTmn8sH6zr8EkRjNF/CBdRoeJgu82j8m+kza0Ud iyOLl6GnUbm5aIaDmrU2J96t+6ux17HMCDmxD44VkYVJyRbNWb7ODChIDxxeEQSu QTl8msDX1GhPjtIL0oive8enLdtCD7cp1OOkZjYA3TATEMMKBVOOUP8xXRRHEbgu H/hoy8pZyMqffyjeDqjaokObsWAPzToW81TI/GaoRS+IFonCakb0Qs+eaFaKd9ey Dswz4cg5DIuj97UYivlE+crYnPwL7Ct23goJs5H/zX2HmtDUviefCG/G581weazK x3IULCixfCNFN2zEiPF7VK8pAJlPXJZT3ICfNs4QVYWZceMVGPc0tEFWmA8STeJ4 vfAuYngzvmZ8dvnH0eGfFhhJPadgsiZb+qJYW8ryqYuZ36w6ivP+ijkfgEdBOL49 PmBynNN895MA+x21ikgLkuimMKjL1xeVbdCDxEPN+5b3EtHNFfbgbmc2cSq5AztQ jHsDJL2Y6fGyBIROpAak =ILi1 -----END PGP SIGNATURE----- --xbpgLIbaj6sF8JHHblRN3SbU0XHOsqD98--