[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109327: Generalize INTERNAL_FIEL

From: Stefan Monnier
Subject: Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109327: Generalize INTERNAL_FIELD between buffers, keyboards and frames.
Date: Fri, 03 Aug 2012 18:50:29 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

>>> the barrier (just one such a store is fatal for the collector). Next,
>>> when we will know that the collector invariant is never broken, it's
>>> possible to replace these obfuscated FVAR (x, y) back to x->y.
>> You can use coccinelle to automatically turn the x->y into an rvalue
>> FVAR (x,y) while debugging.  And such a script should be kept around and
>> run every once in a while to check that new code follows the
>> SETFVAR convention.
>> But I don't want the trunk's code obfuscated just for some temporary
>> debugging needs.
> Have you tried to use coccinelle? As I have said, it's not a silver bullet
> (yet), and it's just impossible to handle such a stuff in fully automated
> mode.  There are special cases that should be handled manually, and doing
> them over and over again is much worse than even an endless merging.

If we want to use "foo->bar" in the end code, then we will need to solve
this problem anyway (since, as mentioned, we'll need to check every once
in a while that "foo->bar" is only used for rvalues).

> And I still don't see an answer to the simplest possible question: why
> (F|W)VARs are so bad but (B|K)VARs are OK?

I don't actually think that BVAR/KVAR are OK either.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]