Paul Eggert <
address@hidden> schrieb am So., 22. Nov. 2015 um 00:25 Uhr:
Philipp Stephani wrote:
> I honestly can't think of a situation where version checking would work but
> size checking wouldn't.
For example, a structure contains an off_t value, and time_t grows from 32 to
64-bits. The designer knew this might be a problem because of Y2038 issues, and
so created padding for the time_t to grow into.
Another example: suppose we change ptrdiff_t back to int.
Such issues are why we generally prefer fixed-size integers.
Currently the structures contain only pointers and pointer-sized integers. If we are careful to keep it that way, sizes can only ever increase.
Another example: suppose we want the same module to work in both narrow and wide
int Emacs, so we allocate storage for wide integers even though half of them are
not used in narrow platforms.
The module interface never exposes Lisp_Objects directly, so it's immune to such considerations.
What you're saying, if I understand it, is that we promise that we'll never make
any changes like that. This sounds overly constraining, at least for now.
Not really, because there are no cases where we'd need to e.g. expose an off_t field. We only need three types of fields:
- A field for version checking (size should be reasonably fixed)
- A pointer-sized field pointing to private data (size is fixed within a single address space)
- Function pointer fields for interacting with Emacs (size is fixed within the address space)
If we ever need to expose an off_t value, it will be in the form of another function pointer.
Even if, for whatever reason, we must expose an off_t value directly, we can insert appropriate padding to make sure the size increases.
While the interface is experimental we'll retain the freedom to make arbitrary
changes to it. When it settles down we can think about promises about never ever
making changes in the future. In the meantime the size field is experimental and
maybe we'll think of uses for it other than sizes.
The module interface is supposed to be stable at least for the lifetime of Emacs 25. At least from our side it's not meant to be experimental.