From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: oops? read/write vs type of length parameter Date: Wed, 13 Apr 2011 09:06:14 -0700 Organization: UCLA Computer Science Department Message-ID: <4DA5C9F6.3070209@cs.ucla.edu> References: <87wrj1jhfc.fsf@rho.meyering.net> <87hba5yq0p.fsf@uwakimon.sk.tsukuba.ac.jp> <834o64sxd7.fsf@gnu.org> <4DA3A7F8.1020503@cs.ucla.edu> <83k4f0qijz.fsf@gnu.org> <4DA3DDCD.10700@cs.ucla.edu> <4DA40AFE.8050406@cs.ucla.edu> <4DA47581.9010509@cs.ucla.edu> <4DA53148.5000903@cs.ucla.edu> <4DA55B85.5090305@cs.ucla.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1302710817 1430 80.91.229.12 (13 Apr 2011 16:06:57 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 13 Apr 2011 16:06:57 +0000 (UTC) Cc: jim@meyering.net, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 13 18:06:53 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QA2ai-0002mE-1t for ged-emacs-devel@m.gmane.org; Wed, 13 Apr 2011 18:06:52 +0200 Original-Received: from localhost ([::1]:59802 helo=lists2.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QA2ah-0007Fe-Fz for ged-emacs-devel@m.gmane.org; Wed, 13 Apr 2011 12:06:51 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:46865) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QA2aZ-0007FE-Lj for emacs-devel@gnu.org; Wed, 13 Apr 2011 12:06:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QA2aQ-0001tG-Ay for emacs-devel@gnu.org; Wed, 13 Apr 2011 12:06:43 -0400 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:47382) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QA2aG-0001ry-Ea; Wed, 13 Apr 2011 12:06:24 -0400 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 179DB39E80F5; Wed, 13 Apr 2011 09:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcjkYOD4L1YV; Wed, 13 Apr 2011 09:06:22 -0700 (PDT) Original-Received: from [192.168.1.10] (pool-71-189-109-235.lsanca.fios.verizon.net [71.189.109.235]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 623F139E80DB; Wed, 13 Apr 2011 09:06:22 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 131.179.128.62 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:138460 Archived-At: On 04/13/2011 02:46 AM, Eli Zaretskii wrote: > I was asking whether testing errno for EWOULDBLOCK > and EAGAIN, and the code that deals with when that happens, are good > enough for all the possible reasons that emacs_write and > emacs_gnutls_write could return a partial count of bytes. The revised send_process code tests for EWOULDBLOCK and EAGAIN under the same conditions that it does now. If the checks are good enough now, they will continue to be good enough after the proposed change. So I still see no problem here. > sysdep.c is not about system things, it's about Emacs code that > requires platform-dependent techniques. Most of that indeed deals > with system types, but you will find quite a few Emacs specific > internals Yes, and I had already mentioned that the abstraction boundaries were sometimes being violated there. But let's not make matters worse. sysdep.c is supposed to be for interfaces to system-dependent kernel and library code, not for access to Emacs Lisp internals. >> For example, it would be a fairly small change to make Emacs buildable on >> a machine with 32-bit pointers and 64-bit EMACS_INT. > > Somehow, I doubt it is a small change. But if it is, by all means > let's do it now! What are we waiting for? I suspect you are joking, but if not, I'd be happy to implement it. It shouldn't take that long, and it'd be nice to remove that silly 512 MiB limit. Would you object to such a change? But at any rate, that would be a different change, and this fix shouldn't wait on it. >> emacs_write should not stand in the way of plausible improvements >> such as this one. > > Such a configuration (if it indeed is possible "easily") will need to > revamp several calls to emacs_write anyway, so what type we use there > now is a moot point. True, and it suggests that we can revisit the issue if this idea is implemented. But in the meantime, we have a proposed change that fixes bugs and doesn't introduce bugs. Since there are no downsides to this fix now, and no improvements to it have been suggested, we can install it now, and worry about future improvements later. > Either you care about future changes or you don't. Both. I care about plausible future changes; and I also realize that we don't have time to program for all possibilities and need to fix what's before us, which the proposed patch does.