Re: [Emacs-diffs] emacs-25 3eb93c0: Rely on conservative stack scanning to find "emacs_value"s

[Daniel Colascione]

On 03/30/2016 11:42 AM, Paul Eggert wrote:
> On 03/30/2016 11:26 AM, Philipp Stephani wrote:
>>
>>     It's not clear that this feature is worth the hassle of supporting
>> it.
>>
>>
>> If emacs_value* were a real pointer, then the feature would come for
>> free.
> 
> This is begging the question, no? There are good reasons to be
> suspicious of null values, regardless of whether they are represented by
> null pointers or by something else.

And there are good reasons to want unambiguous sentinels. See "in-band
signaling" under "awful ideas that should already be dead, but aren't".

> 
>>     As Stefan mentioned, one can easily use Qnil etc. as sentinels.
>>
>>
>> These aren't sentinels because functions can return nil without
>> existing non-locally.
> 
> If there is a need for C code to return a value that is either an Emacs
> value or something else, then a cleaner way to specify this is as some
> sort of discriminated union that is either an Emacs value, or something
> else.

A handle indirection serves exactly this purpose.

> Attempting to shoehorn an "I'm not an Emacs value!" value into the
> emacs_value type leads to unnecessary confusion. 

It doesn't in Java, which uses precisely the approach Philipp and I prefer.

> At least, any such
> union type should be called "emacs_value_option", or something like
> that, to clearly warn the maintainer that the type is an Emacs value or
> is something else.

Oh, come on. That's like saying malloc should return
memory_or_something_t and not void*. This isn't Rust.


>> XCAR etc. certainly can't be avoided. We should try to reduce
>> undefined behavior though, not add more.
>>
> 
> Yes, there are good arguments against the XCAR etc. approach that is
> used throughout the Emacs interpreter. However, there are also good
> arguments for the approach, and the current Emacs design clearly uses
> and assumes it and it works well enough in practice to overcome the
> mostly-theoretical objections raised in this thread. Regardless of the
> implementation strategy chosen by the Emacs core, it's better if the
> module system lives in harmony with the Emacs interpreter instead of
> attempting to fight against it.

An indirection table in no way fights against the interpreter. In fact,
it makes life better for the interpreter, since if raw Lisp_Value
objects are no longer public, the interpreter has fewer constraints
under which it must operate.

signature.asc
Description: OpenPGP digital signature