From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.bugs Subject: Re: guile 1.9.0 scm_read_hash_extend gc trouble Date: Sat, 27 Jun 2009 22:53:35 +0100 Message-ID: <8763eh4a3k.fsf@arudy.ossau.uklinux.net> References: <20090621120823.M97037@ccrma.Stanford.EDU> <873a9tr46q.fsf@arudy.ossau.uklinux.net> <87skhtpolb.fsf@arudy.ossau.uklinux.net> <20090622171923.M95660@ccrma.Stanford.EDU> <87bpof7sw3.fsf@arudy.ossau.uklinux.net> <20090623191142.M93181@ccrma.Stanford.EDU> <86zlby35wx.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1246139674 29484 80.91.229.12 (27 Jun 2009 21:54:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 27 Jun 2009 21:54:34 +0000 (UTC) Cc: bug-guile@gnu.org To: ludo@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Sat Jun 27 23:54:27 2009 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MKfqs-0005kA-Ka for guile-bugs@m.gmane.org; Sat, 27 Jun 2009 23:54:26 +0200 Original-Received: from localhost ([127.0.0.1]:40015 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MKfqs-0003SA-0B for guile-bugs@m.gmane.org; Sat, 27 Jun 2009 17:54:26 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MKfqn-0003Oj-Vy for bug-guile@gnu.org; Sat, 27 Jun 2009 17:54:22 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MKfqj-0003B8-CA for bug-guile@gnu.org; Sat, 27 Jun 2009 17:54:21 -0400 Original-Received: from [199.232.76.173] (port=58648 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MKfqi-0003AQ-Tm for bug-guile@gnu.org; Sat, 27 Jun 2009 17:54:16 -0400 Original-Received: from mail3.uklinux.net ([80.84.72.33]:36911) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MKfqg-0008Ts-H6; Sat, 27 Jun 2009 17:54:14 -0400 Original-Received: from arudy (host86-152-99-133.range86-152.btcentralplus.com [86.152.99.133]) by mail3.uklinux.net (Postfix) with ESMTP id C91501F7824; Sat, 27 Jun 2009 22:53:36 +0100 (BST) Original-Received: from arudy.ossau.uklinux.net (arudy [127.0.0.1]) by arudy (Postfix) with ESMTP id 1F83938021; Sat, 27 Jun 2009 22:53:36 +0100 (BST) In-Reply-To: <86zlby35wx.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?= =?iso-8859-1?Q?=22's?= message of "Wed\, 24 Jun 2009 01\:07\:58 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.4-2.6 X-BeenThere: bug-guile@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.bugs:4251 Archived-At: ludo@gnu.org (Ludovic Court=E8s) writes: > The attached patch adds a new `scm_t_off' type, whose definition does > not depend on the application's `_FILE_OFFSET_BITS' value. Can you > confirm that it allows you to build Guile with 32-bit offsets and Snd > with 64-bit offsets (or vice versa)? > > Neil: Does this sound like the right approach? Yes, this looks great. (In case it makes a difference, I've reviewed the master commit, not the patch that you put in email.) Also I think it means that we can delete some code that was needed to handle the possibility that off_t might be 32-bit on a platform that also supports large files. - In scm_seek (), the "if (SCM_OPFPORTP (fd_port))" block is now not needed, because the following more general "if (SCM_OPPORTP (fd_port))" case will handle 64-bit correctly. - Therefore scm_i_fport_seek () can be removed. - The "#if GUILE_USE_64_CALLS && HAVE_STAT64 && SIZEOF_OFF_T !=3D SIZEOF_OFF64_T" implementation of fport_seek () can be removed, because fport_seek () is now always identical to fport_seek_or_seek64 (). - Plus the same things again but for "truncate" instead of "seek". Would you agree? Regards, Neil