From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Welsh Duggan Newsgroups: gmane.emacs.devel Subject: Re: oops? read/write vs type of length parameter Date: Thu, 14 Apr 2011 16:57:43 -0400 Message-ID: <87aafsh7p4.fsf@maru.md5i.com> References: <87wrj1jhfc.fsf@rho.meyering.net> <87d3ktjb9l.fsf@rho.meyering.net> <877hb1j7lz.fsf@rho.meyering.net> <877hb1m0jy.fsf@fencepost.gnu.org> <87wrj0fo8x.fsf@rho.meyering.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1302814681 26076 80.91.229.12 (14 Apr 2011 20:58:01 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 14 Apr 2011 20:58:01 +0000 (UTC) Cc: David Kastrup , emacs-devel@gnu.org To: Jim Meyering Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 14 22:57:57 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 1QATbw-0001gR-59 for ged-emacs-devel@m.gmane.org; Thu, 14 Apr 2011 22:57:56 +0200 Original-Received: from localhost ([::1]:42006 helo=lists2.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QATbv-0002d7-Rp for ged-emacs-devel@m.gmane.org; Thu, 14 Apr 2011 16:57:55 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:37113) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QATbt-0002cz-6N for emacs-devel@gnu.org; Thu, 14 Apr 2011 16:57:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QATbs-0001bw-7i for emacs-devel@gnu.org; Thu, 14 Apr 2011 16:57:53 -0400 Original-Received: from md5i.com ([75.151.244.229]:55779 helo=maru.md5i.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QATbq-0001b3-Ii; Thu, 14 Apr 2011 16:57:50 -0400 Original-Received: from md5i by maru.md5i.com with local (Exim 4.75) (envelope-from ) id 1QATbj-0007JG-C8; Thu, 14 Apr 2011 16:57:43 -0400 In-Reply-To: <87wrj0fo8x.fsf@rho.meyering.net> (Jim Meyering's message of "Mon, 11 Apr 2011 23:54:06 +0200") User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 75.151.244.229 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:138486 Archived-At: Jim Meyering writes: > David Kastrup wrote: >> Jim Meyering writes: >> >>> 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. >> >> Resulting in an error or nothing happening. In contrast, if a negative >> number is turned into a long yet valid (2-4GiB) number, it is very >> likely that unintended memory areas will get stomped over. > > Since someone mentioned a goal of being able to edit a 2GiB > file, I thought people here would be sensitive to an API policy > that renders that goal unreachable on some systems. > > Of course the extra bit doesn't matter when you start with 64, > but starting with only 32, using an unsigned "length" would > avoid that unnecessary limit. Forgive me if this is already known, but I believe the POSIX standard says that "If the value of nbyte is greater than {SSIZE_MAX}, the result is implementation-defined." This implies that there is no guarantee that the extra bit would ever be reliably used anyway. -- Michael Welsh Duggan (md5i@md5i.com)