GNU bug report logs - #8496
some file locking code in insert-file-contents cannot be right

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#8496: closed (some file locking code in insert-file-contents
 cannot be right)
Date: Thu, 14 Apr 2011 08:01:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Thu, 14 Apr 2011 10:00:14 +0200
with message-id <m3k4ex6z5d.fsf <at> linux-m68k.org>
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
help-debbugs <at> gnu.org.)


-- 
8496: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8496
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: bug-gnu-emacs <at> gnu.org
Subject: some file locking code in insert-file-contents cannot be right
Date: Wed, 13 Apr 2011 17:40:49 -0700

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?

[Message part 3 (message/rfc822, inline)]

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 8496-done <at> debbugs.gnu.org
Subject: Re: bug#8496: some file locking code in insert-file-contents cannot
	be right
Date: Thu, 14 Apr 2011 10:00:14 +0200

Paul Eggert <eggert <at> cs.ucla.edu> writes:

> What *is* intended here?

If you look at 9a95c4d it is obvious.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.