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: oops? read/write vs type of length parameter Date: Mon, 11 Apr 2011 07:52:45 -0400 Message-ID: References: <87wrj1jhfc.fsf@rho.meyering.net> <87d3ktjb9l.fsf@rho.meyering.net> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1302522781 32366 80.91.229.12 (11 Apr 2011 11:53:01 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 11 Apr 2011 11:53:01 +0000 (UTC) Cc: emacs-devel@gnu.org To: Jim Meyering Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 11 13:52:57 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Q9Ffr-0004Jx-8n for ged-emacs-devel@m.gmane.org; Mon, 11 Apr 2011 13:52:55 +0200 Original-Received: from localhost ([127.0.0.1]:36576 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q9Ffq-0004BM-6v for ged-emacs-devel@m.gmane.org; Mon, 11 Apr 2011 07:52:54 -0400 Original-Received: from [140.186.70.92] (port=50050 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q9Ffj-00049x-JL for emacs-devel@gnu.org; Mon, 11 Apr 2011 07:52:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q9Ffh-0001GH-RB for emacs-devel@gnu.org; Mon, 11 Apr 2011 07:52:47 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:46451) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q9Ffh-0001GB-P1 for emacs-devel@gnu.org; Mon, 11 Apr 2011 07:52:45 -0400 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1Q9Ffh-0004sR-3D; Mon, 11 Apr 2011 07:52:45 -0400 In-reply-to: <87d3ktjb9l.fsf@rho.meyering.net> (message from Jim Meyering on Mon, 11 Apr 2011 13:08:38 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.10 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:138383 Archived-At: > From: Jim Meyering > Cc: emacs-devel@gnu.org > Date: Mon, 11 Apr 2011 13:08:38 +0200 > > Currently, emacs_write silently ignores an invalid buffer length, > treating it just like a length of 0. It'd be better not to ignore > such an error. emacs_write simply does nothing for negative sizes. However, its callers will not silently ignore that: emacs_write returns that same value to the caller, and callers should (and some do) check the return value for being non-negative. See, for example, write-region (whose debugging led to this change in the interface). > IMHO, an interface that takes a logically unsigned parameter > should have an unsigned type. That would be a major inconvenience, and even annoyance: in Emacs, it is a very frequent idiom to pass the result of subtracting two EMACS_INT values, because we reference buffers and strings with such values. Having the argument as unsigned type would trigger warnings and will need explicit type casts. And with type casts, there's the danger of interpreting a negative value as a large positive one. So I think on balance, having a signed type there is better. The fact that it is slightly narrower is not a problem in this case: EMACS_INT is already a couple of bits narrower than the size_t type, so we don't lose anything. > I guess I'm biased towards least-surprise for developers, so I > think read- and write-like functions should accept a buffer length > argument of type size_t, to be consistent with read and write. I'm sure you agree that the situation with read and write is less than ideal. I don't see why we should follow that in Emacs. A developer who sees that a function named emacs_write is called instead of write should assume that emacs_write is not a trivial wrapper, and should look there to see the details. > To try to protect against bugs by changing API to a signed type may > actually cause trouble when callers end up mixing/comparing their > newly signed (to accommodate the invented API) and unsigned lengths > from standard functions. As I said, the normal use cases in Emacs is that the data types used to compute that argument are signed to begin with. And the previous API used `int', which is also a signed type. > Another thing to keep in mind: on some older systems, trying to read > more than INT_MAX bytes in a single syscall will fail. On such system, emacs_write will return either -1 or a value less than the last arg, and the caller will notice that and produce a suitable error message.