Daniel Colascione <
address@hidden> schrieb am So., 4. Okt. 2015 um 21:34 Uhr:
On 10/04/2015 02:41 AM, Philipp Stephani wrote:
> >
> >
> > typedef struct emacs_value_tag* emacs_value;
> >
> >
> > I think it's important that this is a pointer to a struct (for type
> > safety and size correctness) rather than just an arbitrary type.
>
> A typedef is exactly as typesafe. The question of whether to use a
> struct or a typedef is aesthetic. I strongly prefer a typedef, just like
> pthreads, and I believe that the people who advocate using structs
> directly are simply wrong.
>
>
> Ah, I'm not against the typedef, I'm just asking whether you would make
> it part of the API contract that it's a typedef of a struct pointer, or
> whether it can be any type.
The problem with defining it as a pointer type is that NULL is now the
invalid sentinel value, which seems incompatible with both making this
thing literally a Lisp_Object and Qnil having all zero bits.
That's why I strongly prefer making emacs_value a _pointer_ to a
Lisp_Object, where we store the Lisp_Object in an array owned by the
emacs_env. This way, allocating local values is very cheap.
A simple fixed array however puts a fixed upper bound on the number of local values used. That might be undesirable, especially for plugins dealing with large data structures. The simplest unbound allocation mechanism would use an array of emacs_value pointers (emacs_value **) stored in the environment object; the array itself and its elements would be allocated using malloc as usual, and the array would be grown using realloc. However, that requires lots of allocations (at least one per local object used) and could make a more complex allocator necessary.