Re: Modules: definition of emacs_value

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

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

Daniel Colascione <dancol@dancol.org> schrieb am Mi., 2. März 2016 um
21:14 Uhr:

> On 03/02/2016 10:30 AM, Philipp Stephani wrote:
> >
> >
> > Daniel Colascione <dancol@dancol.org <mailto: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 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.

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