[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Modules: definition of emacs_value

From: Philipp Stephani
Subject: Re: Modules: definition of emacs_value
Date: Wed, 02 Mar 2016 18:30:08 +0000

Daniel Colascione <address@hidden> 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. 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]