emacs-bug-tracker
[Top][All Lists]
Advanced

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

[Emacs-bug-tracker] bug#8496: closed (some file locking code in insert-f


From: GNU bug Tracking System
Subject: [Emacs-bug-tracker] bug#8496: closed (some file locking code in insert-file-contents cannot be right)
Date: Thu, 14 Apr 2011 08:01:02 +0000

Your message dated Thu, 14 Apr 2011 10:00:14 +0200
with message-id <address@hidden>
and subject line Re: bug#8496: some file locking code in insert-file-contents 
cannot be right
has caused the GNU bug report #8496,
regarding some file locking code in insert-file-contents cannot be right
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
8496: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8496
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: some file locking code in insert-file-contents cannot be right Date: Wed, 13 Apr 2011 17:40:49 -0700 User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9
As a result of the "mark unexported symbols 'static'" patch that I'm
working on, in the Emacs trunk I found some file-locking code inside
insert-file-contents that cannot be right:

     if (NILP (visit) && inserted > 0)
       {
   #ifdef CLASH_DETECTION
         if (!NILP (BVAR (current_buffer, file_truename))
             /* Make binding buffer-file-name to nil effective.  */
             && !NILP (BVAR (current_buffer, filename))
             && SAVE_MODIFF >= MODIFF)
           we_locked_file = 1;
   #endif /* CLASH_DETECTION */
         prepare_to_modify_buffer (GPT, GPT, NULL);
       }

The above code is equivalent to a no-op, since 'inserted' must
be zero here.  There's later code:

   #ifdef CLASH_DETECTION
         if (we_locked_file)
           unlock_file (BVAR (current_buffer, file_truename));
   #endif

that is also a no-op, because 'we_locked_file' must be zero.

GCC merrily optimizes all this code away, but I don't think
that was intended.  What *is* intended here?



--- End Message ---
--- Begin Message --- Subject: Re: bug#8496: some file locking code in insert-file-contents cannot be right Date: Thu, 14 Apr 2011 10:00:14 +0200 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)
Paul Eggert <address@hidden> writes:

> What *is* intended here?

If you look at 9a95c4d it is obvious.

Andreas.

-- 
Andreas Schwab, address@hidden
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."


--- End Message ---

reply via email to

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