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: Mon, 11 Apr 2011 18:16:40 -0700 Organization: UCLA Computer Science Department Message-ID: <4DA3A7F8.1020503@cs.ucla.edu> References: <87wrj1jhfc.fsf@rho.meyering.net> <87hba5yq0p.fsf@uwakimon.sk.tsukuba.ac.jp> <834o64sxd7.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1302571024 24268 80.91.229.12 (12 Apr 2011 01:17:04 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 12 Apr 2011 01:17:04 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 12 03:17:00 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists2.gnu.org ([140.186.70.17] helo=lists.gnu.org) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Q9SDz-00068k-W8 for ged-emacs-devel@m.gmane.org; Tue, 12 Apr 2011 03:17:00 +0200 Original-Received: from localhost ([::1]:55302 helo=lists2.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q9SDz-0006RD-Mt for ged-emacs-devel@m.gmane.org; Mon, 11 Apr 2011 21:16:59 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:59862) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q9SDr-0006LV-Um for emacs-devel@gnu.org; Mon, 11 Apr 2011 21:16:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q9SDq-0005I2-OQ for emacs-devel@gnu.org; Mon, 11 Apr 2011 21:16:51 -0400 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:38333) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q9SDq-0005E0-He for emacs-devel@gnu.org; Mon, 11 Apr 2011 21:16:50 -0400 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 745B239E80F5 for ; Mon, 11 Apr 2011 18:16:41 -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 2yVtI-qGHwY8 for ; Mon, 11 Apr 2011 18:16:41 -0700 (PDT) Original-Received: from [131.179.64.200] (Penguin.CS.UCLA.EDU [131.179.64.200]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id F19C839E80DB for ; Mon, 11 Apr 2011 18:16:40 -0700 (PDT) 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 In-Reply-To: <834o64sxd7.fsf@gnu.org> 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:138399 Archived-At: emacs_read and emacs_write are a bit of a special case, because by design Emacs always invokes them with a small positive size (currently limited to 64 KiB, if memory serves). So any signature will do; it really doesn't matter. The old signature worked; the new one works; and making the signature compatible with ordinary 'read' and 'write' would also work. Of these choices, I mildly prefer using the 'read' and 'write' signature since that's what C programmers would expect; and second would prefer going back the way it used to be (using the argument that if it wasn't broken, why fix it....). To some extent this discussion is a proxy for what the internal coding style of Emacs should be, for integers. Here are some suggestions: * When dealing with system objects, such as file descriptors and C object sizes, use the relevant system types, such as 'int' and 'size_t'. * When dealing with Emacs fixnums, which are always signed, use EMACS_INT. * Use EMACS_UINT only when EMACS_INT would yield undefined behavior due to integer overflow. * If overflow is possible when calculating values of a type, e.g., when converting from one type to another, then check this at runtime. I realize these guidelines are often violated (particularly the last one :-), but using them would help make Emacs internals more reliable.