From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: view/edit large files Date: Wed, 18 Feb 2009 05:18:03 +0900 Message-ID: <871vtw95s4.fsf@catnip.gol.com> References: <86fxiuw6u7.fsf@lifelogs.com> <86zlgzqudo.fsf_-_@lifelogs.com> <86k583p96e.fsf@lifelogs.com> <874oz7grs0.fsf@catnip.gol.com> <864oz3nyj8.fsf@lifelogs.com> <864oz2l47t.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1234901916 11449 80.91.229.12 (17 Feb 2009 20:18:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Feb 2009 20:18:36 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 17 21:19:52 2009 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.50) id 1LZWQ2-0008AZ-3Z for ged-emacs-devel@m.gmane.org; Tue, 17 Feb 2009 21:19:50 +0100 Original-Received: from localhost ([127.0.0.1]:43997 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LZWOh-0005Pl-S8 for ged-emacs-devel@m.gmane.org; Tue, 17 Feb 2009 15:18:27 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LZWOc-0005NT-Vj for emacs-devel@gnu.org; Tue, 17 Feb 2009 15:18:23 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LZWOc-0005Mq-EG for emacs-devel@gnu.org; Tue, 17 Feb 2009 15:18:22 -0500 Original-Received: from [199.232.76.173] (port=33648 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LZWOc-0005Mf-Ax for emacs-devel@gnu.org; Tue, 17 Feb 2009 15:18:22 -0500 Original-Received: from main.gmane.org ([80.91.229.2]:46082 helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LZWOb-0007fu-Ol for emacs-devel@gnu.org; Tue, 17 Feb 2009 15:18:22 -0500 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1LZWOW-0004Q9-5J for emacs-devel@gnu.org; Tue, 17 Feb 2009 20:18:16 +0000 Original-Received: from 218.231.175.8.eo.eaccess.ne.jp ([218.231.175.8]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Feb 2009 20:18:16 +0000 Original-Received: from miles by 218.231.175.8.eo.eaccess.ne.jp with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Feb 2009 20:18:16 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 46 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 218.231.175.8.eo.eaccess.ne.jp System-Type: x86_64-unknown-linux-gnu Cancel-Lock: sha1:OWNGzxMOlFeVheWWr5e3dZgJILE= X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:109146 Archived-At: Eli Zaretskii writes: >> + off_t beg_offset, end_offset; > > Is off_t guaranteed to be 64-bit wide? If not, we lose the advantage > of the floats, no? If the system isn't capable of handling large files at all, then there's no point in worrying about it, right? >> + beg_offset = FLOATP (beg) ? (off_t) XFLOAT_DATA (beg) : XINT (beg); >> + end_offset = FLOATP (end) ? (off_t) XFLOAT_DATA (end) : XINT (end); > > Shouldn't we round rather than truncate, when converting to off_t? No. The values being represented are integers. The user almost certainly will not be passing in a non-integral float; if he is doing something weird so that he may end up with non-integral offsets, then it's his job to worry about how such values are interpreted as integer offsets. Maybe it should guard against overflow in the conversion though (and signal an error?). >> - if (XINT (beg) != 0) >> + if (beg_offset != 0) > > Exact equalities might be dangerous with floats. > >> - if (same_at_start - BEGV_BYTE == XINT (end)) >> + if (same_at_start - BEGV_BYTE == end_offset - beg_offset) > Likewise. >> - if (XINT (beg) != 0 || !NILP (replace)) >> + if (beg_offset != 0 || !NILP (replace)) > Likewise. Comparing against zero here is fine -- a float can represent it exactly, and there's no non-integer calculation to lose accuracy. If there was overflow in the conversion to off_t, it probabably should have been caught during the conversion. -Miles -- Discriminate, v.i. To note the particulars in which one person or thing is, if possible, more objectionable than another.