From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Changes in update-game-score.c Date: Thu, 23 Jan 2014 05:52:29 +0200 Message-ID: <8338kffj7m.fsf@gnu.org> References: <8361pbg5vy.fsf@gnu.org> <52E08D31.3080801@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1390449145 16635 80.91.229.3 (23 Jan 2014 03:52:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 23 Jan 2014 03:52:25 +0000 (UTC) Cc: emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 23 04:52:30 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W6BLB-0005kI-FW for ged-emacs-devel@m.gmane.org; Thu, 23 Jan 2014 04:52:29 +0100 Original-Received: from localhost ([::1]:38794 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6BLA-0004iN-SY for ged-emacs-devel@m.gmane.org; Wed, 22 Jan 2014 22:52:28 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33490) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6BL3-0004de-M4 for emacs-devel@gnu.org; Wed, 22 Jan 2014 22:52:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W6BKy-000747-Hj for emacs-devel@gnu.org; Wed, 22 Jan 2014 22:52:21 -0500 Original-Received: from mtaout27.012.net.il ([80.179.55.183]:55036) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6BKy-00073O-9F for emacs-devel@gnu.org; Wed, 22 Jan 2014 22:52:16 -0500 Original-Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0MZU00A004GYSS00@mtaout27.012.net.il> for emacs-devel@gnu.org; Thu, 23 Jan 2014 05:51:37 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MZU007JU5E1JX60@mtaout27.012.net.il>; Thu, 23 Jan 2014 05:51:37 +0200 (IST) In-reply-to: <52E08D31.3080801@cs.ucla.edu> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.183 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:168927 Archived-At: > Date: Wed, 22 Jan 2014 19:32:01 -0800 > From: Paul Eggert > CC: emacs-devel@gnu.org > > Eli Zaretskii wrote: > > Why do we suddenly care about it so much? > > We got a bug report about it, which I fixed, and I noticed some other > bugs in the neighborhood, including undefined behavior and race > conditions which are dicey in a setuid program (it's bad PR at the very > least). A feature freeze shouldn't prevent us from fixing such bugs. The bugfix should have fixed the bug that was reported, and that's it. Even the first bugfix was already too much (you said it yourself: fancy). The rest is just superfluous and unneeded, as the program is not important enough for us to waste any time on it. (Why isn't it implemented in Lisp, anyway?) > The main culprit here was the w32 port's definition of fchmod as a noop > for Emacs, and its failure to define fchmod for non-Emacs executables. > We can't expect non-w32 experts to anticipate that sort of tricky > situation flawlessly every time. No one requested you to be the expert, you are missing the point. You never explained why the switch from chmod to fchmod was needed anyway. Do we really care about race conditions here? What, the same user will be updating her score simultaneously from 2 sessions? Come on! Feature freeze means restraint: do not try to "fix" that which has been happily "broken" for ages.