Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109327: Generalize INTERNAL_FIELD between buffers, keyboards and frames.

[Dmitry Antipov <dmantipov@yandex.ru>]

On 08/06/2012 02:54 PM, Stefan Monnier wrote:

> I want the C part of Emacs to look like C code.  So, if the
> structure-field access does not require extra machinery (i.e. no read
> barrier), I want to write it "foo->bar".

I (and I hope all others) too. But we do AREF and ASET for vectors,
thinking about that vector implementation may be changed so direct access
to 'contents' becomes invalid or nonsense. So, I think that xGET and xSET
for complex structures fits this approach and don't add too much obfuscation.

Moreover, C itself is not designed to provide GC, and GC-aware system is
"unusual" C program. So, I don't see a problem if such a program contains
some "unusual" constructs which aren't quite similar to a core language.
Оn the contrary, this sets a good point for a newcomer: "look at these
strange things, they're implemented in a such unusual way because they're
really important, you should understand it before you write something".

> If we want to make sure that the write-barrier is used everywhere where
> it's needed, than we need to find a way to check this with some tool.
> Such a tool might require some extra annotations in the source code, and
> I'm willing to accept some such things, but I'd much rather avoid
> "FVAR (foo, bar)" if at all possible.
>
> If tools like coccinelle have trouble finding the right "foo->bar", then
> maybe we can try to find some coding convention that helps coccinelle
> find the right spots.  Or find some other tool that can do those checks
> for us.

Development (and politics) is the art of the possible, and we have those
tools which are. I investigated this area, and I believe that coccinelle
is good enough to be used in our work; finally, I don't see the practical
reasons to wait until someone develops a wunderwaffe like GCC plugin
for automatic barrier insertion on any critical pointer stores.

Dmitry