Re: Modules: definition of emacs_value

[Philipp Stephani <p.stephani2@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]

Daniel Colascione <dancol@dancol.org> schrieb am Di., 1. März 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 be 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 really don't like making
> 32-bit callers cope with 64-bit values.


It's been a while since I did 32-bit programming, but what issues could
arise? We're not doing any arithmetic or other processing on the values,
just passing them around.


> 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.
>

As said above, we're already doing that.

[-- Attachment #2: Type: text/html, Size: 1694 bytes --]