From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jim Meyering Newsgroups: gmane.emacs.devel Subject: Re: oops? read/write vs type of length parameter Date: Mon, 11 Apr 2011 14:27:36 +0200 Message-ID: <877hb1j7lz.fsf@rho.meyering.net> References: <87wrj1jhfc.fsf@rho.meyering.net> <87d3ktjb9l.fsf@rho.meyering.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1302524876 12089 80.91.229.12 (11 Apr 2011 12:27:56 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 11 Apr 2011 12:27:56 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 11 14:27:52 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 1Q9GDf-00088L-Bo for ged-emacs-devel@m.gmane.org; Mon, 11 Apr 2011 14:27:51 +0200 Original-Received: from localhost ([127.0.0.1]:47685 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q9GDe-0005g0-1C for ged-emacs-devel@m.gmane.org; Mon, 11 Apr 2011 08:27:50 -0400 Original-Received: from [140.186.70.92] (port=52772 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q9GDZ-0005f6-5L for emacs-devel@gnu.org; Mon, 11 Apr 2011 08:27:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q9GDX-0002Pj-7N for emacs-devel@gnu.org; Mon, 11 Apr 2011 08:27:44 -0400 Original-Received: from mx.meyering.net ([82.230.74.64]:51273) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q9GDV-0002P4-Bl; Mon, 11 Apr 2011 08:27:41 -0400 Original-Received: by rho.meyering.net (Acme Bit-Twister, from userid 1000) id 077BA6021B; Mon, 11 Apr 2011 14:27:36 +0200 (CEST) In-Reply-To: (Eli Zaretskii's message of "Mon, 11 Apr 2011 07:52:45 -0400") Original-Lines: 47 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 82.230.74.64 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:138386 Archived-At: Eli Zaretskii wrote: >> 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. >From my experience with signedness-related warnings, it is counterproductive to enable options like -Wsign-conversion and -Wsign-compare, unless you're prepared to cherry-pick fixes for the few "real" problems and to ignore the others. Adding casts to work around them makes the "cure" worse than the disease. > 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. What about when EMACS_INT is defined to "int"? Someone will inevitably call your write-like function with a length of type size_t -- many existing uses do just that -- and by using a signed type, you will have converted their long yet valid (2-4GiB), buffer length, into a negative number.